|
xen-devel
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
|
To: |
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking |
|
From: |
Alex Williamson <alex.williamson@xxxxxx> |
|
Date: |
Tue, 9 Mar 2010 19:13:47 -0700 |
|
Cc: |
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Weidong Han <weidong.han@xxxxxxxxx>, "linux@xxxxxxxxxxxxxx" <linux@xxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx> |
|
Delivery-date: |
Tue, 09 Mar 2010 18:14:27 -0800 |
|
Dkim-signature: |
v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=oLNmZZtk5kDB4MCWHgTZjSaDqZYWqflZnyoCo9xA9LE=; b=n/Y9lFKU5693hEc9LuUYvUK0KroDr1Y2d7LIp+C7luJFFp5RV2Bj21VxCTVeSJm5wN wvI5+XzyUzvP9a7dVk3NSfsqeo4pqRlJtgKD6mIVdcXSsctZD1ZWKQveH7YK3737JVWY EgM+u3I2tPfBH+WZUitoXmhHV4496UJQeVnrs= |
|
Domainkey-signature: |
a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HT9tRXatyshBOLYupKmFfbQO1ydaaLMPD+uN+okIPP2h3nCRv1l9t8z37z6rDhMY53 yCNHRV/bzPSwTyjQbXOir+KhEQ0P49xf/Y4tgoweUTVuVRReP7Rc9ZuD3/S4dvrUHdhF EDZoJ2TePHdFM1PDI3tvoyyFtJHll96zvuQ8k= |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<7162ab21003091525w11e8fc2cmba9264accaa04906@xxxxxxxxxxxxxx> |
|
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: |
<C77E162B.6FE6%keir.fraser@xxxxxxxxxxxxx> <4B59132B.40607@xxxxxxxxx> <4B59188C.50901@xxxxxxxxxxxxxx> <4B59660F.4000909@xxxxxxxxx> <7162ab21003091339i4adb8669safd5e074607386a2@xxxxxxxxxxxxxx> <20100309213026.GA12602@xxxxxxxxxxxxxxxxxxx> <7162ab21003091357v32b3c58qae708301fdf2764a@xxxxxxxxxxxxxx> <20100309222229.GA700@xxxxxxxxxxxxxxxxxxx> <1268175900.14039.142.camel@xxxxxxxxxx> <7162ab21003091525w11e8fc2cmba9264accaa04906@xxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On Tue, Mar 9, 2010 at 4:25 PM, Alex Williamson <alex.williamson@xxxxxx> wrote:
> On Tue, Mar 9, 2010 at 4:05 PM, Alex Williamson <alex.williamson@xxxxxx>
> wrote:
>>
>> In my case ir_ioapic_num will match nr_ioapics, so this shouldn't
>> disable on my system.
>>
>> The problem with the current Xen code is that there's no requirement
>> that an IOAPIC is a PCI device, yet we have to describe it as a device
>> scope under a DRHD to enable interrupt remapping. That means we have to
>> fill in the scope path with something, even if there's no device visible
>> there. We happen to use the path of the IOAPIC if it were exposed so we
>> can keep straight what it is, but nothing requires it to be enumerable
>> on the PCI bus.
>
> I guess we probably do need to use the actual IOAPIC PCI source ID so
> we can enable source ID checking in the interrupt remapping table, but
> I still don't think that implies it needs to be visible on a bus walk.
>
>> IMHO, the only important field in an IOAPIC DRHD scope
>> is the enumeration ID, which allows the OS/VMM to map the IOAPIC to one
>> defined in the MADT.
>
> So actually, I might make the argument that the purpose of IOAPIC scope is:
> 1) Map an MADT defined APIC ID under a DRHD
> 2) Provide the source ID for the IOAPIC
>
> Using the source ID to verify the IOAPIC exists isn't valid, though I
> think it would be valid to verify the APIC ID against the MADT.
Not to beat a dead horse, but I believe my platform is exactly
following sections 8.3.1.1 of the VT-d spec for non-PCI discoverable
IOAPICs with a 2 byte path field. This really needs to be fixed or
removed before Xen 4.0.0. Thanks,
Alex
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home