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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.03.2021 03:18, Tian, Kevin wrote:
>> From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> 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.

Jan