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

[Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>]

On Fri, 16 Jan 2009 11:26:10 +0800
"Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:

> > 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?
> 
> Shohei, I think this model may have some issue. 
> a) The stubdomain/qemu is not trustable, so user may use a fake stub
>  domain and try to programe some sensitive config space (like MSI).

My idea is to call XEN_DOMCTL_iomem_permission from domain 0. 
So my idea doesn't open a new hole.

In addition to this, interrupt remapping of VT-d can block invalid MSI.

> b) If there is no mmcfg support, to sync access to cf8/cfc will be
> difficult. So you mean we have different implementation for
> mmcfg/cf8 method?

If there is no mmcfg support, I'd like to use existing
mechanism (pciback in dom0 and pcifront in stub domain).

If there is mmcfg support, I'd like to allow stub domain to access
directly.

Thanks,
--
Shohei Fujiwara


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