Friendly ping... anything else that needs to happen here?
On Thu, May 15 2025, Cornelia Huck wrote:
> Some small fixes, including fixing up/adding SPDX identifiers, keeping the
> series bisectable, and updating MAINTAINERS (please check if that's ok.)
>
> Also available at
> https://gitlab.com/cohuck/qemu/-/commits/arm-rework-idreg-storage-v7
>
>
> Just some small changes:
> - fixed up some botched conversions noted by Eric (thanks!)
> - rebased to current master
> - new patch with a small cleanup suggested by Eric
>
>
> Just a quick respin to fix a missed conversion in hvf.c.
>
>
> Next iteration of the id register patches; only small changes.
>
> Changed from v3:
> - added R-bs (thanks!)
> - added missing SPDX header
> - merged patch introducing accessors for kvm to the first user
> - skip over sysregs outside of the id register range when generating
> register definitions again
>
> Also available at
> https://gitlab.com/cohuck/qemu/-/commits/arm-rework-idreg-storage-v4
>
>
> Yet another update of the id register series, less changes this time
> around.
>
> Changed from v2:
> - changed generation of the various register defines via the "DEF"
> magic suggested by Richard
> - some kvm-only code moved to kvm.c; some code potentially useful to
> non-kvm code stayed out of there (the cpu model code will make use
> of it, and that one should be extendable outside of kvm -- a
> revised version of those patches is still in the works, but I'll be
> off for a few days and rather wanted to get this one out first)
>
> Also available at
> https://gitlab.com/cohuck/qemu/-/commits/arm-rework-idreg-storage-v3
>
>
>
> Changed from v1:
> - Noticed that we missed the hvf code. Converted, compiled, but not tested
> as I'm lacking an environment for testing.
> - Hopefully incorporated most of the suggested changes -- if I missed
> something, it was unintentional unless mentioned below.
> - fixed repeated inclusion of definitions
> - hopefully made macros more robust
> - removed distinction between reading 32/64 values, which was mostly
> adding churn for little value
> - postponed generating property definitions to the cpu model patches,
> where they are actually used
> - juggled hunks and moved them to the right patches
> - fixed some typos
> - rebased to a more recent code base
>
> NOT changed from v1:
> - definitions are still generated from the Linux sysregs file
> - I still think updating the generated files on demand (so that we can
> double check the result) is the right thing to do
> - I'm open to changing the source of the definitions from the sysregs
> file to the JSON definitions published by Arm; however, I first wanted
> to get the code using it right -- we can switch out the code generating
> the file to use a different source easily later on, and I'd also like
> to steal parts of the script from Linux once integrated (which I think
> hasn't happened yet?)
>
>
>
> [Note: I've kept the cc list from the last round of cpu model patches;
> so if you're confused as to why you're cc:ed here, take it as a
> heads-up that a new cpu model series will come along soon]
>
> This patch series contains patches extracted from the larger cpu model
> series (RFC v2 last posted at
> https://lore.kernel.org/qemu-devel/[email protected]/)
> and aims at providing a base upon which we can continue with building
> support for cpu models, but which is hopefully already an improvement
> on its own.
>
> Main changes from the patches in that series include:
> - post-pone the changes to handle KVM writable ID registers for cpu models
> (I have a series including that on top of this one)
> - change how we store the list of ID registers, and access them
> basically, use an enum for indexing, and an enum doing encodings in a
> pattern similar to cpregs
> - move some hunks to different patches
> - update the scripts to generate the register descriptions, and run
> them against a recent Linux sysregs file
>
> What I've kept:
> - generating the register descriptions from the Linux sysregs file
> I think that file is still our best bet to generate the descriptions
> easily, and updating the definitions is a manual step that can be checked
> for unintended changes
> - most of the hard work that Eric had been doing; all new bugs in there
> are my own :)
>
>
>
>
>
>
>
>
> Cornelia Huck (2):
> arm/cpu: switch to a generated cpu-sysregs.h.inc
> arm/kvm: use fd instead of fdarray[2]
>
> Eric Auger (12):
> arm/cpu: Add sysreg definitions in cpu-sysregs.h
> arm/cpu: Store aa64isar0/aa64zfr0 into the idregs arrays
> arm/cpu: Store aa64isar1/2 into the idregs array
> arm/cpu: Store aa64pfr0/1 into the idregs array
> arm/cpu: Store aa64mmfr0-3 into the idregs array
> arm/cpu: Store aa64dfr0/1 into the idregs array
> arm/cpu: Store aa64smfr0 into the idregs array
> arm/cpu: Store id_isar0-7 into the idregs array
> arm/c