public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: devel@edk2.groups.io, "Brian J. Johnson" <brian.johnson@hpe.com>,
	 "West, Catharine" <catharine.west@intel.com>,
	"Xu, Min M" <min.m.xu@intel.com>, "Ni, Ray" <ray.ni@intel.com>,
	 "Wu, MingliangX" <mingliangx.wu@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	 "Xue, Shengfeng" <xueshengfeng@byosoft.com.cn>,
	"Dong, Eric" <eric.dong@intel.com>,
	 "Kumar, Rahul R" <rahul.r.kumar@intel.com>,
	"De, Debkumar" <debkumar.de@intel.com>
Subject: Re: [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0
Date: Wed, 24 Jan 2024 18:11:42 +0100	[thread overview]
Message-ID: <63a6jposj5ucemyltcwqkka5fcmng7zvtxoop23n6pc3jetbuo@evihgquzwk5w> (raw)
In-Reply-To: <5e3c5720-4cd6-fa02-fc5e-4eb550df68c3@redhat.com>

  Hi,

> > 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?

For a 100% emulated device this would make sense indeed.  When making
some GPU resources available to VMs (including giving the GPU DMA access
to guest memory) not so much.  The later is the case with the
intel/nvidia gpu mdev devices.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114333): https://edk2.groups.io/g/devel/message/114333
Mute This Topic: https://groups.io/mt/100367559/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



      reply	other threads:[~2024-01-24 17:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26  9:47 [edk2-devel] [PATCH V1 1/1] UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0 xueshengfeng via groups.io
2023-07-26  9:55 ` Ni, Ray
     [not found] ` <177562550EF0534C.27380@groups.io>
2023-08-03  8:14   ` Ni, Ray
2024-01-10  7:51     ` Min Xu
2024-01-10 16:43       ` West, Catharine
2024-01-18 15:46         ` Gerd Hoffmann
2024-01-22 19:11           ` Brian J. Johnson
2024-01-23  5:01             ` Min Xu
2024-01-23 10:52             ` Gerd Hoffmann
2024-01-23 14:13               ` Laszlo Ersek
2024-01-23 16:11                 ` Gerd Hoffmann
2024-01-24  3:06                   ` Min Xu
2024-01-24 12:49                   ` Laszlo Ersek
2024-01-24 13:26                     ` Gerd Hoffmann
2024-01-24 14:45                       ` Laszlo Ersek
2024-01-24 17:11                         ` Gerd Hoffmann [this message]

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-list 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=63a6jposj5ucemyltcwqkka5fcmng7zvtxoop23n6pc3jetbuo@evihgquzwk5w \
    --to=devel@edk2.groups.io \
    /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