On Wed, 2007-09-19 at 10:08 -0500, Anthony Liguori wrote: > Ryan Harper wrote: > > * Avi Kivity <[EMAIL PROTECTED]> [2007-09-19 03:58]: > > > >> Ryan Harper wrote: > >> > >>>> We have a test which verifies #GP is not caused by setting the bits on > >>>> either AMD or Intel chips. "Stray" bits can get turned on in some cases > >>>> when switching between 64-bit, PAE and non-PAE address modes. > >>>> > >>>> Were you testing on a 64-bit host kernel? > >>>> > >>>> > >>> 64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing > >>> anything 64-bit AFAIK. > >>> > >>> > >> If the host is 64-bit, so is the guest, although the guest can choose to > >> ignore the 64-bit capabilities (and 32-bit guest OSes do; but VMware > >> might be doing something tricky). > >> > > > > Hrm. I'm not sure I understand the distiction you are making. I'll > > give a 32-bit host a try without the patch and see if I see the same > > behavior. > > > > On a 64-bit host, even if the guest kernel is 32-bit the guest could > still detect the ability to run in 64-bit mode. The thinking is that > VMware may be detecting 64-bit capabilities and doing something weird. > I think that's somewhat orthogonal to this patch. It seems like > ignoring setting of reserved bits is the right thing to do in 32-bit > mode. Does anyone disagree with that?
No, VMware does this in non-weird cases. It might not actually load a CR3 with reserved bits set (well, it might do that too in a different version of the code), but the standard path in and out of the VMware monitor has a couple of different ways you can effectively end up with reserved bits set (left as an exercise to the reader). VMware will exhibit this behavior more frequently with 64-bit host, but a PAE / non-PAE mismatch between guest and host also causes the same issue. Our software tests show that AMD and Intel processors ignore these reserved bits across the board and we've been relying on this behavior for some time. BTW, VMware can run 64-bit guests on a 32-bit host, all it needs is capable hardware, so unless you mask the 64-bit support in KVM, you could have a strange situation where the 32-bit KVM starts (or tries to start, expecting success) running 64-bit code. I can imagine a couple of ways that could blow up the host if assumptions are made that 32-bit guests will limit themselves to running 32-bit code. So if you don't support EFER.LM activation, you should strip the cpuid bit from hardware. Zach ------------------------------------------------------------------------- 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
