Re: [PATCH] Remove MSR_P6_{EVNTSEL0,PERFCTR0} from printk warning list.

[Avi Kivity <avi@redhat.com>]

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