> From: Jan Beulich <jbeul...@suse.com> > Sent: Monday, March 1, 2021 4:16 PM > > On 01.03.2021 03:18, Tian, Kevin wrote: > >> From: Roger Pau Monné <roger....@citrix.com> > >> Sent: Thursday, February 11, 2021 8:27 PM > >> > >> On Thu, Feb 11, 2021 at 12:22:41PM +0100, Jan Beulich wrote: > >>> On 11.02.2021 12:16, Roger Pau Monné wrote: > >>>> On Thu, Feb 11, 2021 at 11:36:59AM +0100, Jan Beulich wrote: > >>>>> On 11.02.2021 09:45, Roger Pau Monné wrote: > >>>>>> On Wed, Feb 10, 2021 at 05:48:26PM +0100, Jan Beulich wrote: > >>>>>>> --- a/xen/include/asm-x86/p2m.h > >>>>>>> +++ b/xen/include/asm-x86/p2m.h > >>>>>>> @@ -935,6 +935,9 @@ static inline unsigned int p2m_get_iommu > >>>>>>> flags = IOMMUF_readable; > >>>>>>> if ( !rangeset_contains_singleton(mmio_ro_ranges, > mfn_x(mfn)) ) > >>>>>>> flags |= IOMMUF_writable; > >>>>>>> + /* VMX'es APIC access page is global and hence has no owner. > >> */ > >>>>>>> + if ( mfn_valid(mfn) && !page_get_owner(mfn_to_page(mfn)) ) > >>>>>>> + flags = 0; > >>>>>> > >>>>>> Is it fine to have this page accessible to devices if the page tables > >>>>>> are shared between the CPU and the IOMMU? > >>>>> > >>>>> No, it's not, but what do you do? As said elsewhere, devices > >>>>> gaining more access than is helpful is the price we pay for > >>>>> being able to share page tables. But ... > >>>> > >>>> I'm concerned about allowing devices to write to this shared page, as > >>>> could be used as an unintended way to exchange information between > >>>> domains? > >>> > >>> Well, such an abuse would be possible, but it wouldn't be part > >>> of an ABI and hence could break at any time. Similarly I > >>> wouldn't consider it an information leak if a guest abused > >>> this. > >> > >> Hm, I'm kind of worried about having such shared page accessible to > >> guests. Could Intel confirm whether pages in the 0xFEExxxxx range are > >> accessible to devices in any way when using IOMMU shared page > >> tables? > > > > 0xFEExxxxx range is special. Requests to this range are not subject to > > DMA remapping (even if a valid mapping for this range exists in the > > IOMMU page table). And this special treatment is true regardless of > > whether interrupt remapping is enabled (which comes only after an > > interrupt message to this range is recognized). > > For my/our education, could you outline what happens to device > accesses to that range when interrupt remapping is off? And > perhaps also what happens to accesses to this range that don't > match the pattern of an MSI initiation (dword write)? I don't > think I've been able to spot anything to this effect in the docs. >
In VT-d spec "3.14 Handling Requests to Interrupt Address Range" -- On Intel® architecture platforms, physical address range 0xFEEx_xxxx is designated as the interrupt address range. Requests without PASID to this range are not subjected to DMA remapping (even if translation structures specify a mapping for this range). -- The following types of requests to this range are illegal requests. They are blocked and reported as Interrupt Remapping faults. • Read requests without PASID that are not ZLR. • Atomics requests without PASID. • Non-DWORD length write requests without PASID. -- Interrupt remapping decides how to interpret the format of the recognized interrupt message and whether to go through IRTE, as explained in "5.1.4 Interrupt-Remapping Hardware Operation": -- An interrupt request is identified by hardware as a DWORD sized write request to interrupt address ranges 0xFEEx_xxxx. • When interrupt-remapping is not enabled (IRES field Clear in Global Status Register), all interrupt requests are processed per the Compatibility interrupt request format described in Section 5.1.2.1. • When interrupt-remapping is enabled (IRES field Set in Global Status Register), interrupt requests are processed as follows: ... -- Thanks Kevin
