Re: domU SMP TODO?

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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".

- xen pmap (only the parts that are Xen specific, x86 ones are already 
MP friendly):
   - 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.

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

- in addition, for save/restore: a way to bring all CPUs (except the 
first one) to a consistent state to save their context. IMHO, the 
difficult part is to ensure that the CPU execution contexts do not hold 
any reference to a machine frame number, as they can change between save 
and restore. This is close in concept to CPU hotplug.

rmind@ branch (uvmplock) will reorganize the locking in uvm(9), and 
makes the locking in pmap easier (I hope so :p ). so the Xen pmap 
locking for MP will be probably minimal.

That is all I can think of, now. Sorry, I do not have an exhaustive TODO 
list for MP work. Manuel may have one though.

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost