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

[Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>]

On Fri, 16 Jan 2009 14:19:12 +0000
Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx> wrote:

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

Domain 0 is SPOF(Single Point of Failure). If domain 0 panics, whole
system stops. So, I'd like to remove the function from domain 0, if we
can keep security. This reduces possibility of panic of domain 0.

In the future, it is great if domain 0 can reboot while guest domain
are working. This avoids SPOF. 
To achieve this, we have to solve many problems. In case
of network, emulating link down during rebooting is needed. In case of
PCI passthrough, it is difficult to block configuration access during
rebooting. If stub domain can access to configuration space directly,
we don't need to block configuration access.

What do you think?

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

There is no real problem of configuration. I also think config space
access should work, if it is tunneled or not.

Thanks,
--
Shohei Fujiwara


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