Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/dev/nvmm/x86
hi,
On Wed, Jul 15, 2026 at 10:22 AM Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
>
> Module Name: src
> Committed By: riastradh
> Date: Wed Jul 15 01:22:21 UTC 2026
>
> Modified Files:
> src/sys/dev/nvmm/x86: nvmm_x86.c nvmm_x86.h nvmm_x86_svm.c
> nvmm_x86_vmx.c
>
> Log Message:
> nvmm: Add support for extended CPU state (XSAVE) beyond x87/SSE.
i have been using a similar patch for a while. but i haven't committed
it because
i was not happy to implement cpuid emulation bits in kernel like this.
it's simpler to make qemu provide them via NVMM_VCPU_CONF_CPUID
or something similar. (in addition to xcr0)
cpuid emulation is quite complex and will likely be more complex in future.
it's better to leverage what qemu already has.
what do you think?
>
> New machine-dependent x86 vCPU configuration command
> NVMM_VCPU_CONF_XCR0_MASK sets the vCPU's XCR0 mask, that is, the set
> of XSAVE features that the guest sees as supported in the vCPU. This
> command is advertised by the new machine capability
> NVMM_CAP_ARCH_VCPU_CONF_XCR0_MASK. (Changing the XCR0 mask after the
> guest has begun execution will clear all extended CPU state for now;
> it is unlikely that hypervisor software will do this anyway.)
>
> This change doesn't expose the XSAVE area to userland in the comm
> page -- there are already machine-independent members in struct
> nvmm_comm_page at fixed offsets past the machine-dependent state so
> we can't just extend struct nvmm_vcpu_state without breaking the ABI.
> And the XSAVE area may exceed a page, but the address space for the
> virtual machine uvm object packs comm areas in consecutive pages, so
> we can't put it in the comm page at all without breaking the ABI
> another way.
>
> Instead, we can expose the XSAVE area in another location in the
> virtual machine uvm object, and create an ioctl for querying its
> object address and size so userland can mmap it. TBD.
i was thinking of having a new NVMM_IOC_VCPU_xxx to get the extra MD state.
>
> Note: Have not tested this on CPUs with VMX/SVM but not XSAVE, or on
> CPUs with AVX-512 or AMX/ACE. In principle the code should support
> them but we need some practice to trip over the difference between
> principle and practice.
>
> PR port-amd64/59860: nvmm: support AVX2, AVX512, &c.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.24 -r1.25 src/sys/dev/nvmm/x86/nvmm_x86.c
> cvs rdiff -u -r1.21 -r1.22 src/sys/dev/nvmm/x86/nvmm_x86.h
> cvs rdiff -u -r1.95 -r1.96 src/sys/dev/nvmm/x86/nvmm_x86_svm.c \
> src/sys/dev/nvmm/x86/nvmm_x86_vmx.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
Home |
Main Index |
Thread Index |
Old Index