On Fri, Dec 20, 2024, Xiaoyao Li wrote:
> On 12/19/2024 10:33 AM, Sean Christopherson wrote:
> > > > For all other CPUID bits, what the TDX Module thinks and/or presents to
> > > > the guest
> > > > is completely irrelevant, at least as far as KVM cares, and to some
> > > > extent as far
> > > >
On 12/19/2024 10:33 AM, Sean Christopherson wrote:
For all other CPUID bits, what the TDX Module thinks and/or presents to the
guest
is completely irrelevant, at least as far as KVM cares, and to some extent as
far
as QEMU cares. This includes the TDX Module's FEATURE_PARAVIRT_CTRL, which
fra
On Wed, 2024-12-18 at 18:33 -0800, Sean Christopherson wrote:
> > So that is how I arrived at that we need some list of host affecting bits to
> > verify match in the TD.
>
> At the end of the day, the list is going to be human-generated. For the UX
> side
> of things, it makes sense to push that
On Thu, Dec 19, 2024, Rick P Edgecombe wrote:
> On Tue, 2024-12-17 at 16:08 -0800, Sean Christopherson wrote:
> > On Tue, Dec 17, 2024, Rick P Edgecombe wrote:
> > > Some options discussed on the call:
> > >
> > > 1. If we got a promise to require any new CPUID bits that clobber host
> > > state
On Tue, 2024-12-17 at 16:08 -0800, Sean Christopherson wrote:
> On Tue, Dec 17, 2024, Rick P Edgecombe wrote:
> > It seems like an anti-pattern to have KVM maintaining any code to defend
> > against
> > TDX module changes that could instead be handled with a promise.
>
> I disagree, sanity check
On Tue, Dec 17, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-12-16 at 17:53 -0800, Sean Christopherson wrote:
> > Every new feature that lands in hardware needs to either be "benign" or
> > have the
> > appropriate virtualization controls. KVM already has to deal with cases
> > where
> > feature
On Mon, 2024-12-16 at 17:53 -0800, Sean Christopherson wrote:
> Every new feature that lands in hardware needs to either be "benign" or have
> the
> appropriate virtualization controls. KVM already has to deal with cases where
> features can effectively be used without KVM's knowledge. E.g. ther
On 12/17/2024 9:53 AM, Sean Christopherson wrote:
On Tue, Dec 10, 2024, Rick P Edgecombe wrote:
On Tue, 2024-12-10 at 11:22 +0800, Xiaoyao Li wrote:
The solution in this proposal decreases the work the VMM has to do, but
in the long term won't remove hand coding completely. As long as we are
de
On Tue, Dec 10, 2024, Rick P Edgecombe wrote:
> On Tue, 2024-12-10 at 11:22 +0800, Xiaoyao Li wrote:
> > > The solution in this proposal decreases the work the VMM has to do, but
> > > in the long term won't remove hand coding completely. As long as we are
> > > designing something, what kind of ba
On Tue, 2024-12-10 at 11:22 +0800, Xiaoyao Li wrote:
> > The solution in this proposal decreases the work the VMM has to do, but in
> > the
> > long term won't remove hand coding completely. As long as we are designing
> > something, what kind of bar should we target?
>
> For this specific #VE red
On 12/7/2024 2:41 AM, Edgecombe, Rick P wrote:
On Fri, 2024-12-06 at 10:42 +0800, Xiaoyao Li wrote:
# Interaction with TDX_FEATURES0.VE_REDUCTION
TDX introduces a new feature VE_REDUCTION[2]. From the perspective of
host VMM, VE_REDUCTION turns several CPUID bits from fixed1 to
configurable, e.
On Fri, 2024-12-06 at 10:42 +0800, Xiaoyao Li wrote:
> # Interaction with TDX_FEATURES0.VE_REDUCTION
>
> TDX introduces a new feature VE_REDUCTION[2]. From the perspective of
> host VMM, VE_REDUCTION turns several CPUID bits from fixed1 to
> configurable, e.g., MTRR, MCA, MCE, etc. However, from
This is a proposal for a potential future TDX Module feature to assist
QEMU/KVM in configuring CPUID leafs for TD guests. It is only in the
idea stage and not currently being implemented. We are looking for
comments on the suitability for QEMU/KVM.
# Background
To correctly virtualize CPUID f
13 matches
Mail list logo
