[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] target-i386: GPF on invalid MSRs
From: |
Josh Triplett |
Subject: |
Re: [Qemu-devel] [PATCH] target-i386: GPF on invalid MSRs |
Date: |
Fri, 27 May 2011 08:46:09 -0700 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, May 27, 2011 at 05:16:56PM +0200, Alexander Graf wrote:
>
> On 27.05.2011, at 17:13, Josh Triplett wrote:
>
> > On Thu, May 26, 2011 at 11:12:12AM +0200, Alexander Graf wrote:
> >> On 26.05.2011, at 11:08, Josh Triplett wrote:
> >>> qemu currently returns 0 for rdmsr on invalid MSRs, and ignores wrmsr on
> >>> invalid MSRs. Real x86 processors GPF on invalid MSRs, which allows
> >>> software to detect unavailable MSRs. Emulate this behavior correctly in
> >>> qemu.
> >>>
> >>> Bug discovered via the BIOS Implementation Test Suite
> >>> <http://biosbits.org/>; fix tested the same way, for both 32-bit and
> >>> 64-bit x86.
> >>
> >> This would break a _lot_ of guests that work just fine today, as qemu
> >> doesn't handle all the necessary MSRs.
> >
> > It also fixes guests that rely on the GPF to indicate the absence of an
> > MSR, and assume that the lack of GPF means the availability of that MSR.
> > Silently returning 0 for unknown MSRs means silent breakage.
>
> It's not about guests triggereing MSRs that they shouldn't. It's that qemu
> doesn't implement all MSRs that all the respective CPUs implement.
>
> > What (buggy) guests expect to use random model-specific registers
> > without either handling GPFs or checking the CPU model first?
>
> Mac OS X for example :). It even breaks on KVM today due to MSR checks.
Ah, of course, since they only run on their own hardware. Fair enough.
> > What MSRs do those guests expect that qemu doesn't currently implement?
> >
> > If this represents a workaround for buggy guests, then may I add an
> > option to control this behavior?
>
> I'm not against this change per-se, but it should definitely have an option
> to disable/enable it and you need to do very extensive testing to make sure
> that all MSRs for most OSs are actually handled.
Fair enough. Expect PATCHv2 with an option in the near future.
- Josh Triplett