From: Oliver Upton <oupton@google.com> To: Gavin Shan <gshan@redhat.com> Cc: kvmarm@lists.cs.columbia.edu, maz@kernel.org, linux-kernel@vger.kernel.org, eauger@redhat.com, shan.gavin@gmail.com, Jonathan.Cameron@huawei.com, pbonzini@redhat.com, vkuznets@redhat.com, will@kernel.org Subject: Re: [PATCH v5 19/22] KVM: arm64: Support SDEI ioctl commands on vCPU Date: Wed, 23 Mar 2022 17:55:10 +0000 [thread overview] Message-ID: <Yjte/g4yG+gw7vnt@google.com> (raw) In-Reply-To: <20220322080710.51727-20-gshan@redhat.com> On Tue, Mar 22, 2022 at 04:07:07PM +0800, Gavin Shan wrote: > This supports ioctl commands on vCPU to manage the various object. > It's primarily used by VMM to accomplish migration. The ioctl > commands introduced by this are highlighted as below: > > * KVM_SDEI_CMD_GET_VCPU_EVENT_COUNT > Return the total count of vCPU events, which have been queued > on the target vCPU. > > * KVM_SDEI_CMD_GET_VCPU_EVENT > * KVM_SDEI_CMD_SET_VCPU_EVENT > Get or set vCPU events. > > * KVM_SDEI_CMD_GET_VCPU_STATE > * KVM_SDEI_CMD_SET_VCPU_STATE > Get or set vCPU state. All of this GET/SET stuff can probably be added to KVM_{GET,SET}_ONE_REG immediately. Just introduce new registers any time a new event comes along. The only event we have at the end of this series is the software-signaled event, with async PF coming later right? Some special consideration is likely necessary to avoid adding a register for every u64 chunk of data. I don't think we need to afford userspace any illusion of granularity with these, and can probably lump it all under one giant pseudoregister. > * KVM_SDEI_CMD_INJECT_EVENT > Inject SDEI event. What events are we going to allow userspace to inject? IIUC, the software-signaled event is an IPI and really under the control of the guest. Async PF is entriely under KVM control. I do agree that having some form of event injection would be great. VM providers have found it useful to allow users to NMI their VMs when they get wedged. I just believe that userspace should not be able to trigger events that have a defined meaning and are under full KVM ownership. IMO, unless the async PF changes need to go out to userspace, you could probably skip event injection for now and only worry about SDEI within a VM. -- Thanks, Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Upton <oupton@google.com> To: Gavin Shan <gshan@redhat.com> Cc: maz@kernel.org, linux-kernel@vger.kernel.org, eauger@redhat.com, shan.gavin@gmail.com, Jonathan.Cameron@huawei.com, pbonzini@redhat.com, vkuznets@redhat.com, will@kernel.org, kvmarm@lists.cs.columbia.edu Subject: Re: [PATCH v5 19/22] KVM: arm64: Support SDEI ioctl commands on vCPU Date: Wed, 23 Mar 2022 17:55:10 +0000 [thread overview] Message-ID: <Yjte/g4yG+gw7vnt@google.com> (raw) In-Reply-To: <20220322080710.51727-20-gshan@redhat.com> On Tue, Mar 22, 2022 at 04:07:07PM +0800, Gavin Shan wrote: > This supports ioctl commands on vCPU to manage the various object. > It's primarily used by VMM to accomplish migration. The ioctl > commands introduced by this are highlighted as below: > > * KVM_SDEI_CMD_GET_VCPU_EVENT_COUNT > Return the total count of vCPU events, which have been queued > on the target vCPU. > > * KVM_SDEI_CMD_GET_VCPU_EVENT > * KVM_SDEI_CMD_SET_VCPU_EVENT > Get or set vCPU events. > > * KVM_SDEI_CMD_GET_VCPU_STATE > * KVM_SDEI_CMD_SET_VCPU_STATE > Get or set vCPU state. All of this GET/SET stuff can probably be added to KVM_{GET,SET}_ONE_REG immediately. Just introduce new registers any time a new event comes along. The only event we have at the end of this series is the software-signaled event, with async PF coming later right? Some special consideration is likely necessary to avoid adding a register for every u64 chunk of data. I don't think we need to afford userspace any illusion of granularity with these, and can probably lump it all under one giant pseudoregister. > * KVM_SDEI_CMD_INJECT_EVENT > Inject SDEI event. What events are we going to allow userspace to inject? IIUC, the software-signaled event is an IPI and really under the control of the guest. Async PF is entriely under KVM control. I do agree that having some form of event injection would be great. VM providers have found it useful to allow users to NMI their VMs when they get wedged. I just believe that userspace should not be able to trigger events that have a defined meaning and are under full KVM ownership. IMO, unless the async PF changes need to go out to userspace, you could probably skip event injection for now and only worry about SDEI within a VM. -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2022-03-23 17:55 UTC|newest] Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-22 8:06 [PATCH v5 00/22] Support SDEI Virtualization Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 01/22] KVM: arm64: Introduce template for inline functions Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 19:42 ` Oliver Upton 2022-03-22 19:42 ` Oliver Upton 2022-03-23 12:16 ` Gavin Shan 2022-03-23 12:16 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 02/22] KVM: arm64: Add SDEI virtualization infrastructure Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 22:43 ` Oliver Upton 2022-03-22 22:43 ` Oliver Upton 2022-03-23 12:40 ` Gavin Shan 2022-03-23 12:40 ` Gavin Shan 2022-03-23 17:11 ` Oliver Upton 2022-03-23 17:11 ` Oliver Upton 2022-03-24 6:54 ` Gavin Shan 2022-03-24 6:54 ` Gavin Shan 2022-03-24 9:04 ` Oliver Upton 2022-03-24 9:04 ` Oliver Upton 2022-03-25 6:07 ` Gavin Shan 2022-03-25 6:07 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 03/22] KVM: arm64: Support SDEI_VERSION hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 18:04 ` Oliver Upton 2022-03-22 18:04 ` Oliver Upton 2022-03-23 12:46 ` Gavin Shan 2022-03-23 12:46 ` Gavin Shan 2022-03-23 16:31 ` Oliver Upton 2022-03-23 16:31 ` Oliver Upton 2022-03-24 4:07 ` Gavin Shan 2022-03-24 4:07 ` Gavin Shan 2022-03-24 7:48 ` Oliver Upton 2022-03-24 7:48 ` Oliver Upton 2022-03-25 6:11 ` Gavin Shan 2022-03-25 6:11 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 04/22] KVM: arm64: Support SDEI_EVENT_REGISTER hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 05/22] KVM: arm64: Support SDEI_EVENT_{ENABLE, DISABLE} hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 06/22] KVM: arm64: Support SDEI_EVENT_CONTEXT hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 07/22] KVM: arm64: Support SDEI_EVENT_UNREGISTER hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 08/22] KVM: arm64: Support SDEI_EVENT_STATUS hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 09/22] KVM: arm64: Support SDEI_EVENT_GET_INFO hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 10/22] KVM: arm64: Support SDEI_EVENT_ROUTING_SET hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:06 ` [PATCH v5 11/22] KVM: arm64: Support SDEI_PE_{MASK, UNMASK} hypercall Gavin Shan 2022-03-22 8:06 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 12/22] KVM: arm64: Support SDEI_{PRIVATE, SHARED}_RESET Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 13/22] KVM: arm64: Support SDEI_FEATURES hypercall Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 14/22] KVM: arm64: Support SDEI event injection, delivery and cancellation Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 15/22] KVM: arm64: Support SDEI_EVENT_SIGNAL hypercall Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 23:06 ` Oliver Upton 2022-03-22 23:06 ` Oliver Upton 2022-03-23 12:52 ` Gavin Shan 2022-03-23 12:52 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 16/22] KVM: arm64: Support SDEI_EVENT_{COMPLETE,COMPLETE_AND_RESUME} hypercall Gavin Shan 2022-03-22 8:07 ` [PATCH v5 16/22] KVM: arm64: Support SDEI_EVENT_{COMPLETE, COMPLETE_AND_RESUME} hypercall Gavin Shan 2022-03-22 8:07 ` [PATCH v5 17/22] KVM: arm64: Support SDEI event notifier Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 18/22] KVM: arm64: Support SDEI ioctl commands on VM Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-23 17:28 ` Oliver Upton 2022-03-23 17:28 ` Oliver Upton 2022-03-25 6:59 ` Gavin Shan 2022-03-25 6:59 ` Gavin Shan 2022-03-25 7:35 ` Oliver Upton 2022-03-25 7:35 ` Oliver Upton 2022-03-25 10:14 ` Gavin Shan 2022-03-25 10:14 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 19/22] KVM: arm64: Support SDEI ioctl commands on vCPU Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-23 17:55 ` Oliver Upton [this message] 2022-03-23 17:55 ` Oliver Upton 2022-03-25 7:59 ` Gavin Shan 2022-03-25 7:59 ` Gavin Shan 2022-03-25 8:37 ` Oliver Upton 2022-03-25 8:37 ` Oliver Upton 2022-03-25 10:23 ` Gavin Shan 2022-03-25 10:23 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 20/22] KVM: arm64: Export SDEI capability Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 21/22] KVM: arm64: Add SDEI document Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 8:07 ` [PATCH v5 22/22] KVM: selftests: Add SDEI test case Gavin Shan 2022-03-22 8:07 ` Gavin Shan 2022-03-22 18:13 ` [PATCH v5 00/22] Support SDEI Virtualization Oliver Upton 2022-03-22 18:13 ` Oliver Upton 2022-03-23 12:57 ` Gavin Shan 2022-03-23 12:57 ` Gavin Shan
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=Yjte/g4yG+gw7vnt@google.com \ --to=oupton@google.com \ --cc=Jonathan.Cameron@huawei.com \ --cc=eauger@redhat.com \ --cc=gshan@redhat.com \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-kernel@vger.kernel.org \ --cc=maz@kernel.org \ --cc=pbonzini@redhat.com \ --cc=shan.gavin@gmail.com \ --cc=vkuznets@redhat.com \ --cc=will@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.