> -----Original Message----- > From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of Roger > Pau Monné > Sent: 25 July 2019 11:54 > To: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; xen-devel@lists.xenproject.org > Subject: Re: [Xen-devel] [PATCH 1/2] x86/iommu: avoid mapping the interrupt > address range for hwdom > > On Thu, Jul 25, 2019 at 10:22:17AM +0000, Jan Beulich wrote: > > On 23.07.2019 17:48, Roger Pau Monne wrote: > > > Current code only prevent mapping the lapic page into the guest > > > physical memory map. Expand the range to be 0xFEEx_xxxx as described > > > in the Intel VTd specification section 3.13 "Handling Requests to > > > Interrupt Address Range". > > > > > > AMD also lists this address range in the AMD SR5690 Databook, section > > > 2.4.4 "MSI Interrupt Handling and MSI to HT Interrupt Conversion". > > > > > > Requested-by: Andrew Cooper <andrew.coop...@citrix.com> > > > Signed-off-by: Roger Pau Monné <roger....@citrix.com> > > > > I've committed this on the basis that it shouldn't hurt, but having > > thought about this some more I'm not really sure I see the point: > > The IOMMU special cases accesses into this range anyway, to redirect > > lookup to the interrupt remapping table instead of the DMA remapping > > one. Hence any mappings inserted into this range are simply useless, > > but shouldn't otherwise hurt. > > Intel SDM contains: > > "Software must ensure the second-level paging-structure entries are > programmed not to remap input addresses to the interrupt address > range. Hardware behavior is undefined for memory requests remapped to > the interrupt address range." > > In section 3.13 (Handling Requests to Interrupt Address Range). > > Since arch_iommu_hwdom_init/hwdom_iommu_map adds entries to both the > hap and the iommu page tables (or to hap only if shared) Xen should be > careful to not map this range because the iommu special cases this > range, but I'm not sure what hap does.
Presumably such ranges should never end up in the P2M as they'd need to be trapped for emulation? Paul > > Thanks, Roger. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
