On 1/24/24 14:26, Gerd Hoffmann wrote:
> Hi,
>
>> So, yesterday I read your status on virt-staff, and I found an entry in
>> it that resembled this upstream thread pretty closely. However, your
>> status was the *only* mention of "mdev" specifically, and so I wasn't
>> sure if *mdev* meant the same thing as the more generic upstream
>> expression "pci device assignment" (see it above in the context).
>>
>> Furthermore, I saw kvm_arch_has_noncoherent_dma() in my linux commit
>> 879ae1880449, which superficially resembled device assignment, but... I
>> dismissed it. In the end, I only managed (and even that, only
>> reluctantly) the above pointers... Thanks for tracking it down!
>>
>> But then, next question: why has this problem *not* been reported
>> repeatedly? There's a whole bunch of users (gamers) that run Windows
>> guests with device (GPU) assignment. I'm sure they'd absolutely complain
>> about very slow OVMF boot (like they actually have, in the past, about
>> similar LZMA slowdowns due to improper caching setup).
>
> static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
> {
> [ ... ]
> * When there is no need to deal with noncoherent DMA (e.g., no VT-d
> * or VT-d has snoop control), guest CD/MTRR/PAT are all ignored. The
> * EPT memory type is set to WB. The effective memory type is forced
> * WB.
> *
> * Otherwise, we trust guest. Guest CD/MTRR/PAT are all honored. The
> * EPT memory type is used to emulate guest CD/MTRR.
> [ ... ]
>
>> Something must be special about Min's assigned device.
>
> Yep. I think the magic word is "snoop control". When pci-assigning a
> *real* pci device VT-d (aka iommu) handles cache control that way. When
> assigning a mdev device this is not the case.
>
> mdev is a virtual pci device emulated by the kernel. This can be purely
> virtual (see samples/vfio-mdev/mtty.c in the linux kernel, which can be
> used to reproduce this). More typical is hardware-assisted device
> partitioning, used for some intel and nvidia gpus. Roughly comparable
> with SR/IOV, but not implemented completely in hardware, the kernel has
> some device-specific support code instead.
Very interesting, thanks! ... But, given that mdev is emulated in the
kernel: isn't that *all the more reason* for treating the guest memory
as writeback-cacheable? With a physical assigned device, the IOMMU has
to implement this "snoop control" with extra gymnastics. With an mdev (a
device emulated in the host kernel), there is just one "coherency
domain" -- we'd have to do extra gymnastics for *breaking* cache
coherence (or put differently, for simulating noncoherent DMA). It seems
to me that with only mdevs assigned, DMA should be assumed coherent (=
"snoop control" should be assumed).
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114305): https://edk2.groups.io/g/devel/message/114305
Mute This Topic: https://groups.io/mt/100367559/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
