[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <76a9a58a-06e6-2151-a3a6-a8b61a68ab15@intel.com>
Date: Thu, 4 May 2023 09:30:47 +0800
From: "Yang, Weijiang" <weijiang.yang@...el.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"john.allen@....com" <john.allen@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC: "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>
Subject: Re: [PATCH v2 14/21] KVM:VMX: Add a synthetic MSR to allow userspace
VMM to access GUEST_SSP
On 5/4/2023 1:08 AM, Edgecombe, Rick P wrote:
> On Fri, 2023-04-21 at 09:46 -0400, Yang Weijiang wrote:
>> Introduce a host-only synthetic MSR, MSR_KVM_GUEST_SSP, so that the
>> VMM
>> can read/write the guest's SSP, e.g. to migrate CET state. Use a
>> synthetic
>> MSR, e.g. as opposed to a VCPU_REG_, as GUEST_SSP is subject to the
>> same
>> consistency checks as the PL*_SSP MSRs, i.e. can share code.
> It seems this is exposed to the guest? I'm thinking maybe it should not
> be. IA32_PL0_SSP comes with some extra checks, so MSR_KVM_GUEST_SSP
> seems a bit powerful. I think the guest doesn't need it either.
Make sense. The MSR is just for live migration purpose, no need to
expose it to guest,
will change it, thanks!
Powered by blists - more mailing lists