RE: [Xen-devel] RE: VT-d device assignment may fail (regression from Xen c/s 19805:2f1fa2215e60)

["Alfred Song" <song.zhuo@xxxxxxxxxx>]

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