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] RE: VT-d device assignment may fail (regression from Xen

To: "'Jan Beulich'" <JBeulich@xxxxxxxxxx>, "'Weidong Han'" <weidong.han@xxxxxxxxx>, "'Yunhong Jiang'" <yunhong.jiang@xxxxxxxxx>
Subject: RE: [Xen-devel] RE: VT-d device assignment may fail (regression from Xen c/s 19805:2f1fa2215e60)
From: "Alfred Song" <song.zhuo@xxxxxxxxxx>
Date: Tue, 26 Oct 2010 11:48:10 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, 'Allen M Kay' <allen.m.kay@xxxxxxxxx>
Delivery-date: Mon, 25 Oct 2010 20:49:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CC5C749020000780001F01A@xxxxxxxxxxxxxxxxxx>
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: <4CC17FE5020000780001E91F@xxxxxxxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659732FBDEB49@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4CC562EC020000780001EE50@xxxxxxxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659732FBDED7D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4CC5C749020000780001F01A@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Act0Yi9WM3KhxVumSw2hZeLjT+O3vwAXRcUg
Hi yulong and guys,

I am just interested in the topic and I have the same question about
hot-plug as Yunhong said in the old mail of this list:

I think the conflict is when we assigned a pci bridge to a domain U,
according to the vt-d spec, 
all the devices under the bridge should have been directly assigned to the
domain U too. 
So the point may be in the current code, the whole bridge(including the
current devices under the bridge) will not be 
allowed to be assigned to the same domain U again. Assume that a real pci
device hot-attached 
to the HW platform where its upstream bridge directly assigned to the above
domain U( if the case is possible), 
the device, according to the vt-d spec, should be assigned to the same
domain U, but whether the hot-plug
device is still not allowed to be assigned? 

By the way, I think if the real device which is hot-plugged to hw platform
was assigned to domain 0 firstly 
and then let the tools deal with it, like notifying qemu for a new device
plugged, the process makes sense,
if it is automatically and we don't need some extra work for an
administrator. 

-- zhuo

>>> On 25.10.10 at 17:52, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:

> 
>>-----Original Message-----
>>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>>Sent: Monday, October 25, 2010 4:59 PM
>>To: Han, Weidong; Jiang, Yunhong
>>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx 
>>Subject: RE: VT-d device assignment may fail (regression from Xen c/s
>>19805:2f1fa2215e60)
>>
>>>>> On 25.10.10 at 09:05, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
wrote:
>>>>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx] 
>>> What's the removed bus/devfn check you mean? I didn't catch it in the
patch.
>>
>>There used to be
>>
>>        if ( (secbus != bus) && (secdevfn != 0) )
>>
>>guarding the second call to domain_context_mapping_one().
> 
> I didn't understand quite clearly of the oriignal check (the secbus!= bus
&& 
> secdevfn != 0). But seems the new code should be ok, we only need setup
the 
> devfn=0 for the pcie2pci bridge, at least according to the vt-d spec.

It obviously isn't okay in the case where the original device is the
one at <secbus>:00.0 (and avoiding the attempt to map the device
a second time was - afaict - the intention of that check).

Jan


_______________________________________________
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