Hi Eric, > -----Original Message----- > From: Eric Auger <eau...@redhat.com> > Sent: Thursday, December 12, 2024 8:42 AM > To: eric.au...@redhat.com; Cornelia Huck <coh...@redhat.com>; > eric.auger....@gmail.com; qemu-devel@nongnu.org; qemu- > a...@nongnu.org; kvm...@lists.linux.dev; peter.mayd...@linaro.org; > richard.hender...@linaro.org; alex.ben...@linaro.org; m...@kernel.org; > oliver.up...@linux.dev; seb...@redhat.com; Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com>; arm...@redhat.com; > berra...@redhat.com; abolo...@redhat.com; jdene...@redhat.com > Cc: shahu...@redhat.com; mark.rutl...@arm.com; phi...@linaro.org; > pbonz...@redhat.com > Subject: Re: [PATCH RFCv2 00/20] kvm/arm: Introduce a customizable > aarch64 KVM host model > > Shameer, > > On 12/12/24 09:12, Eric Auger wrote: > > Connie, > > > > On 12/6/24 12:21, Cornelia Huck wrote: > >> A respin/update on the aarch64 KVM cpu models. Also available at > >> gitlab.com/cohuck/qemu arm-cpu-model-rfcv2 > >> > >> Find Eric's original cover letter below, so that I do not need to > >> repeat myself on the aspects that have not changed since RFCv1 :) > >> > >> Changes from RFCv1: > >> > >> Rebased on more recent QEMU (some adaptions in the register > conversions > >> of the first few patches.) > >> > >> Based on feedback, I have removed the "custom" cpu model; instead, I > >> have added the new SYSREG_<REG>_<FIELD> properties to the "host" > model. > >> This works well if you want to tweak anything that does not correspond > >> to the existing properties for the host model; however, if you e.g. > >> wanted to tweak sve, you have two ways to do so -- we'd probably either > >> want to check for conflicts, or just declare precedence. The kvm-specific > >> props remain unchanged, as they are orthogonal to this configuration. > >> > >> The cpu model expansion for the "host" model now dumps the new > SYSREG_ > >> properties in addition to the existing host model properties; this is a > >> bit ugly, but I don't see a good way on how to split this up. > >> > >> Some more adaptions due to the removal of the "custom" model. > >> > >> Things *not* changed from RFCv1: > >> > >> SYSREG_ property naming (can be tweaked easily, once we are clear on > what > >> the interface should look like.) > >> > >> Sysreg generation scripts, and the generated files (I have not updated > >> anything there.) I think generating the various definitions makes sense, > >> as long as we double-check the generated files on each update (which > would > >> be something to trigger manually anyway.) > >> > >> What I would like us to reach some kind of consensus on: > >> > >> How to continue with the patches moving the ID registers from the isar > >> struct into the idregs array. These are a bit of churn to drag along; > >> if they make sense, maybe they can be picked independently of this > series? > >> > >> Whether it make sense to continue with the approach of tweaking > values in > >> the ID registers in general. If we want to be able to migrate between > cpus > >> that do not differ wildly, we'll encounter differences that cannot be > >> expressed via FEAT_xxx -- e.g. when comparing various AmpereAltra Max > systems, > >> they only differ in parts of CTR_EL0 -- which is not a feature register, > >> but > >> a writable register. > > In v1 most of the commenters said they would prefer to see FEAT props > > instead of IDREG field props. I think we shall try to go in this > > direction anyway. As you pointed out there will be some cases where > FEAT > > won't be enough (CTR_EL0 is a good example). So I tend to think the end > > solution will be a mix of FEAT and ID reg field props. > > > > Personally I would smoothly migrate what we can from ID reg field props > > to FEAT props (maybe using prop aliases?), starting from the easiest 1-1 > > mappings and then adressing the FEAT that are more complex but are > > explictly needed to enable the use cases we are interested in, at RedHat: > > migration within Ampere AltraMax family, migration within NVidia Grace > > family, migration within AmpereOne family and migration between > Graviton3/4. > > > > We have no info about other's use cases. If some of you want to see some > > other live migration combinations addressed, please raise your voice. > In relation to [1] you seem to be also interested in the migration > between heterogeneous systems with qemu.
Yes. That is correct. > Do you think targeting migration within a cpu family is enough for your > use cases. How different are the source and destination host on your > cases. Do you thing feat props are relevant in your case or would you > need lower granularity at idreg field levelto pass the migration? I think, from the current requirement we have for migration, the source and destination mostly can be handled by FEAT_XXX. But like Ampere, we do need to manage the CTR_EL0 differences[1]. Also we do have differences in GIC support as well(AA64PFR0_EL1.GIC) which I am not sure how to manage with FEAT_XXX. And we are checking with our Product team whether we need to support migration from an old CPU type in which case we have to do a bit more analysis. Thanks, Shameer 1. https://lore.kernel.org/kvmarm/20241022073943.35764-1-shameerali.kolothum.th...@huawei.com/
