Re: domU SMP TODO?

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Jun 28, 2010 at 09:46:58PM +0200, Jean-Yves Migeon wrote:
> On 28.06.2010 21:03, Jeff Rizzo wrote:
> >I know this issue comes up from time to time, but I'm curious if anyone
> >has a relatively well-spelled-out TODO list of what needs doing to have
> >SMP support in a xen domU.
> >
> >I've seen various descriptions of pmap changes, but I would be very
> >interested to get more detailed information.
> >
> >Thanks,
> >+j
> 
> Need some work to be MPSAFE:
> 
> - frontend drivers (xennet, xencons, xbd). Basically, in a MP world,
> threads may queue requests/responses "simultaneously", so you have
> to:
>    - protect the ring I/Os from concurrent access,
>    - protect the SLIST that tracks the different requests/responses
>    - get rid of the "old" spl/tsleep/wakeup model too, and bring it
> to a mutex/condvar "paradigm".

But this is not a showstopped. Right now, in a SMP world, these would be
protected by the biglock, and would work.
Of course, this means the interrupt system knows how to take the
biglock for non-SMP safe handler, and this is not done yet.

> 
> - xen pmap (only the parts that are Xen specific, x86 ones are
> already MP friendly):

unfortunably, no. the x86 pmap uses atomic_ops to update PTEs, and
this doesn't work with Xen as we have to use hypercalls.
We need to grab the per-pmap lock for this, I guess.

>    - all the physical to machine/machine to physical translation
> tables have to be protected by a mutex, or a rwlock.
>    - same goes for the xpq_queue_*() functions.

these could be per-pmap, and use the pmap lock.

> 
> - general work for multi-vcpu attach code (attach + initialization,
> MP trampoline...).

I think this is not the hardest part, as vcpus are already in
virtual land.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--