public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: francisco flynn <francisco_flynn@foxmail.com>
Cc: dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org,  tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, x86@kernel.org,  hpa@zytor.com,
	rdunlap@infradead.org, akpm@linux-foundation.org,
	 bhelgaas@google.com, mawupeng1@huawei.com,
	linux-kernel@vger.kernel.org,  pbonzini@redhat.com,
	kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: x86/mmu: treat WC memory as MMIO
Date: Tue, 12 Mar 2024 08:21:41 -0700	[thread overview]
Message-ID: <ZfBzBUbxpF9MpII-@google.com> (raw)
In-Reply-To: <tencent_AA5D14EAA36D58807959EE9AFC9E07548108@qq.com>

On Tue, Mar 12, 2024, francisco flynn wrote:
> On 2024/3/12 00:20, Sean Christopherson wrote:
> > On Mon, Mar 11, 2024, francisco_flynn wrote:
> >> when doing kvm_tdp_mmu_map for WC memory, such as pages
> >> allocated by amdgpu ttm driver for ttm_write_combined
> >> caching mode(e.g. host coherent in vulkan),
> >> the spte would be set to WB, in this case, vcpu write
> >> to these pages would goes to cache first, and never
> >> be write-combined and host-coherent anymore. so
> >> WC memory should be treated as MMIO, and the effective
> >> memory type is depending on guest PAT.
> > 
> > No, the effective memtype is not fully guest controlled.  By forcing the EPT memtype
> > to UC, the guest can only use UC or WC.  I don't know if there's a use case for
> 
> Well,it's actually the host mapping memory WC and guest uses WC,

No, when the guest is running, the host, i.e. KVM, sets the EPT memory type to UC

  static u8 vmx_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t gfn, bool is_mmio)
  {
	if (is_mmio)
		return MTRR_TYPE_UNCACHABLE << VMX_EPT_MT_EPTE_SHIFT;

which effectively makes the guest "MTRR" memtype UC, and thus restricts the guest
to using UC or WC.

Your use case wants to map the memory as WC in the guest, but there are zero
guarantees that *every* use case wants to access such memory as WC (or UC),
i.e. forcing UC could cause performance regressions for existing use cases.

Ideally, KVM would force the EPT memtype to match the host PAT memtype while still
honoring guest PAT, but if we wanted to go that route, then KVM should (a) stuff
the exact memtype, (b) stuff the memtype for all of guest memory, and (c) do so
for all flavors of KVM on x86, not just EPT on VMX.

Unfortunatley, making that change now risks breaking 15+ years of KVM ABI.  And
there's also the whole "unsafe on Intel CPUs without self-snoop" problem.

> one use case is virtio-gpu host blob, which is to map physical GPU buffers into guest
> 
> > the host mapping memory WC while the guest uses WB, but it should be a moot point,
> > because this this series should do what you want (allow guest to map GPU buffers
> > as WC).
> > 
> > https://lore.kernel.org/all/20240309010929.1403984-1-seanjc@google.com
> > 
> 
> yes, this is what i want, but for virtio-gpu device, if we mapping WC typed 
> GPU buffer into guest, kvm_arch_has_noncoherent_dma would return false, 
> so on cpu without self-snoop support, guest PAT will be ignored, the effective
> memory type would be set to WB, causing data inconsistency.

My understanding is that every Intel CPU released in the last 8+ years supports
self-snoop.  See check_memory_type_self_snoop_errata().

IMO, that's a perfectly reasonable line to draw: if you want virtio-gpu support,
upgrade to Ivy Bridge or later.

  reply	other threads:[~2024-03-12 15:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tencent_4B50D08D2E6211E4F9B867F0531F2C05BA0A@qq.com>
     [not found] ` <Ze8vM6HcU4vnXVSS@google.com>
2024-03-12  8:42   ` [PATCH] KVM: x86/mmu: treat WC memory as MMIO francisco flynn
2024-03-12 15:21     ` Sean Christopherson [this message]
2024-03-13  2:01       ` francisco flynn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZfBzBUbxpF9MpII-@google.com \
    --to=seanjc@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=francisco_flynn@foxmail.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mawupeng1@huawei.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox