Re: [PATCH] discard MSR writes

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Amit Shah wrote:
> On Tuesday 20 November 2007 15:42:35 Avi Kivity wrote:
>   
>> Amit Shah wrote:
>>     
>>> On Tuesday 20 November 2007 15:17:54 Avi Kivity wrote:
>>>       
>>>> Amit Shah wrote:
>>>>         
>>>>> On Tuesday 20 November 2007 00:38:05 Markus Rechberger wrote:
>>>>>           
>>>>>> this patch discards MSR writes to the Performance Event-Select
>>>>>> Registers, this is the first issue why vista seems to fail although
>>>>>> now vista ends up in an endless loop a bit later.
>>>>>> Qemu currently also discards those writes.
>>>>>>             
>>>>> Won't this make the corresponding rdmsrs fail? What happens when the
>>>>> rdmsr returns an error, but windows then uses some garbage value (as it
>>>>> thinks the wrmsr succeeded, so the rdmsr also should)?
>>>>>           
>>>> rdmsr will inject #GP for these msrs.  Implementing set_msr() doesn't
>>>> affect rdmsr.
>>>>
>>>>         
>>> >From the AMD programming manual, vol 2:
>>>
>>> The performance event-select registers can be read and written only by
>>> system software running at CPL = 0 using the RDMSR and WRMSR
>>> instructions, respectively. Any attempt to read or write these registers
>>> at CPL > 0 causes a general-protection exception to occur.
>>>       
>> Look through the code that implements rdmsr, it doesn't care about the
>> manuals and will happily inject a #GP for rdmsr of any unimplemented msr
>> (like PerfEvtSel)  wrmsr and rdmsr implementations are not linked.
>>     
>
> That's right; but isn't that wrong if we cause it? I mean if we just allow the 
> wrmsr access to go through (and if they're actually used, not disabled as you 
> mentioned separately), then there'll be no interrupts when the guest expects 
> them to occur, or the rdmsr will fail, when the guest thinks it shouldn't 
> have.
>
>   

It is wrong; but at least it fails loudly.  We can't implement all msrs 
(Intel and AMD are adding them faster than we can code), so we must make 
sure that where we don't implement things, at least we have visibility 
if the guest tries to use them.

> I guess we're putting forth the same point: if the wrmsr is not for disabling 
> interrupts, we shouldn't let it go through, or just implement the required 
> emulation.
>   

Yes.  Ignoring an msr will "fix" one guest but kill another.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/