[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yk73ta7nwuI1NnlC@google.com>
Date: Thu, 7 Apr 2022 14:39:49 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Kai Huang <kai.huang@...el.com>, isaku.yamahata@...el.com,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
isaku.yamahata@...il.com, Jim Mattson <jmattson@...gle.com>,
erdemaktas@...gle.com, Connor Kuehl <ckuehl@...hat.com>
Subject: Re: [RFC PATCH v5 089/104] KVM: TDX: Add a placeholder for handler
of TDX hypercalls (TDG.VP.VMCALL)
On Thu, Apr 07, 2022, Paolo Bonzini wrote:
> On 4/7/22 06:15, Kai Huang wrote:
> > > +static int handle_tdvmcall(struct kvm_vcpu *vcpu)
> > > +{
> > > + struct vcpu_tdx *tdx = to_tdx(vcpu);
> > > +
> > > + if (unlikely(tdx->tdvmcall.xmm_mask))
> > > + goto unsupported;
> > Put a comment explaining this logic?
> >
>
> This only seems to be necessary for Hyper-V hypercalls, which however are
> not supported by this series in TDX guests (because the kvm_hv_hypercall
> still calls kvm_*_read, likewise for Xen).
>
> So for now this conditional can be dropped.
I'd prefer to keep the sanity check, it's a cheap and easy way to detect a clear
cut guest bug. E.g. KVM would be within its rights to write garbage the XMM
registers in this case. Even though KVM isn't to be trusted, KVM can still be
nice to the guest.
Powered by blists - more mailing lists