Re: [PATCH v8 1/9] x86/xpti: avoid copying L4 page table contents when possible

[Juergen Gross <jgross@suse.com>]

On 21/04/18 15:32, Tim Deegan wrote:
> Hi,
> 
> At 09:44 +0200 on 19 Apr (1524131080), Juergen Gross wrote:
>>>> So either I'm adding some kind of locking/rcu, or I'm switching to use
>>>> IPIs and access root_pgt_changed only locally.
>>>>
>>>> Do you have any preference?
>>>
>>> Since issuing an IPI is just a single call, I'd prefer not to have new (locking,
>>> rcu, or whatever else) logic added here. Unless of course someone, in
>>> particular Tim, thinks sending an IPI here is a rather bad idea.
> 
> AFAICS you're calling this from shadow code whenever it changes an
> L4e, so I'd rather not have an IPI here if we don't need it.
> 
>> Another alternative would be to pass another flag to the callers to
>> signal the need for a flush. This would require quite some modifications
>> to shadow code I'd like to avoid, though. OTOH this way we could combine
>> flushing the tlb and the root page tables. Tim, any preferences?
> 
> This sounds a promising direction but it should be doabl without major
> surgery to the shadow code.  The shadow code already leaves old sl4es
> visible (in TLBs) when it's safe to do so, so I think the right place
> to hook this is on the receiving side of the TLB flush IPI.  IOW as
> long as:
>  - you copy the L4 on context switch; and
>  - you copy it on the TLB flush IPI is received
> then you can rely on the existing TLB flush mechanisms to do what you need.
> And shadow doesn't have to behave differently from 'normal' PV MM.

It is not so easy. The problem is that e.g. a page fault will flush the
TLB entry for the page in question, but it won't lead to the L4 to be
copied. Additionally a new introduced page resulting in a new L4 entry
would possibly never result in picking up the new L4 shadow entry as a
TLB flush wouldn't be necessary and this would result in an endless
stream of page faults.

I tried that approach be just doing a L4 copy in case of a TLB flush IPI
on all affected cpus but this wouldn't be enough.

So what I'd need to do is to set a new flag when writing a L4 entry and
carry it up to the point where the TLB flush is done to add a L4 copy.
All the places which won't do a TLB flush today will have to add one
for the L4 copy.

> Do you think it needs more (in particular to avoid the L4 copy on TLB
> flushes?)  Would a per-domain flag be good enough if per-vcpu is
> difficult?


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel