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.

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.

-------------------------------------------------------------------------
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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to