On Thu, May 14, 2015 at 05:04:19PM +0200, Paolo Bonzini wrote: > On 14/05/2015 16:47, Josh Triplett wrote: > > On Thu, May 14, 2015 at 10:40:34AM +0200, Paolo Bonzini wrote: > >> On 13/05/2015 22:15, j...@joshtriplett.org wrote: > >>> Leaving aside the "why KVM is in emulation mode", though, shouldn't > >>> emulation mode support finit? > >> > >> Yes, it should strive to support all instructions. But there are a lot, > >> and since it's only used for big real mode you pick your fights. If > >> you're on a pre-Westmere chip and your program uses the FPU in big real > >> mode, it's probably not using any fancy KVM feature and then it's faster > >> to use QEMU's translator instead of KVM. > >> > >> Thus, the emulator covers most non-FPU instructions, and all > >> instructions that access memory (because those are used for MMIO even if > >> not in big real mode). > > > > That doesn't explain, though, why this same BIOS image works fine with > > -enable-kvm on a Sandy Bridge system. > > Found it. It's eptad; you can avoid the problem by loading kvm-intel > with eptad=N. > > OVMF used to place page tables in ROM, which works on real hardware, > and also works on VMs except: > > - on AMD systems > > - on Intel systems, if you have EPT page tables with A/D bits on > > Why? Because on these systems, the processor treat page table accesses as > writes. (Why piggyback this on enabling accessed and dirty flags > for EPT? the answer is probably deep in the EPT microcode). For Intel, > see 28.2.3.2 ("EPT Violations") and 28.2.4 ("Accessed and Dirty Flags > for EPT") in the SDM.
That's...special. Is there no way to work around that? In general, it seems like a bug if KVM cannot faithfully simulate real hardware. > We did fix it for eptad=N and ept=N (commit ba6a35415455, KVM: mmu: > allow page tables to be in read-only slots, 2013-09-09), but ultimately > the processor does not cooperate. You need to update OVMF to a more > recent version, which builds page tables at run time instead of > embedding them in the FD: > > commit c90e37b503d4e79dbebbd49f9bfc3c6c14ffb67d > Author: Jordan Justen <jordan.l.jus...@intel.com> > Date: Tue Sep 24 18:23:20 2013 +0000 > > OvmfPkg: Add platform specific reset vector code for X64 > > KVM has a bug that prevents using page tables in the ROM if the ROM > region utilizes the KVM READONLY memory feature. Therefore, we > avoid using page tables stored in the ROM. > > Since OVMF doesn't require memory initialization, we just build > page table entries in RAM at 0x80000 very early in the OVMF boot > process. This address is just after the 'temp RAM' which is set > up by the SEC module. > > Currently we only set up 4GB of page tables for OVMF's PEI, > but DxeIpl will build identity mapped page tables that cover all > of the available processor physical address space. > > Reported-by: Gary Ching-Pang Lin <g...@suse.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com> > Reviewed-by: Laszlo Ersek <ler...@redhat.com> > Tested-by: Laszlo Ersek <ler...@redhat.com> > > git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14715 > 6f19259b-4bc3-4df7-8a09-765794883524 I can confirm that updating to a newer OVMF makes this problem go away. If there's no way of supporting page tables in ROM with eptad, then you can go ahead and close this bug. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org