Hi Joerg, Thanks for the new patch-set!
> On Jul 14, 2020, at 5:08 AM, Joerg Roedel <[email protected]> wrote: > > From: Tom Lendacky <[email protected]> > > Add handler for VC exceptions caused by MMIO intercepts. These > intercepts come along as nested page faults on pages with reserved > bits set. > > Signed-off-by: Tom Lendacky <[email protected]> > [ [email protected]: Adapt to VC handling framework ] > Co-developed-by: Joerg Roedel <[email protected]> > Signed-off-by: Joerg Roedel <[email protected]> > > <snip> I’m running into an MMIO-related bug when I try testing this on our hypervisor. During boot, probe_roms (arch/x86/kernel/probe_roms.c) uses romchecksum over the video ROM and extension ROM regions. In my test VM, the video ROM romchecksum starts at virtual address 0xffff8880000c0000 and has length 65536. But, at address 0xffff8880000c4000, we switch from being video-ROM-backed to being unbacked by anything. With SEV-ES enabled, our platform handles reads and writes to unbacked memory by treating them as MMIO. So, the read from 0xffff8880000c4000 causes a #VC, which is handled by do_early_exception. In handling the #VC, vc_slow_virt_to_phys fails for that address. My understanding is that the #VC handler should then add an entry to the page tables and retry the faulting access. Somehow, that isn’t happening. From the hypervisor side, it looks like the guest is looping somehow. (I think the VCPU is mostly unhalted and making progress, but the guest never gets past that romchecksum.) The guest never actually makes an MMIO vmgexit for that address. If I remove the call to probe_roms from setup_arch, or remove the calls to romchecksum from probe_roms, this kernel boots normally. Please let me know of other tests I should run or data that I can collect. Thanks! Mike
