[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.