Re: [PATCH][4.15] x86/shadow: suppress "fast fault path" optimization without reserved bits

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.02.2021 18:07, Tim Deegan wrote:
> 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>

Thanks.

>> 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.

Will cook a patch, albeit I guess I'll keep as many of the bits set
as possible, while still being able to encode a full-40-bit GFN.

Ian - I don't suppose you'd consider this a reasonable thing to do
for 4.15? It would allow limiting the negative (performance) effect
the change here has.

Jan