[RFC PATCH 0/3] KVM: x86: honor guest memory type

[Tian, Kevin]

> From: Paolo Bonzini
> Sent: Wednesday, February 19, 2020 12:29 AM
> 
> On 14/02/20 23:03, Sean Christopherson wrote:
> >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu <olvaffe at gmail.com> wrote:
> >>> AFAICT, it is currently allowed on ARM (verified) and AMD (not
> >>> verified, but svm_get_mt_mask returns 0 which supposedly means the
> NPT
> >>> does not restrict what the guest PAT can do).  This diff would do the
> >>> trick for Intel without needing any uapi change:
> >> I would be concerned about Intel CPU errata such as SKX40 and SKX59.
> > The part KVM cares about, #MC, is already addressed by forcing UC for
> MMIO.
> > The data corruption issue is on the guest kernel to correctly use WC
> > and/or non-temporal writes.
> 
> What about coherency across live migration?  The userspace process would
> use cached accesses, and also a WBINVD could potentially corrupt guest
> memory.
> 

In such case the userspace process possibly should conservatively use
UC mapping, as if for MMIO regions on a passthrough device. However
there remains a problem. the definition of KVM_MEM_DMA implies 
favoring guest setting, which could be whatever type in concept. Then
assuming UC is also problematic. I'm not sure whether inventing another
interface to query effective memory type from KVM is a good idea. There
is no guarantee that the guest will use same type for every page in the
same slot, then such interface might be messy. Alternatively, maybe
we could just have an interface for KVM userspace to force memory type
for a given slot, if it is mainly used in para-virtualized scenarios (e.g. 
virtio-gpu) where the guest is enlightened to use a forced type (e.g. WC)?

Thanks
Kevin