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] [PATCH][RFC] Support more Capability StructuresandDevice

To: "Yuji Shimada" <shimada-yxb@xxxxxxxxxxxxxxx>, "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH][RFC] Support more Capability StructuresandDevice Specific
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Mon, 30 Jun 2008 13:48:54 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Sun, 29 Jun 2008 22:49:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080630131728.F30A.SHIMADA-YXB@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>
References: <10EA09EFD8728347A513008B6B0DA77A035B4F6F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx><18532.60499.366233.86609@xxxxxxxxxxxxxxxxxxxxxxxx> <20080630131728.F30A.SHIMADA-YXB@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjaalRbZjQBi+HiQ5iTj8bHmBQ2SwAAXkgg
Thread-topic: [Xen-devel] [PATCH][RFC] Support more Capability StructuresandDevice Specific
Hi Yuji,
I looked at the patch.  It seems pretty good. 
Except for the (temporary) absence of MSI/MSI-X stuff, looks the passthrough 
policy in the patch is almost the same as what is discussed in the PDF file 
Eddie posted.

I also made some tests against the patch, and found there may be some unstable 
issues:
I.e., when I boot a 32e RHEL5u1 (I add the "pci=nomsi" parameter)), it can 
easily (30%~80% probable) stay for a very long (i.e., >40s) at "Starting 
udev:", and after I login in shell, the NIC seems not present (the guest has no 
network available), but "lspci" shows the NIC is there.
If I use the Qemu without your patch, the issue disappears at once, and NIC in 
guest works well.

I haven't found issue in your patch yet. :)

Thanks,
-- Dexuan


-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Yuji Shimada
Sent: 2008年6月30日 12:32
To: Ian Jackson
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Dong, Eddie; Keir Fraser
Subject: Re: [Xen-devel] [PATCH][RFC] Support more Capability 
StructuresandDevice Specific

I think it is NOT safe to pass through operations with unknown
behaviour. qemu-dm should prevent guest software setting unsafe value
to register.  We have to investigate each register and decide to
emulate(virtualize) or passthrough.

I haven't investigated some capability structures (like PCI-X
Capability Structure).  I hide them from guest software.

Device Specific Registers (exclude capability structures) is
passthrough. In non-virtualized environment, OS does not touch device
specific registers, but device drivers configure them. In virtualized
environment, we have to allow device drivers to configure them.

--
Yuji Shimada

On Fri, 27 Jun 2008 14:34:11 +0100
Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:

> Dong, Eddie writes ("RE: [Xen-devel] [PATCH][RFC] Support more Capability 
> Structures andDevice Specific"):
> > If we agree the basic policy is pass through except the ones with known
> > behavior, I think we don't need that many case to case handle. Dexuan is
> > working on the implementation base on the summit talk and close to end,
> > maybe Yuji and Dexuan can coordinate first to see if the proposed policy
> > can server yuji's purpose.
> 
> Is it really safe to pass through operations with unknown behavious ?
> Particularly if the system has an iommu, the administrator may be
> expecting the passthrough mechanism to defend the host from rogue
> behaviour by the card and its owning guest.
> 
> (I'm no expert on PCI so forgive me if this question is stupid.)
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

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

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

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