On Mon, Jul 18, 2022, Maxim Levitsky wrote:
> On Fri, 2022-07-15 at 23:00 +0000, Sean Christopherson wrote:
> > diff --git a/arch/x86/kvm/mmu/spte.h b/arch/x86/kvm/mmu/spte.h
> > index ba3dccb202bc..cabe3fbb4f39 100644
> > --- a/arch/x86/kvm/mmu/spte.h
> > +++ b/arch/x86/kvm/mmu/spte.h
> > @@ -147,6 +147,7 @@ extern u64 __read_mostly shadow_mmio_value;
> > extern u64 __read_mostly shadow_mmio_mask;
> > extern u64 __read_mostly shadow_mmio_access_mask;
> > extern u64 __read_mostly shadow_present_mask;
> > +extern u64 __read_mostly shadow_memtype_mask;
> > extern u64 __read_mostly shadow_me_value;
> > extern u64 __read_mostly shadow_me_mask;
> >
>
>
> So if I understand correctly:
>
>
> VMX:
>
> - host MTRRs are ignored.
>
> - all *host* mmio ranges (can only be VFIO's pci BARs), are mapped UC in EPT,
> but guest can override this with its PAT to WC)
>
>
> - all regular memory is mapped WB + guest PAT ignored unless there is noncoherent dma,
> (an older Intel's IOMMU? I think current Intel's IOMMLU are coherent?)
Effectively, yes.
My understanding is that on x86, everything is cache-coherent by default, but devices
can set a no-snoop flag, which breaks cache coherency. But then the IOMMU, except for
old Intel IOMMUs, can block such packets, and VFIO forces the block setting in the IOMMU
when it's supported by hardware.
Note, at first glance, commit e8ae0e140c05 ("vfio: Require that devices support DMA
cache coherence") makes it seem like exposing non-coherent DMA to KVM is impossible,
but IIUC that's just enforcing that the _default_ device behavior provides coherency.
I.e. VFIO will still allow an old Intel IOMMU plus a device that sets no-snoop.
