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
|
Home