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

[Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>]

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

> Shohei Fujiwara <mailto:fujiwara-sxa@xxxxxxxxxxxxxxx> wrote:
> > 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.
> 
> I suspect that feature is not enabled in all system.
> 
> Also what will happen if guest try to change the BAR value? Will be
> passed to hardware also? I'm not sure what will happen if two device
> under the same bus has the same BAR value. Maybe then it is possible
> one guest can write MMIO of another device.

This is the figure of my idea.

If mmcfg and interrupt remapping are supported:

    guest domain      | stub domain
    ------------------+------------------------------------------
    guest software -> | ioemu -> libpci(pcifront) -> mmcfg(subset)

If mmcfg or interrupt remapping are not supported:

    guest domain      | stub domain                  | domain 0
    ------------------+------------------------------+---------------------
    guest software -> | ioemu -> libpci(pcifront) -> | pciback -> mmcfg/cf8

    * This is the same with current implementation.

BAR is virtualized by ioemu. BAR value written by guest software 
isn't passed to hardware.

If stub domain is hijacked, it is possible to set invalid BAR value.

> >> 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.
> 
> I'm not sure how difference between these two implementation and if
> we really want keep this implementation. Mostly I think it is ok
> since it should not be on data path (Or any special device will do
> that??)
> But there is really one thing we need consider: The mask bit for
> MSI/MSI-X. Because guest may try to mask/unmask the interrupt. Maybe
> we need translate that operation to the mask/unmask of the virtual
> interrupt.

As mentioned above, my idea keeps pci configuration virtualization in
ioemu in stub domain. So MSI mask bit in config space and MSI-X mask
bits in memory space will work fine.

Thanks,
--
Shohei Fujiwara


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