[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] x86/traps: Rework #PF[Rsvd] bit handling
On 19/05/2020 17:09, Jan Beulich wrote: > On 19.05.2020 17:33, Andrew Cooper wrote: >> On 19/05/2020 15:48, Jan Beulich wrote: >>> On 19.05.2020 16:11, Andrew Cooper wrote: >>>> Given that shadow frames are limited to 44 bits anyway (and not yet >>>> levelled safely in the migration stream), my suggestion for fixing this >>>> was just to use one extra nibble for the extra 4 bits and call it done. >>> Would you remind(?) me of where this 44-bit restriction is coming >>> from? >> From paging_max_paddr_bits(), >> >> /* Shadowed superpages store GFNs in 32-bit page_info fields. */ > Ah, that's an abuse of the backlink field. After some looking > around I first thought the up field could be used to store the > GFN instead, as it's supposedly used for single-page shadows > only. Then however I found > > static inline int sh_type_has_up_pointer(struct domain *d, unsigned int t) > { > /* Multi-page shadows don't have up-pointers */ > if ( t == SH_type_l1_32_shadow > || t == SH_type_fl1_32_shadow > || t == SH_type_l2_32_shadow ) > return 0; > /* Pinnable shadows don't have up-pointers either */ > return !sh_type_is_pinnable(d, t); > } > > It's unclear to me in which way SH_type_l1_32_shadow and > SH_type_l2_32_shadow are "multi-page" shadows; I'd rather have > expected all three SH_type_fl1_*_shadow to be. Tim? I suspect the comment is incomplete, and should include "4k shadows don't have up-pointers". > > In any event there would be 12 bits to reclaim from the up > pointer - it being a physical address, there'll not be more > than 52 significant bits. Right, but for L1TF safety, the address bits in the PTE must not be cacheable. Currently, on fully populated multi-socket servers, the MMIO fastpath relies on the top 4G of address space not being cacheable, which is the safest we can reasonably manage. Extending this by a nibble takes us to 16G which is not meaningfully less safe. ~Andrew
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |