Re: [Xen-devel] Move some of the PCI device manage/control into pciback?

[Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>]

On Thu, 15 Jan 2009 11:09:21 +0800
"Cui, Dexuan" <dexuan.cui@xxxxxxxxx> wrote:

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

I agree with you that there are two similar codes in pciback and
ioemu. But I'm not happy if the code is removed from ioemu.

In case of HVM domain with stub domain, I'm considering direct access
from ioemu to configuration space.  We can achieve this by mapping the
subset of MMCFG to stub domain. This will improve the scalability of PCI
pass-through and reduce the responsibility of dom0.

My model is the following.

    1. PCI back driver resets the device and setups it.
    2. PCI back driver passes the responsibility of configuration
       space of device to ioemu.
    3. Ioemu reads/writes configuration space of the device,
       responding guest OS.
    4. When ioemu exits, pci back driver gets the responsibility of
       configuration space of device.
    5. PCI back driver resets device (and put D3hot state if possible)

As you know, current xend reads/writes configuration space. If xend
doesn't reads/writes, the architecture becomes simpler.

What do you think about this?

Thanks,
--
Shohei Fujiwara

> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel