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.
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
Thanks,
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
