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
