[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


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.

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


Xen-devel mailing list



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