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

[Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>]

[Shohei Fujiwara]
> On Fri, 16 Jan 2009 14:16:08 +0800
> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>> Shohei Fujiwara <mailto:fujiwara-sxa@xxxxxxxxxxxxxxx> wrote:
>>> 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.


I still don't understand what you're trying to achieve by avoiding to
go through pciback.  As Keir said, PCI config accesses should not be
taken on the data path.  Config accesses should neither be required
for regular device operation.  It is afterall called "configuration
space", not "control space".  PCI config space acesses are kind of
bound to have some overhead.  For example, Itanium requires them to go
through a SAL call.

Is there a real problem you're trying to solve by pushing this to the
stub domain?  Also, if this is to be handled in the stub domain I
would very much like to be able to configure certain devices so that
their config space acesses are still tunneled through pciback.

        eSk




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