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

[Tim Deegan <tim@xxxxxxx>]

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.

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?

Tim.


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