On 2009年1月19日 08:30:18 +0000
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 19/01/2009 07:05, "Shohei Fujiwara" <fujiwara-sxa@xxxxxxxxxxxxxxx> wrote:
>
> >> 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?
>
> I think what you want to do sounds pretty hard. PCI accesses should
> definitely go through pciback by default. If you need other modes for more
> extensive rearchitecting you are doing, they belong in your dom0-can-reboot
> branch, or in the main tree as a configurable option.
I understand PCI accesses should go through pciback by default. Direct
access to MMCFG from stub domain should be configurable.
I'd like to keep developing in the main tree while it is
possible. For now, I am trying to enable PCI passthrough with stub
domain, keeping it de-privileged. I hope new patch can be applied to
main tree, because it will be useful for other developers and users.
Thanks,
--
Shohei Fujiwara
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel