|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Move some of the PCI device manage/control into pciback?
1) Now in Xen VT-d, the FLR related things (can the device(s) be
statically/dynamically assigned to a guest? how should the device(s) be
FLR-ed?) are done in xend. The diff of the python patch is ~700 lines.
We may consider moving these things to pciback. Certainly, with these things
in pciback, I'm afraid we'll have less flexibility -- a small adjustment
(e.g., some people would like to relax the co-assignment constraint) or a bug
fix requires a reload of pciback or a reboot of host (if pciback is built into
Dom0 kernel). And we have some other issues: a) moving all the python logic
into the pciback using C needs a big effort so maybe somebody doesn't like the
big number of the line of code; b) we may need to add an interface between
pciback and control panel so that xend can invoke these FLR related functions
of pciback.
2) Now the pci config space virtualizations of PV and HVM guests are not the
same and there are some duplicated codes in pciback and ioemu. Now the ioemu of
Dom0 accesses device config space via libpci (the /sys); maybe ioemu can talk
to pciback directly?
In the case of stubdomain, looks the libpci is implemented via pcifront -- if
ioemu can talk to pciback directly, I think we can eliminate the duplicated
codes in ioemu and we'll have a consistency between PV and HVM.
And for the pci passthrough related hypercalls invoked by the ioemu in the
de-priviledged stubdomain, I think ioemu can ask pciback to help to invoke the
hypercall, but this needs us to add an interface in pciback.
All these things need us to re-architect the current codes. Will this bring
compatibility issues? I remember it's said Xen 3.4 will be released in March;
now it's the suitable time for us to consider the changes?
PS, in the long run -- how long? -- will ioemu be removed from Dom0 and
stubdomain will be the only place for ioemu?
Any comment is appreciated!
Thanks,
-- Dexuan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|