From: Gavin Shan <gshan@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: drjones@redhat.com, agraf@csgraf.de,
Oliver Upton <oupton@google.com>,
richard.henderson@linaro.org, qemu-devel@nongnu.org,
eric.auger@redhat.com, qemu-arm@nongnu.org, shan.gavin@gmail.com,
pbonzini@redhat.com
Subject: Re: [PATCH 0/5] target/arm: Support variable sized coprocessor registers
Date: Mon, 11 Apr 2022 17:49:52 +0800 [thread overview]
Message-ID: <a84ed377-2428-11ca-ee17-0dc8debebcf1@redhat.com> (raw)
In-Reply-To: <CAFEAcA-Tig6PAE4suFnERMN0f_Wco=0UVE7SrWy-Rb7gDheP_Q@mail.gmail.com>
Hi Peter,
On 4/11/22 5:22 PM, Peter Maydell wrote:
> On Mon, 11 Apr 2022 at 07:59, Gavin Shan <gshan@redhat.com> wrote:
>>
>> There are two arrays for each CPU, to store the indexes and values of the
>> coprocessor registers. Currently, 8 bytes fixed storage space is reserved
>> for each coprocessor register. However, larger coprocessor registers have
>> been defined and exposed by KVM. Except SVE registers, no coprocessor
>> register exceeds 8 bytes in size. It doesn't mean large coprocessor registers
>> won't be exploited in future. For example, I'm looking into SDEI virtualization
>> support, which isn't merged into Linux upstream yet. I have plan to add
>> several coprocessor ("firmware pseudo") registers to assist the migration.
>
> So, can you give an example of coprocessor registers which are
> not 8 bytes in size? How are they accessed by the guest?
> If we need to support them then we need to support them, but this
> cover letter/series doesn't seem to me to provide enough detail
> to make the case that they really are necessary.
>
> Also, we support SVE today, and we don't have variable size
> coprocessor registers. Is there a bug here that we would be
> fixing ?
>
[Cc Oliver Upon]
Apart from SVE registers, I don't think we have any more large registers
whose sizes exceed 8 bytes for now, until SDEI virtualization needs more
large registers for migration.
I'm working the KVM series to support SDEI virtualization and last revision
is v6. One of the requirement is to migrate the SDEI events and states.
In v5, the migration is done by the dedicated ioctl commands and it was
suggested by Oliver to use {GET, SET}_ONE_REG. Note that the series isn't
merged yet. So I had the prototype to support SDEI's migration through
{GET, SET}_ONE_REG. Note that those newly added registers are inaccessible
from guest.
https://github.com/gwshan/linux/commit/c2e5de5e210de6b003d1e1330eeb0958cf7007f5
(branch: kvm/arm64_sdei)
https://lore.kernel.org/lkml/20220403153911.12332-13-gshan@redhat.com/T/ (last revision: v6)
https://lore.kernel.org/kvmarm/YjtYuk+Jx1dFPQQ9@google.com/ (v5)
There are large coprocessor register sizes, like U2048, exposed by KVM.
However, it seems we never support those large coprocessor registers.
I'm not sure if we have any challenges to support those large registers,
or we don't have the needs yet?
Thanks,
Gavin
next prev parent reply other threads:[~2022-04-11 9:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 6:58 [PATCH 0/5] target/arm: Support variable sized coprocessor registers Gavin Shan
2022-04-11 6:58 ` [PATCH 1/5] target/arm/tcg: Indirect addressing for coprocessor register storage Gavin Shan
2022-04-11 6:58 ` [PATCH 2/5] target/arm/hvf: " Gavin Shan
2022-04-11 6:58 ` [PATCH 3/5] target/arm/kvm: " Gavin Shan
2022-04-11 6:58 ` [PATCH 4/5] target/arm: Migrate coprocessor register indirect addressing information Gavin Shan
2022-04-11 6:58 ` [PATCH 5/5] target/arm/kvm: Support coprocessor register with variable size Gavin Shan
2022-04-11 9:22 ` [PATCH 0/5] target/arm: Support variable sized coprocessor registers Peter Maydell
2022-04-11 9:49 ` Gavin Shan [this message]
2022-04-11 10:05 ` Peter Maydell
2022-04-12 1:54 ` Gavin Shan
2022-04-11 12:02 ` Andrew Jones
2022-04-11 12:10 ` Peter Maydell
2022-04-13 2:55 ` Gavin Shan
2022-04-12 2:08 ` 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=a84ed377-2428-11ca-ee17-0dc8debebcf1@redhat.com \
--to=gshan@redhat.com \
--cc=agraf@csgraf.de \
--cc=drjones@redhat.com \
--cc=eric.auger@redhat.com \
--cc=oupton@google.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=shan.gavin@gmail.com \
/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).