Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
On Mon, Aug 06, 2018 at 03:05:00PM +0200, Christoffer Dall wrote: > On Thu, Jun 21, 2018 at 03:57:24PM +0100, Dave Martin wrote: > > This series implements basic support for allowing KVM guests to use the > > Arm Scalable Vector Extension (SVE). > > > > The patches is based on torvalds/master f5b7769e (Revert "debugfs: > > inode: debugfs_create_dir uses mode permission from parent") plus the > > patches from [1]. > > Given the effort required to go fetch another patch set from the list to > apply to a specific commit, and the size of this patch set, it would be > helpful to have a pointer to a branch with everything in it. Fair enough. This probably won't be an issue for the next spin, in any case, but I can push a branch somewhere otherwise. Cheers ---Dave ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
On Thu, Jun 21, 2018 at 03:57:24PM +0100, Dave Martin wrote: > This series implements basic support for allowing KVM guests to use the > Arm Scalable Vector Extension (SVE). > > The patches is based on torvalds/master f5b7769e (Revert "debugfs: > inode: debugfs_create_dir uses mode permission from parent") plus the > patches from [1]. Given the effort required to go fetch another patch set from the list to apply to a specific commit, and the size of this patch set, it would be helpful to have a pointer to a branch with everything in it. Thanks, -Christoffer ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
On 6 July 2018 at 11:11, Alex Bennée wrote: > > Peter Maydell writes: > >> On 6 July 2018 at 10:20, Alex Bennée wrote: >>> For the most part in QEMU with KVM we just treat the list of registers >>> we get from the OS as an opaque blob of things we save to memory and >>> pass back. >> >> This is specifically not the case for the SVE registers -- we >> will need extra code to handle them. (The current code only >> allows for the possibility of 64-bit registers, so if we'd >> allowed the kernel to hand it the larger SVE registers it would >> just have fallen over. This is why QEMU needs to specifically >> enable SVE via the VCPU_INIT call.) > > Ahh right. So currently both the KVM_GET_REG_LIST and the core registers > use KVM_GET/SET_ONE_REG which certainly won't do the trick. So I guess > we need another IOCTL (or to enhance the current one) and a KVM > capability bit as well? It is still GET/SET_ONE_REG, but the size of the register (which is encoded in its ID number) is not something the current code will cope with (see the switches on regidx & KVM_REG_SIZE_MASK in write_kvmstate_to_list() and write_list_to_kvmstate()). thanks -- PMM ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
Peter Maydell writes: > On 6 July 2018 at 10:20, Alex Bennée wrote: >> For the most part in QEMU with KVM we just treat the list of registers >> we get from the OS as an opaque blob of things we save to memory and >> pass back. > > This is specifically not the case for the SVE registers -- we > will need extra code to handle them. (The current code only > allows for the possibility of 64-bit registers, so if we'd > allowed the kernel to hand it the larger SVE registers it would > just have fallen over. This is why QEMU needs to specifically > enable SVE via the VCPU_INIT call.) Ahh right. So currently both the KVM_GET_REG_LIST and the core registers use KVM_GET/SET_ONE_REG which certainly won't do the trick. So I guess we need another IOCTL (or to enhance the current one) and a KVM capability bit as well? > > thanks > -- PMM -- Alex Bennée ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
On 6 July 2018 at 10:20, Alex Bennée wrote: > For the most part in QEMU with KVM we just treat the list of registers > we get from the OS as an opaque blob of things we save to memory and > pass back. This is specifically not the case for the SVE registers -- we will need extra code to handle them. (The current code only allows for the possibility of 64-bit registers, so if we'd allowed the kernel to hand it the larger SVE registers it would just have fallen over. This is why QEMU needs to specifically enable SVE via the VCPU_INIT call.) thanks -- PMM ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
Dave Martin writes: > On Fri, Jul 06, 2018 at 09:22:47AM +0100, Alex Bennée wrote: >> >> Dave Martin writes: >> >> >> > >> > This series is somewhat tested on Arm Juno r0 and the Arm Fast Model >> > (with/without SVE support). arch/arm builds, but I've not booted >> > it -- only some trivial refactoring in this series affects arch/arm. >> >> Now that QEMU linux-user SVE support is pretty much complete we've also >> got preliminary patches for system emulation mode. However we currently >> don't have VHE implemented so I guess we need to do that first before we >> can test under QEMU. > > Qemu can use this as a KVM client without invasive changes, right? Yeah for KVM use there aren't really any changes. > For kvmtool, it's just a question of checking/setting a feature flag > in KVM_ARM_PREFERRED_TARGET and KVM_ARM_VCPU_INIT, and (eventually) > doing at ioctl() to set the set of permitted vector lengths (not yet, > this will come in a follow-up series). For the most part in QEMU with KVM we just treat the list of registers we get from the OS as an opaque blob of things we save to memory and pass back. The CPU features code will probably need a bit of tweaking but it will be minor. I'm not sure what the current status of cross-host CPU migration is at the moment - that was mostly Christopher's headache to track ;-) For things like gdbstub we need to add additional handling. I suspect as we currently don't explicitly handle the SVE registers they won't show up - I believe there are protocol updates for better handling these registers coming. I think migration should work out of the box but I'd need to double check. Certainly its a strong argument for getting VHE done in TCG mode as we can exercise a lot of the common code. > > Cheers > ---Dave -- Alex Bennée ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
On Fri, Jul 06, 2018 at 09:22:47AM +0100, Alex Bennée wrote: > > Dave Martin writes: > > > > > > This series is somewhat tested on Arm Juno r0 and the Arm Fast Model > > (with/without SVE support). arch/arm builds, but I've not booted > > it -- only some trivial refactoring in this series affects arch/arm. > > Now that QEMU linux-user SVE support is pretty much complete we've also > got preliminary patches for system emulation mode. However we currently > don't have VHE implemented so I guess we need to do that first before we > can test under QEMU. Qemu can use this as a KVM client without invasive changes, right? For kvmtool, it's just a question of checking/setting a feature flag in KVM_ARM_PREFERRED_TARGET and KVM_ARM_VCPU_INIT, and (eventually) doing at ioctl() to set the set of permitted vector lengths (not yet, this will come in a follow-up series). Cheers ---Dave ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [RFC PATCH 00/16] KVM: arm64: Initial support for SVE guests
Dave Martin writes:
>
> This series is somewhat tested on Arm Juno r0 and the Arm Fast Model
> (with/without SVE support). arch/arm builds, but I've not booted
> it -- only some trivial refactoring in this series affects arch/arm.
Now that QEMU linux-user SVE support is pretty much complete we've also
got preliminary patches for system emulation mode. However we currently
don't have VHE implemented so I guess we need to do that first before we
can test under QEMU.
>
> Cheers
> ---Dave
>
>
> [1] [PATCH v2 0/4] KVM: arm64: FPSIMD/SVE fixes for 4.17 [sic]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/584281.html
>
> Dave Martin (16):
> arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush
> KVM: arm64: Delete orphaned declaration for __fpsimd_enabled()
> KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance
> KVM: arm64: Add missing #include of to kvm_host.h
> KVM: arm: Add arch init/uninit hooks
> arm64/sve: Determine virtualisation-friendly vector lengths
> arm64/sve: Enable SVE state tracking for non-task contexts
> KVM: arm64: Support dynamically hideable system registers
> KVM: arm64: Allow ID registers to by dynamically read-as-zero
> KVM: arm64: Add a vcpu flag to control SVE visibility for the guest
> KVM: arm64/sve: System register context switch and access support
> KVM: arm64/sve: Context switch the SVE registers
> KVM: Allow 2048-bit register access via KVM_{GET,SET}_ONE_REG
> KVM: arm64/sve: Add SVE support to register access ioctl interface
> KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST
> KVM: arm64/sve: Report and enable SVE API extensions for userspace
>
> arch/arm/include/asm/kvm_host.h | 4 +-
> arch/arm64/include/asm/fpsimd.h | 4 +-
> arch/arm64/include/asm/kvm_host.h | 18 ++-
> arch/arm64/include/asm/kvm_hyp.h | 1 -
> arch/arm64/include/asm/sysreg.h | 3 +
> arch/arm64/include/uapi/asm/kvm.h | 11 ++
> arch/arm64/kernel/cpufeature.c| 2 +-
> arch/arm64/kernel/fpsimd.c| 131 +---
> arch/arm64/kernel/signal.c| 5 -
> arch/arm64/kvm/fpsimd.c | 7 +-
> arch/arm64/kvm/guest.c| 321
> +++---
> arch/arm64/kvm/hyp/switch.c | 43 +++--
> arch/arm64/kvm/hyp/sysreg-sr.c| 5 +
> arch/arm64/kvm/reset.c| 14 ++
> arch/arm64/kvm/sys_regs.c | 73 ++---
> arch/arm64/kvm/sys_regs.h | 22 +++
> include/uapi/linux/kvm.h | 1 +
> virt/kvm/arm/arm.c| 13 +-
> 18 files changed, 587 insertions(+), 91 deletions(-)
--
Alex Bennée
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
