[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] ide: Don't use qemu_hw_version() for firmware rev
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [RFC] ide: Don't use qemu_hw_version() for firmware revision |
Date: |
Thu, 12 Nov 2015 13:19:53 -0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Thu, Nov 12, 2015 at 09:27:56AM +0100, Markus Armbruster wrote:
> Eduardo Habkost <address@hidden> writes:
>
> > The IDEState.version field is used for firmware version
> > information returned to the guest. Updating firmware information
> > on QEMU upgrade is supposed to be acceptable, so IDE doesn't need
> > the version compatibility magic of qemu_hw_version() and can use
> > QEMU_VERSION directly.
> >
> > Signed-off-by: Eduardo Habkost <address@hidden>
> > ---
> > I'm sending this just to start a discussion about what exactly we
> > are supposed to return to the guest on those IDE fields. Should
> > we return:
> >
> > 1) Something that never changes and don't reveal QEMU version
> > information (e.g. "QEMU")?
> > 2) Something that is always the same depending on the
> > machine-type (machine-type name? MachineClass.hw_version?)
> > 3) Something that change every time QEMU is upgraded (QEMU_VERSION)?
> > 4) Something else?
> >
> > This patch implements option (3).
> >
> > ---
> > hw/ide/core.c | 2 +-
> > hw/ide/internal.h | 2 ++
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index 364ba21..1602707 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -2312,7 +2312,7 @@ int ide_init_drive(IDEState *s, BlockBackend *blk,
> > IDEDriveKind kind,
> > if (version) {
> > pstrcpy(s->version, sizeof(s->version), version);
> > } else {
> > - pstrcpy(s->version, sizeof(s->version), qemu_hw_version());
> > + pstrcpy(s->version, sizeof(s->version), QEMU_VERSION);
>
> Is s->version migrated?
AFAICS, it's not.
>
> If no, live migration to a newer QEMU changes the version, doesn't it?
> The "firmware upgrade is acceptable" argument doesn't apply there. I
> guess a spontaneous version change is relatively unlikely to cause
> trouble, but why risk it?
Good point.
Michael proposed we just change the default value of
qemu_hw_version() to something constant (like "3.0" or "2.5+")
starting on pc-*-2.5, and never update hw_version on newer
machine-types anymore. I think his proposal makes sense.
--
Eduardo