Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: domU SMP TODO?



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




Home | Main Index | Thread Index | Old Index