On 5/18/23 10:33, Sean Christopherson wrote: > > 2. I'm pretty sure conditioning mmio_stale_data_clear on kvm_arch_has_assigned_device() > is a bug. AIUI, the vulnerability applies to _any_ MMIO accesses. Assigning > a device is necessary to let the device DMA into the guest, but it's not > necessary to let the guest access MMIO addresses, that's done purely via > memslots. Just to make sure we're all on the same page: KVM needs mitigations when real, hardware MMIO is exposed to the guest. None of this has anything to do with virtio or what guests _normally_ see as devices or MMIO. Right? But direct device assignment does that "real hardware MMIO" for sure because it's mapping parts of the PCI address space (which is all MMIO) into the guest. That's what the kvm_arch_has_assigned_device() check was going for. But I think you're also saying that, in the end, memory gets exposed to the guest by KVM userspace setting up a memslot. KVM userspace _could_ have mapped a piece of MMIO and could just pass that down to a guest without kvm_arch_has_assigned_device() being involved. That makes the kvm_arch_has_assigned_device() useless. In other words, all guests with kvm_arch_has_assigned_device() need mitigation. But there are potentially situations where the guest can see real hardware MMIO and yet also be !kvm_arch_has_assigned_device().
