Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.06.2020 15:24, Roger Pau Monné wrote:
> On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote:
>> On 22.06.2020 11:31, Roger Pau Monné wrote:
>>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote:
>>>> On 18.06.2020 18:04, Roger Pau Monne wrote:
>>>>> Commit e9aca9470ed86 introduced a regression when avoiding sending
>>>>> IPIs for certain flush operations. Xen page fault handler
>>>>> (spurious_page_fault) relies on blocking interrupts in order to
>>>>> prevent handling TLB flush IPIs and thus preventing other CPUs from
>>>>> removing page tables pages. Switching to assisted flushing avoided such
>>>>> IPIs, and thus can result in pages belonging to the page tables being
>>>>> removed (and possibly re-used) while __page_fault_type is being
>>>>> executed.
>>>>>
>>>>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted
>>>>> TLB flush. Those selected flushes are the page type change (when
>>>>> switching from a page table type to a different one, ie: a page that
>>>>> has been removed as a page table) and page allocation. This sadly has
>>>>> a negative performance impact on the pvshim, as less assisted flushes
>>>>> can be used.
>>>>>
>>>>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush
>>>>> using an IPI (flush_tlb_mask_sync). Note that the flag is only
>>>>> meaningfully defined when the hypervisor supports PV mode, as
>>>>> otherwise translated domains are in charge of their page tables and
>>>>> won't share page tables with Xen, thus not influencing the result of
>>>>> page walks performed by the spurious fault handler.
>>>>
>>>> Is this true for shadow mode? If a page shadowing a guest one was
>>>> given back quickly enough to the allocator and then re-used, I think
>>>> the same situation could in principle arise.
>>>
>>> Hm, I think it's not applicable to HVM shadow mode at least, because
>>> CR3 is switched as part of vmentry/vmexit, and the page tables are not
>>> shared between Xen and the guest, so there's no way for a HVM shadow
>>> guest to modify the page-tables while Xen is walking them in
>>> spurious_page_fault (note spurious_page_fault is only called when the
>>> fault happens in non-guest context).
>>
>> I'm afraid I disagree, because of shadow's use of "linear page tables".
> 
> You will have to bear with me, but I don't follow.
> 
> Could you provide some pointers at how/where the shadow (I assume
> guest controlled) "linear page tables" are used while in Xen
> context?

See config.h:

/* Slot 258: linear page table (guest table). */
#define LINEAR_PT_VIRT_START    (PML4_ADDR(258))
#define LINEAR_PT_VIRT_END      (LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES)
/* Slot 259: linear page table (shadow table). */
#define SH_LINEAR_PT_VIRT_START (PML4_ADDR(259))
#define SH_LINEAR_PT_VIRT_END   (SH_LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES)

These linear page tables exist in the Xen page tables at basically
all times as long as a shadow guest's vCPU is in context. They're
there to limit the overhead of accessing guest page tables and
their shadows from inside Xen.

Jan