[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits
Hi, At 14:03 +0100 on 25 Feb (1614261809), Jan Beulich wrote: > When none of the physical address bits in PTEs are reserved, we can't > create any 4k (leaf) PTEs which would trigger reserved bit faults. Hence > the present SHOPT_FAST_FAULT_PATH machinery needs to be suppressed in > this case, which is most easily achieved by never creating any magic > entries. > > To compensate a little, eliminate sh_write_p2m_entry_post()'s impact on > such hardware. > > While at it, also avoid using an MMIO magic entry when that would > truncate the incoming GFN. > > Requested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Tim Deegan <tim@xxxxxxx> > I wonder if subsequently we couldn't arrange for SMEP/SMAP faults to be > utilized instead, on capable hardware (which might well be all having > such large a physical address width). I don't immediately see how, since we don't control the access type that the guest will use. > I further wonder whether SH_L1E_MMIO_GFN_MASK couldn't / shouldn't be > widened. I don't see a reason why it would need confining to the low > 32 bits of the PTE - using the full space up to bit 50 ought to be fine > (i.e. just one address bit left set in the magic mask), and we wouldn't > even need that many to encode a 40-bit GFN (i.e. the extra guarding > added here wouldn't then be needed in the first place). Yes, I think it could be reduced to use just one reserved address bit. IIRC we just used such a large mask so the magic entries would be really obvious in debugging, and there was no need to support arbitrary address widths for emulated devices. Cheers, Tim.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |