From: Sean Christopherson <seanjc@google.com>
To: Peter Gonda <pgonda@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
marcorr@google.com, michael.roth@amd.com,
thomas.lendacky@amd.com, joro@8bytes.org, mizhang@google.com,
pbonzini@redhat.com, andrew.jones@linux.dev
Subject: Re: [V4 6/8] KVM: selftests: add library for creating/interacting with SEV guests
Date: Wed, 19 Oct 2022 16:34:39 +0000 [thread overview]
Message-ID: <Y1AnHwVtOFShRxQD@google.com> (raw)
In-Reply-To: <CAMkAt6pvT15teuYWjz7r1vmUP5McDp76qjxQ26_oeg5mTnv5NA@mail.gmail.com>
On Tue, Oct 18, 2022, Peter Gonda wrote:
> On Mon, Oct 17, 2022 at 2:34 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Mon, Oct 17, 2022, Peter Gonda wrote:
> > > I think this means we don't need to add VM_MODE_PXXV48_4K_SEV since we
> > > can set up the c-bit from inside of vm_sev_create_*(), thoughts?
> >
> > Configuring the C-bit inside vm_sev_create_*() won't work (at least not well).
> > The C-bit needs to be known before kvm_vm_elf_load(), i.e. can't be handled after
> > __vm_create(), and needs to be tracked inside the VM, i.e. can't be handled before
> > __vm_create().
> >
> > The proposed kvm_init_vm_address_properties() seems like the best fit since the
> > C-bit (and TDX's S-bit) is stolen from GPA space, i.e. directly affects the other
> > values computed in that path.
> >
> > As for the kvm_vm_arch allocation ugliness, when we talked off-list I didn't
> > consider the need to allocate in kvm_init_vm_address_properties(). That's quite
> > gross, especially since the pointer will be larger than the thing being allocated.
> >
> > With that in mind, adding .../include/<arch>/kvm_util.h so that "struct kvm_vm_arch"
> > can be defined and referenced directly doesn't seem so bad. Having to stub in the
> > struct for the other architectures is annoying, but not the end of the world.
>
> I'll make "struct kvm_vm_arch" a non pointer member, so adding
> /include/<arch>/kvm_util.h files.
>
> But I think we do not need VM_MODE_PXXV48_4K_SEV, see:
I really don't want to open code __vm_create() with a slight tweak. E.g. the
below code will be broken by Ricardo's series to add memslot0 is moved out of
____vm_create()[1], and kinda sorta be broken again by Vishal's series to add an
arch hook to __vm_create()[2].
AFAICT, there is no requirement that KVM_SEV_INIT be called before computing the
C-Bit, the only requirement is that KVM_SEV_INIT is called before adding vCPUs.
[1] https://lore.kernel.org/all/20221017195834.2295901-8-ricarkol@google.com
[2] https://lore.kernel.org/all/YzsC4ibDqGh5qaP9@google.com
> struct kvm_vm *vm_sev_create_with_one_vcpu(uint32_t policy, void *guest_code,
> struct kvm_vcpu **cpu)
> {
> enum vm_guest_mode mode = VM_MODE_PXXV48_4K;
> uint64_t nr_pages = vm_nr_pages_required(mode, 1, 0);
> struct kvm_vm *vm;
> uint8_t measurement[512];
> int i;
>
> vm = ____vm_create(mode, nr_pages);
>
> kvm_sev_ioctl(vm, KVM_SEV_INIT, NULL);
>
> configure_sev_pte_masks(vm);
>
> *cpu = vm_vcpu_add(vm, 0, guest_code);
> kvm_vm_elf_load(vm, program_invocation_name);
>
> sev_vm_launch(vm, policy);
>
> /* Dump the initial measurement. A test to actually verify it
> would be nice. */
> sev_vm_launch_measure(vm, measurement);
> pr_info("guest measurement: ");
> for (i = 0; i < 32; ++i)
> pr_info("%02x", measurement[i]);
> pr_info("\n");
>
> sev_vm_launch_finish(vm);
>
> return vm;
> }
next prev parent reply other threads:[~2022-10-19 16:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 17:10 [V4 0/8] KVM: selftests: Add simple SEV test Peter Gonda
2022-08-29 17:10 ` [V4 1/8] KVM: selftests: move vm_phy_pages_alloc() earlier in file Peter Gonda
2022-10-06 17:35 ` Sean Christopherson
2022-08-29 17:10 ` [V4 2/8] KVM: selftests: sparsebit: add const where appropriate Peter Gonda
2022-08-29 17:10 ` [V4 3/8] KVM: selftests: add hooks for managing encrypted guest memory Peter Gonda
2022-10-06 17:48 ` Sean Christopherson
2022-10-11 17:38 ` Peter Gonda
2022-08-29 17:10 ` [V4 4/8] KVM: selftests: handle encryption bits in page tables Peter Gonda
2022-10-06 17:34 ` Sean Christopherson
2022-08-29 17:10 ` [V4 5/8] KVM: selftests: add support for encrypted vm_vaddr_* allocations Peter Gonda
2022-08-29 17:10 ` [V4 6/8] KVM: selftests: add library for creating/interacting with SEV guests Peter Gonda
2022-10-06 18:25 ` Sean Christopherson
2022-10-17 16:32 ` Peter Gonda
2022-10-17 18:04 ` Sean Christopherson
2022-10-17 18:25 ` Peter Gonda
2022-10-17 20:34 ` Sean Christopherson
2022-10-18 14:59 ` Peter Gonda
2022-10-19 16:34 ` Sean Christopherson [this message]
2022-10-27 16:24 ` Peter Gonda
2022-10-27 17:59 ` Sean Christopherson
2022-10-27 18:34 ` Peter Gonda
2022-08-29 17:10 ` [V4 7/8] KVM: selftests: Update ucall pool to allocate from shared memory Peter Gonda
2022-08-29 17:10 ` [V4 8/8] KVM: selftests: Add simple sev vm testing Peter Gonda
2022-10-06 18:31 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1AnHwVtOFShRxQD@google.com \
--to=seanjc@google.com \
--cc=andrew.jones@linux.dev \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcorr@google.com \
--cc=michael.roth@amd.com \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=thomas.lendacky@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).