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

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

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.

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

> 
> Thanks,
> --
> Shohei Fujiwara
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel