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/
Home Products Support Community News


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


Xen-devel mailing list