[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAH4kHZ_A7-dNyMiyrZ2p46te=Xi7SRosS_kSjYvG6sJTcmb7A@mail.gmail.com>
Date: Tue, 19 Nov 2024 20:54:12 -0800
From: Dionna Amalie Glaze <dionnaglaze@...gle.com>
To: Michael Roth <michael.roth@....com>
Cc: kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
linux-kernel@...r.kernel.org, x86@...nel.org, pbonzini@...hat.com,
seanjc@...gle.com, jroedel@...e.de, thomas.lendacky@....com,
pgonda@...gle.com, ashish.kalra@....com, bp@...en8.de, pankaj.gupta@....com,
liam.merwick@...cle.com
Subject: Re: [PATCH v2 1/2] KVM: Introduce KVM_EXIT_COCO exit type
On Tue, Nov 19, 2024 at 5:51 AM Michael Roth <michael.roth@....com> wrote:
>
> +struct kvm_exit_coco {
> +#define KVM_EXIT_COCO_REQ_CERTS 0
> +#define KVM_EXIT_COCO_MAX 1
> + __u8 nr;
> + __u8 pad0[7];
> + __u32 ret;
> + __u32 pad1;
> + union {
> + struct {
> + __u64 gfn;
> + __u32 npages;
Should this not also include a vmm_err code to report to the guest? We
need some way for user space to indicate that KVM should write the
vmm_err to the upper 32 bits of exit_info_2.
I don't think we have a snapshot of the GHCB accessible to userspace.
I'm still not quite able to get a good test of this patch series
ready. Making the certificate file accessible to the VMM process has
been unfortunately challenging due to how we manage chroots and VMM
upgrades.
Still, I'm stuck in the VMM implementation of grabbing the file lock
for the certificates and asking myself "how do I tell KVM to write
exit_info_2 = (2 << 32) | (exit_info_2 & ((1 << 32)-1) before entering
the guest?"
A __u32 vmm_err field of this struct would nicely make its size 64-bit aligned..
--
-Dionna Glaze, PhD, CISSP, CCSP (she/her)
Powered by blists - more mailing lists