On Wed, Mar 05, 2025 at 01:24:25PM +0530, Ani Sinha wrote:
> On Sat, Mar 1, 2025 at 9:04 PM Ani Sinha <anisi...@redhat.com> wrote:
> >
> > On Thu, Feb 20, 2025 at 12:36 PM Zhao Liu <zhao1....@intel.com> wrote:
> > >
> > > On Thu, Feb 20, 2025 at 12:23:26PM +0530, Ani Sinha wrote:
> > > > Date: Thu, 20 Feb 2025 12:23:26 +0530
> > > > From: Ani Sinha <anisi...@redhat.com>
> > > > Subject: [PATCH v2] microvm: do not use the lastest cpu version
> > > > X-Mailer: git-send-email 2.45.2
> > > >
> > > > commit 0788a56bd1ae3 ("i386: Make unversioned CPU models be aliases")
> > > > introduced 'default_cpu_version' for PCMachineClass. This created three
> > > > categories of CPU models:
> > > > - Most unversioned CPU models would use version 1 by default.
> > > > - For machines 4.0.1 and older that do not support cpu model aliases, a
> > > > special default_cpu_version value of CPU_VERSION_LEGACY is used.
> > > > - It was thought that future machines would use the latest value of cpu
> > > > versions corresponding to default_cpu_version value of
> > > > CPU_VERSION_LATEST [1].
> > > >
> > > > All pc machines still use the default cpu version of 1 for
> > > > unversioned cpu models. CPU_VERSION_LATEST is a moving target and
> > > > changes with time. Therefore, if machines use CPU_VERSION_LATEST, it
> > > > would
> > > > mean that over a period of time, for the same versioned machine type,
> > > > the cpu version would be different depending on what the latest was at
> > > > that
> > > > time. This would break guests even when they use a constant specific
> > > > versioned machine type.
> > > > Additionally, microvm machines are not versioned anyway and therefore
> > > > there is no requirement to use the latest cpu model by default.
> > > > Let microvms use the non-versioned cpu model and remove all references
> > > > to CPU_VERSION_LATEST as there are no other users (nor we anticipate
> > > > future consumers of CPU_VERSION_LATEST).
> > > >
> > > > Those users who need spefific cpu versions can use explicit version in
> > > > the QEMU command line to select the specific cpu version desired.
> > > >
> > > > CI pipline does not break with this change.
> > > >
> > > > 1) See commit dcafd1ef0af227 ("i386: Register versioned CPU models")
> > > >
> > > > CC: imamm...@redhat.com
> > > > CC: zhao1....@intel.com
> > > > Reviewed-by: Igor Mammedov <imamm...@redhat.com>
> > > > Reviewed-by: Sergio Lopez <s...@redhat.com>
> > > > Signed-off-by: Ani Sinha <anisi...@redhat.com>
> > > > ---
> > > > hw/i386/microvm.c | 2 +-
> > > > target/i386/cpu.c | 15 ---------------
> > > > target/i386/cpu.h | 4 ----
> > > > 3 files changed, 1 insertion(+), 20 deletions(-)
> > > >
> > > > changelog:
> > > > v2: tags added, more explanation in the commit log.
> > >
> > > Reviewed-by: Zhao Liu <zhao1....@intel.com>
> > >
> >
> > Who is picking this up?
>
> I sent a pull request for this and a couple other reviewed patches
> myself. Two reasons:
> - wanted to see this in the upstream sooner as some other bits of the
> work is pending on it.
> - I never sent a pull request before and wanted to go through the
> process to learn how to do it in case I needed it in the future.
>
> i hope the PR is ok. If not, I can resend after corrections. I used
> Peter's script
> https://git.linaro.org/people/peter.maydell/misc-scripts.git/plain/make-pullreqThis should go via Paolo's tree. I have pinged him to remind him of your patches. Please only send pull requests for subsystems where you are listed as the maintainer in the MAINTAINERS file. It doesn't scale when people send me PRs directly because I need to do a bunch of extra sanity checking and helping people get their one-off PRs properly signed and formatted. I also don't like to bypass sub-maintainers because I'm less qualified to do the final review than the sub-maintainers themselves. Thanks, Stefan
signature.asc
Description: PGP signature
