| Message ID | 20240603131141.834241-4-pbonzini@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | update-linux-headers: prepare for updating to 6.9+ and for SNP patches | expand |
On Mon, Jun 03 2024, Paolo Bonzini <pbonzini@redhat.com> wrote: > From: Pankaj Gupta <pankaj.gupta@amd.com> > > Also brings in an linux-headers/linux/vhost.h fix from v6.9-rc4. > > Co-developed-by: Michael Roth <michael.roth@amd.com> > Signed-off-by: Michael Roth <michael.roth@amd.com> > Signed-off-by: Pankaj Gupta <pankaj.gupta@amd.com> > Message-ID: <20240530111643.1091816-3-pankaj.gupta@amd.com> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > linux-headers/asm-loongarch/kvm.h | 4 +++ > linux-headers/asm-riscv/kvm.h | 1 + > linux-headers/asm-x86/kvm.h | 52 ++++++++++++++++++++++++++++++- > linux-headers/linux/vhost.h | 15 ++++----- > 4 files changed, 64 insertions(+), 8 deletions(-) Hm, I'm not sure updating to kvm/next is a good idea ("current kvm/next" does not mean anything without a commit hash anyway.) I think we should only update to something that's in Linus' tree already... how stable is kvm/next?
On Mon, Jun 3, 2024 at 5:58 PM Cornelia Huck <cohuck@redhat.com> wrote: > Hm, I'm not sure updating to kvm/next is a good idea ("current kvm/next" > does not mean anything without a commit hash anyway.) I think we should > only update to something that's in Linus' tree already... how stable is > kvm/next? It is stable, things are only applied there once UAPI is set. Even rebasing is very rare. The problem here is that if (as is the case for 6.11) the merge window only opens once QEMU is in freeze, waiting for it would delay merging the QEMU side by 4 months. In this case, the patches barely missed 6.10. Paolo
On Mon, Jun 03 2024, Paolo Bonzini <pbonzini@redhat.com> wrote: > On Mon, Jun 3, 2024 at 5:58 PM Cornelia Huck <cohuck@redhat.com> wrote: >> Hm, I'm not sure updating to kvm/next is a good idea ("current kvm/next" >> does not mean anything without a commit hash anyway.) I think we should >> only update to something that's in Linus' tree already... how stable is >> kvm/next? > > It is stable, things are only applied there once UAPI is set. Even > rebasing is very rare. > > The problem here is that if (as is the case for 6.11) the merge window > only opens once QEMU is in freeze, waiting for it would delay merging > the QEMU side by 4 months. In this case, the patches barely missed > 6.10. If we're confident that it's stable, can we please mention a hash? "current" is not very descriptive :)
On Mon, Jun 3, 2024 at 6:25 PM Cornelia Huck <cohuck@redhat.com> wrote: > > On Mon, Jun 03 2024, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On Mon, Jun 3, 2024 at 5:58 PM Cornelia Huck <cohuck@redhat.com> wrote: > >> Hm, I'm not sure updating to kvm/next is a good idea ("current kvm/next" > >> does not mean anything without a commit hash anyway.) I think we should > >> only update to something that's in Linus' tree already... how stable is > >> kvm/next? > > > > It is stable, things are only applied there once UAPI is set. Even > > rebasing is very rare. > > > > The problem here is that if (as is the case for 6.11) the merge window > > only opens once QEMU is in freeze, waiting for it would delay merging > > the QEMU side by 4 months. In this case, the patches barely missed > > 6.10. > > If we're confident that it's stable, can we please mention a hash? Sure, it's commit 6f627b425378915b6eda30908bedefc21b70b8c4. Paolo > "current" is not very descriptive :) >
diff --git a/linux-headers/asm-loongarch/kvm.h b/linux-headers/asm-loongarch/kvm.h index 109785922cf..f9abef38231 100644 --- a/linux-headers/asm-loongarch/kvm.h +++ b/linux-headers/asm-loongarch/kvm.h @@ -17,6 +17,8 @@ #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 #define KVM_DIRTY_LOG_PAGE_OFFSET 64 +#define KVM_GUESTDBG_USE_SW_BP 0x00010000 + /* * for KVM_GET_REGS and KVM_SET_REGS */ @@ -72,6 +74,8 @@ struct kvm_fpu { #define KVM_REG_LOONGARCH_COUNTER (KVM_REG_LOONGARCH_KVM | KVM_REG_SIZE_U64 | 1) #define KVM_REG_LOONGARCH_VCPU_RESET (KVM_REG_LOONGARCH_KVM | KVM_REG_SIZE_U64 | 2) +/* Debugging: Special instruction for software breakpoint */ +#define KVM_REG_LOONGARCH_DEBUG_INST (KVM_REG_LOONGARCH_KVM | KVM_REG_SIZE_U64 | 3) #define LOONGARCH_REG_SHIFT 3 #define LOONGARCH_REG_64(TYPE, REG) (TYPE | KVM_REG_SIZE_U64 | (REG << LOONGARCH_REG_SHIFT)) diff --git a/linux-headers/asm-riscv/kvm.h b/linux-headers/asm-riscv/kvm.h index b1c503c2959..e878e7cc397 100644 --- a/linux-headers/asm-riscv/kvm.h +++ b/linux-headers/asm-riscv/kvm.h @@ -167,6 +167,7 @@ enum KVM_RISCV_ISA_EXT_ID { KVM_RISCV_ISA_EXT_ZFA, KVM_RISCV_ISA_EXT_ZTSO, KVM_RISCV_ISA_EXT_ZACAS, + KVM_RISCV_ISA_EXT_SSCOFPMF, KVM_RISCV_ISA_EXT_MAX, }; diff --git a/linux-headers/asm-x86/kvm.h b/linux-headers/asm-x86/kvm.h index 31c95c2dfe4..1c8f9182348 100644 --- a/linux-headers/asm-x86/kvm.h +++ b/linux-headers/asm-x86/kvm.h @@ -695,6 +695,11 @@ enum sev_cmd_id { /* Second time is the charm; improved versions of the above ioctls. */ KVM_SEV_INIT2, + /* SNP-specific commands */ + KVM_SEV_SNP_LAUNCH_START = 100, + KVM_SEV_SNP_LAUNCH_UPDATE, + KVM_SEV_SNP_LAUNCH_FINISH, + KVM_SEV_NR_MAX, }; @@ -709,7 +714,9 @@ struct kvm_sev_cmd { struct kvm_sev_init { __u64 vmsa_features; __u32 flags; - __u32 pad[9]; + __u16 ghcb_version; + __u16 pad1; + __u32 pad2[8]; }; struct kvm_sev_launch_start { @@ -820,6 +827,48 @@ struct kvm_sev_receive_update_data { __u32 pad2; }; +struct kvm_sev_snp_launch_start { + __u64 policy; + __u8 gosvw[16]; + __u16 flags; + __u8 pad0[6]; + __u64 pad1[4]; +}; + +/* Kept in sync with firmware values for simplicity. */ +#define KVM_SEV_SNP_PAGE_TYPE_NORMAL 0x1 +#define KVM_SEV_SNP_PAGE_TYPE_ZERO 0x3 +#define KVM_SEV_SNP_PAGE_TYPE_UNMEASURED 0x4 +#define KVM_SEV_SNP_PAGE_TYPE_SECRETS 0x5 +#define KVM_SEV_SNP_PAGE_TYPE_CPUID 0x6 + +struct kvm_sev_snp_launch_update { + __u64 gfn_start; + __u64 uaddr; + __u64 len; + __u8 type; + __u8 pad0; + __u16 flags; + __u32 pad1; + __u64 pad2[4]; +}; + +#define KVM_SEV_SNP_ID_BLOCK_SIZE 96 +#define KVM_SEV_SNP_ID_AUTH_SIZE 4096 +#define KVM_SEV_SNP_FINISH_DATA_SIZE 32 + +struct kvm_sev_snp_launch_finish { + __u64 id_block_uaddr; + __u64 id_auth_uaddr; + __u8 id_block_en; + __u8 auth_key_en; + __u8 vcek_disabled; + __u8 host_data[KVM_SEV_SNP_FINISH_DATA_SIZE]; + __u8 pad0[3]; + __u16 flags; + __u64 pad1[4]; +}; + #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) @@ -870,5 +919,6 @@ struct kvm_hyperv_eventfd { #define KVM_X86_SW_PROTECTED_VM 1 #define KVM_X86_SEV_VM 2 #define KVM_X86_SEV_ES_VM 3 +#define KVM_X86_SNP_VM 4 #endif /* _ASM_X86_KVM_H */ diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h index bea69739061..b95dd84eef2 100644 --- a/linux-headers/linux/vhost.h +++ b/linux-headers/linux/vhost.h @@ -179,12 +179,6 @@ /* Get the config size */ #define VHOST_VDPA_GET_CONFIG_SIZE _IOR(VHOST_VIRTIO, 0x79, __u32) -/* Get the count of all virtqueues */ -#define VHOST_VDPA_GET_VQS_COUNT _IOR(VHOST_VIRTIO, 0x80, __u32) - -/* Get the number of virtqueue groups. */ -#define VHOST_VDPA_GET_GROUP_NUM _IOR(VHOST_VIRTIO, 0x81, __u32) - /* Get the number of address spaces. */ #define VHOST_VDPA_GET_AS_NUM _IOR(VHOST_VIRTIO, 0x7A, unsigned int) @@ -228,10 +222,17 @@ #define VHOST_VDPA_GET_VRING_DESC_GROUP _IOWR(VHOST_VIRTIO, 0x7F, \ struct vhost_vring_state) + +/* Get the count of all virtqueues */ +#define VHOST_VDPA_GET_VQS_COUNT _IOR(VHOST_VIRTIO, 0x80, __u32) + +/* Get the number of virtqueue groups. */ +#define VHOST_VDPA_GET_GROUP_NUM _IOR(VHOST_VIRTIO, 0x81, __u32) + /* Get the queue size of a specific virtqueue. * userspace set the vring index in vhost_vring_state.index * kernel set the queue size in vhost_vring_state.num */ -#define VHOST_VDPA_GET_VRING_SIZE _IOWR(VHOST_VIRTIO, 0x80, \ +#define VHOST_VDPA_GET_VRING_SIZE _IOWR(VHOST_VIRTIO, 0x82, \ struct vhost_vring_state) #endif