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, 09 Mar 2010 16:05:00 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>, Weidong Han <weidong.han@xxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, "linux@xxxxxxxxxxxxxx" <linux@xxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 09 Mar 2010 15:06:55 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100309222229.GA700@xxxxxxxxxxxxxxxxxxx>
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>
Organization: HP OSLO R&D
References: <C77E162B.6FE6%keir.fraser@xxxxxxxxxxxxx> <4B59098B.6000108@xxxxxxxxx> <4B590FA4.4000008@xxxxxxxxxxxxxx> <4B59132B.40607@xxxxxxxxx> <4B59188C.50901@xxxxxxxxxxxxxx> <4B59660F.4000909@xxxxxxxxx> <7162ab21003091339i4adb8669safd5e074607386a2@xxxxxxxxxxxxxx> <20100309213026.GA12602@xxxxxxxxxxxxxxxxxxx> <7162ab21003091357v32b3c58qae708301fdf2764a@xxxxxxxxxxxxxx> <20100309222229.GA700@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2010-03-09 at 17:22 -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 09, 2010 at 02:57:00PM -0700, Alex Williamson wrote:
> > On Tue, Mar 9, 2010 at 2:30 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@xxxxxxxxxx> wrote:
> > > On Tue, Mar 09, 2010 at 02:39:10PM -0700, Alex Williamson wrote:
> > >>
> > >> I have a system with what I consider to be a valid DRHD that's getting
> > >> tripped up on this patch.  The problem is that the DRHD includes an
> > >> IOAPIC scope, where the IOAPIC is not materialized on the PCI bus.  I
> > >> think Xen is being overzealous in it's validity checking and that this
> > >> is a valid configuration.  What do others think?  Are IOAPICs a
> > >
> > > How does upstream Linux handle this?
> > 
> > Last I checked, it works just fine, doesn't care that the IOAPIC isn't
> > materialized.
> This is from drivers/pci/intr_remapping.c (2.6.34-rc0):
> 795         if (ir_supported && ir_ioapic_num != nr_ioapics) {
> 796                 printk(KERN_WARNING
> 797                        "Not all IO-APIC's listed under remapping
> hardware\n");
> 798                 return -1;
> 799         }
> 800 
> ir_ioapic_num is figured out from the count of DRHD's.
> So I think Linux would actually turn off VT-d.

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


Xen-devel mailing list