On Tue, Apr 20, 2021, Ashish Kalra wrote:
> On Tue, Apr 20, 2021 at 05:31:07PM +0000, Sean Christopherson wrote:
> > On Tue, Apr 20, 2021, Paolo Bonzini wrote:
> > > + case KVM_HC_PAGE_ENC_STATUS: {
> > > + u64 gpa = a0, npages = a1, enc = a2;
> > > +
> > > + ret = -KVM_ENOSYS;
> > > + if (!vcpu->kvm->arch.hypercall_exit_enabled)
> >
> > I don't follow, why does the hypercall need to be gated by a capability? What
> > would break if this were changed to?
> >
> > if (!guest_pv_has(vcpu, KVM_FEATURE_HC_PAGE_ENC_STATUS))
> >
>
> But, the above indicates host support for page_enc_status_hc, so we want
> to ensure that host supports and has enabled support for the hypercall
> exit, i.e., hypercall has been enabled.
I still don't see how parroting back KVM_GET_SUPPORTED_CPUID, i.e. "unintentionally"
setting KVM_FEATURE_HC_PAGE_ENC_STATUS, would break anything. Sure, the guest
does unnecessary hypercalls, but they're eaten by KVM. On the flip side, gating
the hypercall on the capability, and especially only the capability, creates
weird scenarios where the guest can observe KVM_FEATURE_HC_PAGE_ENC_STATUS=1
but fail the hypercall. Those would be fairly clearcut VMM bugs, but at the
same time KVM is essentially going out of its way to manufacture the problem.
