WARNING - OLD ARCHIVES

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

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 16:25:40 -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 15:26:14 -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=vc5svRNDRgwGo9H7emdIj+1Nyd23vsKNt2bhZE5XENk=; b=ik+3r5mL3NJC3zEEzlRq2CxoDIl53EJITjNovXNF9hNClsDK6Krd4fSV3NWp+mXHgE He6bJ4uaaqnhMFJ5oyADzU8kpvGDTESaxxSkibVcB+PIzs7lphX6b4aGmS0YbZ+YZgdr hKU1JdNmOcYdprdWPjx6TkrNSJZW5Qdfr9HWE=
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=FxE4AkYVnvmIySQNkeFTYLR1bxSrtbOnxYG6ijYwKAKZz0jbm1wtf/YYeDR/2CJ3yH SiabXPzjtp30FStreIDezK9YoIXbkQ37CYR8a5Ara7MNmmvb/W+jhhBpilYSwlc+AmzI N0yYYTVuIxcjw9snqhVEvSlM7Swx+ZZ+UqZss=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1268175900.14039.142.camel@xxxxxxxxxx>
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> <4B590FA4.4000008@xxxxxxxxxxxxxx> <4B59132B.40607@xxxxxxxxx> <4B59188C.50901@xxxxxxxxxxxxxx> <4B59660F.4000909@xxxxxxxxx> <7162ab21003091339i4adb8669safd5e074607386a2@xxxxxxxxxxxxxx> <20100309213026.GA12602@xxxxxxxxxxxxxxxxxxx> <7162ab21003091357v32b3c58qae708301fdf2764a@xxxxxxxxxxxxxx> <20100309222229.GA700@xxxxxxxxxxxxxxxxxxx> <1268175900.14039.142.camel@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.
Thanks,

Alex

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel