Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking

[Alex Williamson <alex.williamson@xxxxxx>]

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,

Alex


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