[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/1 V2] x86/AMD: Fix setup ssss:bb:dd:f for d0 failed



>>> On 04.09.13 at 17:54, Suravee Suthikulanit <suravee.suthikulpanit@xxxxxxx> 
>>> wrote:
> On 9/4/2013 3:51 AM, Jan Beulich wrote:
>>>>> On 31.08.13 at 02:41, <suravee.suthikulpanit@xxxxxxx> wrote:
>>> --- a/xen/drivers/passthrough/vtd/intremap.c
>>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>>> @@ -453,6 +453,7 @@ static void set_msi_source_id(struct pci_dev *pdev,
>>> struct iremap_entry *ire)
>>>           break;
>>>   
>>>       case DEV_TYPE_PCI:
>>> +    case DEV_TYPE_PCI_HOST_BRIDGE:
>>>       case DEV_TYPE_LEGACY_PCI_BRIDGE:
>>>       case DEV_TYPE_PCI2PCIe_BRIDGE:
>>>           ret = find_upstream_bridge(seg, &bus, &devfn, &secbus);
>> There shouldn't be an upstream bridge to a host bridge, and
>> hence adding the case here (rather than above) is at least
>> pointlessly running more complex code (all under the unlikely but
>> not impossible assumption that a host bridge would have MSI set
>> up for it in the first place).
> I put it here because the original code (before introducing the 
> DEV_TYPE_PCI_HOST_BRIDGE) would have classified the host bridge device 
> as "DEV_TYPE_PCI".  Therefore, I was trying to keep the logic the same 
> for Intel.   However, I agree that there should not be upstream bridge 
> from host bridge.

Let's wait for Xiantao's input (in the hope that he'll respond soon).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.