Re: [Xen-devel] [PATCH 2/2] x86/iommu: avoid mapping the APIC configuration space for hwdom

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Jul 25, 2019 at 12:47:01PM +0000, Jan Beulich wrote:
> On 24.07.2019 11:43, Jan Beulich wrote:
> > On 23.07.2019 18:45, Andrew Cooper wrote:
> >> On 23/07/2019 17:09, Jan Beulich wrote:
> >>> On 23.07.2019 17:48, Roger Pau Monne wrote:
> >>>> Current code only prevents mapping the io-apic page into the guest
> >>>> physical memory map. Expand the range to be 0xFECx_xxxx as described
> >>>> in the Intel 3 Series Chipset Datasheet section 3.3.1 "APIC
> >>>> Configuration Space (FEC0_0000h–FECF_FFFFh)".
> >>>>
> >>>> AMD also lists this address range in the AMD SR5690 Databook, section
> >>>> 2.4.2 "Non-SB IOAPIC Support".
> >>> But that's chipset specific. I don't think we can blindly assume
> >>> this range.
> >>
> >> The IO-APIC has always lived in that region since its introduction, and
> >> the location isn't even configurable on newer chipsets (If I've read the
> >> SAD routing rules in Skylake correctly.  All that can be configured is
> >> multiple IO-APICs being mapped adjacent to each other.)
> > 
> > I'm pretty sure I've seen IO-APICs outside that range.
> 
>  From my AMD Fam15 system:
> 
> <7>ACPI: Local APIC address 0xfee00000
> <6>IOAPIC[0]: apic_id 0, version 33, address 0xfec00000, GSI 0-23
> <6>IOAPIC[1]: apic_id 1, version 33, address 0xc8000000, GSI 24-55

Hm, I guess the only option is to then blacklist the proposed range
plus any of the pages of the io-apics on the system. I can send a new
version without dropping the current io-apic blacklisting, but then
I'm not sure there's much value in adding the FEC0_0000h–FECF_FFFFh
range.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel