Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 27 Apr 2023 08:51:03 -0700
In-Reply-To: <CAGtprH_-i15UpM-f3p_g-+GgnK87kUbMa1RpvwGDBRr34XzTuQ@mail.gmail.com>
Mime-Version: 1.0
References: <c49aa7b7bbc016b6c8b698ac2ce3b9d866b551f9.1678643052.git.isaku.yamahata@intel.com>
 <20230418190904.1111011-1-vannapurve@google.com> <20230419133841.00001ee8.zhi.wang.linux@gmail.com>
 <CAGtprH_-i15UpM-f3p_g-+GgnK87kUbMa1RpvwGDBRr34XzTuQ@mail.gmail.com>
Message-ID: <ZEqZ5w7EvzUc8Siv@google.com>
Subject: Re: [PATCH v13 098/113] KVM: TDX: Handle TDX PV map_gpa hypercall
From:   Sean Christopherson <seanjc@google.com>
To:     Vishal Annapurve <vannapurve@google.com>
Cc:     Zhi Wang <zhi.wang.linux@gmail.com>, isaku.yamahata@intel.com,
        dmatlack@google.com, erdemaktas@google.com,
        isaku.yamahata@gmail.com, kai.huang@intel.com, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, pbonzini@redhat.com, sagis@google.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Apr 26, 2023, Vishal Annapurve wrote:
> On Wed, Apr 19, 2023 at 3:38=E2=80=AFAM Zhi Wang <zhi.wang.linux@gmail.co=
m> wrote:
> >
> > On Tue, 18 Apr 2023 19:09:04 +0000
> > Vishal Annapurve <vannapurve@google.com> wrote:
> >
> > > > +static int tdx_map_gpa(struct kvm_vcpu *vcpu)
> > > > +{
> > > > +   struct kvm *kvm =3D vcpu->kvm;
> > > > +   gpa_t gpa =3D tdvmcall_a0_read(vcpu);
> > > > +   gpa_t size =3D tdvmcall_a1_read(vcpu);
> > > > +   gpa_t end =3D gpa + size;
> > > > +
> > > > +   if (!IS_ALIGNED(gpa, PAGE_SIZE) || !IS_ALIGNED(size, PAGE_SIZE)=
 ||
> > > > +       end < gpa ||
> > > > +       end > kvm_gfn_shared_mask(kvm) << (PAGE_SHIFT + 1) ||
> > > > +       kvm_is_private_gpa(kvm, gpa) !=3D kvm_is_private_gpa(kvm, e=
nd)) {
> > > > +           tdvmcall_set_return_code(vcpu, TDG_VP_VMCALL_INVALID_OP=
ERAND);
> > > > +           return 1;
> > > > +   }
> > > > +
> > > > +   return tdx_vp_vmcall_to_user(vcpu);
> > >
> > > This will result into exits to userspace for MMIO regions as well. Do=
es it make
> > > sense to only exit to userspace for guest physical memory regions bac=
ked by
> > > memslots?

No, KVM should exit always, e.g. userspace _could_ choose to create a priva=
te
memslot in response to the guest's request.

> > I think this is necessary as when passing a PCI device to a TD, the gue=
st
> > needs to convert a MMIO region from private to shared, which is not bac=
ked
> > by memslots.

This isn't entirely accurate.  If you're talking about emulated MMIO, then =
there
is no memslot.  But the "passing a PCI device" makes it sound like you're t=
alking
about device passthrough, in which case there is a memslot that points at a=
n actual
MMIO region in the host platform.

In either case, conversions should be unnecessary as MMIO regions should no=
t be
enumerated to the guest as supporting encryption, i.e. the guest should kno=
w from
time zero that those regions are shared.  If we end up with something like =
Hyper-V's
SVSM-based paravisor, then there might be private emulated MMIO, but such a=
 setup
would also come with its own brand of enlightment in the guest.

> KVM could internally handle conversion of regions not backed by

No, KVM should never internally handle conversions, at least not in the ini=
tial
implementation.  And if KVM ever does go down this route, it needs dedicate=
d
support in KVM's uAPI since userspace needs to be kept in the loop, i.e. ne=
eds
to opt-in and be notified of any conversions.