Re: pv_ops smp support

[Zachary Amsden <zach@vmware.com>]

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>> 1) What do you plan to do to address per-cpu data structures?
>
> Er, what's there at the moment, more or less.  The main thing is that 
> the secondary CPU get the PDA set up (init gdt and %gs) before anyone 
> wants to use it (which is generally the first use of 
> smp_processor_id() or current). At some point we'll probably fold the 
> PDA and PER_CPU together.  Xen can more or less completely initialize 
> the VCPU state before it is brought up, so there's little or no need 
> for any kind of bootstrap code.

No, I don't mean the Linux PDA - how do you access the Xen PDA?  Or have 
they conjoined somehow?



>> 2) What is your remote TLB shootdown model?
>
> Xen has a hypercall to shoot down a set of CPU's TLBs, so it doesn't 
> need to do an IPI (we'll need to extend the flush_tlb interface to 
> make good use of this).  It will still need IPIs for reschedule and 
> remote function calls or course.

So your invalidate "IPI" is actually a hypercall, and you can use the 
existing flush_tlb interface for the most part.  You just need a 
paravirt-op then for the IPI itself, which takes a CPU mask - and this 
seems to match nicely onto your hypercall.  I think you might want to 
optimize this a bit more, however, since in some cases you will issue 
implicit shootdown IPIs during a pte update hypercall.

This might require some reworking of the MMU interfaces in paravirt-ops 
to accomodate providing such a record, and perhaps adding a function to 
flush the tlb_gather interface so that pte updates which have such 
properties can record the shootdown.

This seems much cleaner than designing the shootdown semantic directly 
into such PTE updates, which is I believe what some of the older Xen 
patches did, although I could have misread them.

Zach