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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
