From: Gavin Shan <gshan@redhat.com>
To: Oliver Upton <oupton@google.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: Fri, 25 Mar 2022 18:23:14 +0800 [thread overview]
Message-ID: <ac9a870d-e3bc-e86b-43e0-2e10a883aa2d@redhat.com> (raw)
In-Reply-To: <Yj1/Y5ql0d0h39rX@google.com>
Hi Oliver,
On 3/25/22 4:37 PM, Oliver Upton wrote:
> On Fri, Mar 25, 2022 at 03:59:50PM +0800, Gavin Shan wrote:
>> On 3/24/22 1:55 AM, Oliver Upton wrote:
>>> 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.
>>>
>>
>> Yes, KVM_{GET,SET}_ONE_REG is the ideal interface for migration. You're
>> correct we're only concerned by software signaled event and the one for
>> Async PF.
>>
>> I didn't look into Raghavendra's series deeply. Actually, a lump of
>> registers can be avoid after 2048 byte size is specified in its
>> encoding. I think 2048 bytes are enough for now since there are
>> only two supported events.
>
> When I had said 'one giant pseudoregister' I actually meant 'one
> pseudoregister per event', not all of SDEI into a single
> structure. Since most of this is in flux now, it is hard to point
> out what/how we should migrate from conversation alone.
>
> And on the topic of Raghavendra's series, I do not believe it is
> required anymore here w/ the removal of shared events, which I'm
> strongly in favor of.
>
> Let's delve deeper into migration on the next series :)
>
Ok, Thanks for your clarification about 'one giant pseudoregister'.
Lets have more discussion about the migration on next revision.
To be more clear, I plan to implement the base functionality,
where only the private event is supported. After it reaches into
mergeable or merged, we can post the add-on series to support
migration.
>> In the future, we probably have varied number of SDEI events to
>> be migrated. In that case, we need to add a new bit to the encoding
>> of the pseudo system register, so that VMM (QEMU) can support
>> variable sized system register and keep reading and writing on
>> these registers on migration:
>>
>> PSEUDO_SDEI_ADDR: 64-bits in width
>> PSEUDO_SDEI_DATA: has varied size
>>
>> PSEUDO_SDEI_ADDR is used to (1) Indicate the size of PSEUDO_SDEI_DATA
>> (2) The information to be read/written, for example the (shared/private)
>> registered events on VM and vCPU, VCPU state.
>>
>> PSEUDO_SDEI_DATA is used to (1) Retrieved information or that to be
>> written. (2) Flags to indicate current block of information is the
>> last one or not.
>
> I don't think we have sufficient encoding space in the register ID
> to allow for arbitrary length registers. Any new registers for SDEI will
> need to fit into one of the predefined sizes. Note that we've already
> conditioned userspace to handle registers this way and anything else is
> an ABI change.
>
Ok, I think we need padding to structures of the event, to make the
event object aligned to 64-bytes aligned, and VCPU state to 512-bytes
aligned. 64-bytes and 128-bytes registers have been supported.
Thanks,
Gavin
next prev parent reply other threads:[~2022-03-25 10:23 UTC|newest]
Thread overview: 49+ 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 ` [PATCH v5 01/22] KVM: arm64: Introduce template for inline functions Gavin Shan
2022-03-22 19:42 ` Oliver Upton
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 22:43 ` Oliver Upton
2022-03-23 12:40 ` Gavin Shan
2022-03-23 17:11 ` Oliver Upton
2022-03-24 6:54 ` Gavin Shan
2022-03-24 9:04 ` Oliver Upton
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 18:04 ` Oliver Upton
2022-03-23 12:46 ` Gavin Shan
2022-03-23 16:31 ` Oliver Upton
2022-03-24 4:07 ` Gavin Shan
2022-03-24 7:48 ` Oliver Upton
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 ` [PATCH v5 05/22] KVM: arm64: Support SDEI_EVENT_{ENABLE, DISABLE} hypercall 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 ` [PATCH v5 07/22] KVM: arm64: Support SDEI_EVENT_UNREGISTER hypercall 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 ` [PATCH v5 09/22] KVM: arm64: Support SDEI_EVENT_GET_INFO hypercall 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 ` [PATCH v5 11/22] KVM: arm64: Support SDEI_PE_{MASK, UNMASK} hypercall 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 ` [PATCH v5 13/22] KVM: arm64: Support SDEI_FEATURES hypercall 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 ` [PATCH v5 15/22] KVM: arm64: Support SDEI_EVENT_SIGNAL hypercall Gavin Shan
2022-03-22 23:06 ` Oliver Upton
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 17/22] KVM: arm64: Support SDEI event notifier Gavin Shan
2022-03-22 8:07 ` [PATCH v5 18/22] KVM: arm64: Support SDEI ioctl commands on VM Gavin Shan
2022-03-23 17:28 ` Oliver Upton
2022-03-25 6:59 ` Gavin Shan
2022-03-25 7:35 ` Oliver Upton
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-23 17:55 ` Oliver Upton
2022-03-25 7:59 ` Gavin Shan
2022-03-25 8:37 ` Oliver Upton
2022-03-25 10:23 ` Gavin Shan [this message]
2022-03-22 8:07 ` [PATCH v5 20/22] KVM: arm64: Export SDEI capability Gavin Shan
2022-03-22 8:07 ` [PATCH v5 21/22] KVM: arm64: Add SDEI document Gavin Shan
2022-03-22 8:07 ` [PATCH v5 22/22] KVM: selftests: Add SDEI test case Gavin Shan
2022-03-22 18:13 ` [PATCH v5 00/22] Support SDEI Virtualization Oliver Upton
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=ac9a870d-e3bc-e86b-43e0-2e10a883aa2d@redhat.com \
--to=gshan@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=eauger@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@google.com \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).