WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Shohei Fujiwara <fujiwara-sxa@xxxxxxxxxxxxxxx>, Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Move some of the PCI device manage/control into pciback?
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 19 Jan 2009 08:30:18 +0000
Cc: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Delivery-date: Mon, 19 Jan 2009 00:30:19 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090119154513.846E.CB716985@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acl6ECjWXVX3QAUC90KVkVZKq/ckdA==
Thread-topic: [Xen-devel] Move some of the PCI device manage/control into pciback?
User-agent: Microsoft-Entourage/12.15.0.081119
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.

 -- Keir



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

<Prev in Thread] Current Thread [Next in Thread>