RE: [PATCH] VMX: use a single, global APIC access page

["Tian, Kevin" <kevin.tian@intel.com>]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, March 1, 2021 4:16 PM
> 
> On 01.03.2021 03:18, Tian, Kevin wrote:
> >> From: Roger Pau Monné <roger.pau@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