On 07/01/2010 05:47 PM, Jes Sorensen wrote:
On 07/01/10 16:44, Avi Kivity wrote:
On 07/01/2010 05:41 PM, Jes Sorensen wrote:
Saw it, which is why I only suggest we remove EVNTSEL0 and PERFCTR0 but
not the others. If the guest is expecting normal operation it is likely
to use more than just the first.
Why is that?
Depends on usage obviously.
People are reporting these triggering in dmesg for both Linux and
Windows guests btw.
We could put them so the two in question only trigger with a debug flag
or something like that?
What values are the guests writing? Are they really expecting this
thing to work?
What would it take to emulate those counters? They're supposed to be
relatively simple, no?
Sometimes just 0x00, other times more advanced values. I'll have to dig
into the manuals to figure out what it is:
kvm: 9480: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079
kvm: 9480: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffd7698c
kvm: 9480: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079
kvm: 23682: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x130079
kvm: 23682: cpu0 unimplemented perfctr wrmsr: 0xc1 data 0xffd7699c
kvm: 23682: cpu0 unimplemented perfctr wrmsr: 0x186 data 0x530079
I'll try and figure out what it is.
Looks like it plays with the enable bit (22). We can ignore writes that
have bit 22 clear (as long as we remember the contents for a subsequent
rdmsr), but we can't just ignore something that's supposed to cause the
hardware to do something.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
