Re: [Xen-devel] [PATCH] x86/mtrr: recalculate P2M type for domains with iocaps

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 25/04/2019 14:30, Jan Beulich wrote:
>>>> On 23.04.19 at 13:37, <igor.druzhinin@xxxxxxxxxx> wrote:
>> This change reflects the logic in epte_get_entry_emt() and allows
>> changes in guest MTTRs to be reflected in EPT for domains having
>> direct access to certain hardware memory regions but without IOMMU
>> context assigned (e.g. XenGT).
>>
>> Signed-off-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
> 
> Fundamentally I'm happy to get both in sync, so
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> But I have a question:
> 
>>  void memory_type_changed(struct domain *d)
>>  {
>> -    if ( has_iommu_pt(d) && d->vcpu && d->vcpu[0] )
>> +    if ( (has_iommu_pt(d) || cache_flush_permitted(d)) && d->vcpu && 
>> d->vcpu[0] )
>>      {
>>          p2m_memory_type_changed(d);
>>          flush_all(FLUSH_CACHE);
> 
> Wouldn't cache_flush_permitted() alone suffice, both here and
> there? Even if anyone was to pass-through a device without any
> MMIO or I/O port BAR, the memory type (which is a CPU side
> thing only, i.e. doesn't affect DMA by the device) shouldn't
> matter in that case (leaving aside the fact that a BAR-less
> device is unlikely to be DMA-capable, unless the programming
> of the DMA operations was to happen through vendor specific
> config space accesses).
> 

I don't think it's correct in case of EPT sharing with IOMMU as the
section 3.6.5 of VT-d spec implies there is direct effect of caching
information present in IOMMU page table on device accesses within
processor coherency domain. So even in case there are no BARs passed to
the domain, drivers inside it and devices operation on its memory could
still have assumptions on device memory access properties.

Igor

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