From: Robert Hoo <robert.hoo.linux@gmail.com>
To: Yan Zhao <yan.y.zhao@intel.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: pbonzini@redhat.com, seanjc@google.com
Subject: Re: [PATCH v2 5/6] KVM: x86: Keep a per-VM MTRR state
Date: Sun, 21 May 2023 11:44:36 +0800 [thread overview]
Message-ID: <3f09e751-33fd-7d60-78cd-6857d113e8bd@gmail.com> (raw)
In-Reply-To: <20230509135300.1855-1-yan.y.zhao@intel.com>
On 5/9/2023 9:53 PM, Yan Zhao wrote:
> Keep a per-VM MTRR state and point it to the MTRR state of vCPU 0.
>
> This is a preparation patch for KVM to reference a per-VM guest MTRR
> to decide memory type of EPT leaf entries when noncoherent DMA is present.
>
> Though each vCPU has its own MTRR state, MTRR states should be
> consistent across each VM, which is demanded as in Intel's SDM
> "In a multiprocessor system using a processor in the P6 family or a more
> recent family, each processor MUST use the identical MTRR memory map so
> that software will have a consistent view of memory."
>
> Therefore, when memory type of EPT leaf entry needs to honor guest MTRR,
> a per-VM version of guest MTRR can be referenced.
>
> Each vCPU still has its own MTRR state field to keep guest rdmsr()
> returning the right value when there's lag of MTRR update for each vCPU.
>
Can we get rid of per-vCPU MTRR state copies and just have this per-VM
state only? therefore can simplify implementation and avoid hazard of
inconsistency among per-VPU MTRR states.
I see in SDM, it notes:
"In multiple processor systems, the operating system must maintain MTRR
consistency between all the processors in the system (that is, all
processors must use the same MTRR values). The P6 and more recent processor
families provide no hardware support for maintaining this consistency."
leaving each vCPU's MTRR is just to fully mimic HW?
next prev parent reply other threads:[~2023-05-21 3:44 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 13:48 [PATCH v2 0/6] KVM: x86/mmu: refine memtype related mmu zap Yan Zhao
2023-05-09 13:50 ` [PATCH v2 1/6] KVM: x86/mmu: add a new mmu zap helper to indicate memtype changes Yan Zhao
2023-05-10 5:30 ` Chao Gao
2023-05-10 8:06 ` Yan Zhao
2023-05-23 22:51 ` Sean Christopherson
2023-05-24 2:22 ` Yan Zhao
2023-05-24 14:50 ` Sean Christopherson
2023-05-25 10:14 ` Yan Zhao
2023-05-25 15:54 ` Sean Christopherson
2023-05-30 1:32 ` Yan Zhao
2023-05-30 9:48 ` Yan Zhao
2023-05-30 23:51 ` Sean Christopherson
2023-05-31 0:18 ` Yan Zhao
2023-05-09 13:51 ` [PATCH v2 2/6] KVM: x86/mmu: only zap EPT when guest CR0_CD changes Yan Zhao
2023-05-09 13:51 ` [PATCH v2 3/6] KVM: x86/mmu: only zap EPT when guest MTRR changes Yan Zhao
2023-05-10 5:39 ` Chao Gao
2023-05-10 8:00 ` Yan Zhao
2023-05-10 10:54 ` Huang, Kai
2023-05-11 0:15 ` Yan Zhao
2023-05-11 2:42 ` Huang, Kai
2023-05-11 2:31 ` Yan Zhao
2023-05-11 3:05 ` Huang, Kai
2023-05-09 13:52 ` [PATCH v2 4/6] KVM: x86/mmu: Zap all EPT leaf entries according noncoherent DMA count Yan Zhao
2023-05-09 13:53 ` [PATCH v2 5/6] KVM: x86: Keep a per-VM MTRR state Yan Zhao
2023-05-10 17:23 ` David Matlack
2023-05-21 3:44 ` Robert Hoo [this message]
2023-05-23 6:21 ` Yan Zhao
2023-05-24 0:13 ` Sean Christopherson
2023-05-24 11:03 ` Yan Zhao
2023-05-24 18:21 ` Sean Christopherson
2023-05-25 10:09 ` Yan Zhao
2023-05-25 14:53 ` Sean Christopherson
2023-05-26 7:54 ` Yan Zhao
2023-05-26 16:09 ` Sean Christopherson
2023-05-30 1:19 ` Yan Zhao
2023-05-25 7:21 ` Robert Hoo
2023-05-25 15:00 ` Sean Christopherson
2023-05-26 1:49 ` Robert Hoo
2023-05-09 13:53 ` [PATCH v2 6/6] KVM: x86/mmu: use per-VM based MTRR for EPT Yan Zhao
2023-05-24 0:15 ` [PATCH v2 0/6] KVM: x86/mmu: refine memtype related mmu zap Sean Christopherson
2023-05-24 11:04 ` Yan Zhao
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=3f09e751-33fd-7d60-78cd-6857d113e8bd@gmail.com \
--to=robert.hoo.linux@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=yan.y.zhao@intel.com \
/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