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