qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2 (RFC)] QEMU: SMBIOS: Build full smbios table


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [PATCH 2/2 (RFC)] QEMU: SMBIOS: Build full smbios tables
Date: Wed, 5 Mar 2014 09:48:53 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Mar 05, 2014 at 11:59:44AM +0100, Gerd Hoffmann wrote:
> > -static bool smbios_type1_defaults = true;
> > +static bool smbios_defaults = true;
> >  /* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped 
> > to
> >   * host addresses aligned at 1Gbyte boundaries.  This way we can use 1GByte
> >   * pages in the host.
> > @@ -143,9 +143,9 @@ static void pc_init1(QEMUMachineInitArgs *args,
> >      guest_info->has_pci_info = has_pci_info;
> >      guest_info->isapc_ram_fw = !pci_enabled;
> >  
> > -    if (smbios_type1_defaults) {
> > +    if (smbios_defaults) {
> >          /* These values are guest ABI, do not change */
> > -        smbios_set_type1_defaults("QEMU", "Standard PC (i440FX + PIIX, 
> > 1996)",
> > +        smbios_set_defaults("QEMU", "Standard PC (i440FX + PIIX, 1996)",
> >                                    args->machine->name);
> >      }
> 
> Need to be careful here.  smbios_type1_defaults handles machine type
> compatibility.  qemu version 1.7 (and older) don't set any smbios fields
> by default.  Current qemu behaves simliar with -M pc-i440fx-1.7 (+older)
> for compatibility reasons, and smbios_type1_defaults controls that.

I was just reusing the type_1 defaults for more than just
type_1 tables, so I felt I should rename it to reflect this
new, more general purpose. It's still setting type_1 defaults
if/when necessary.

I might also be misunderstanding your point, sorry if that's
the case...

> Given that we don't have a stable release which sets smbios defaults I
> think it is ok to do it this way (assuming it is merged before the 2.0
> release).
> 
> Splitting the patches would be nice for review (add table generator /
> switch type0 / switch type1 / remove field support / add type2).

Yeah, it did occur to me that the diff looked horribly
incomprehensible, so I'll split it all out into smaller,
hopefully much more intelligible bits :)

> Maybe we should continue to use the individual fields interface for 1.7
> machine types, for best backward compatibility.

I'm trying to wrap my head around how I'd distinguish between fields
on the command line that are to be passed on as individual fields, vs.
fields that should be used to build a full table...

> Overall it looks good to me, don't see any major issues.

Thanks, I'll re-send as a series of smaller patches, hopefully with a
few additional table types being built locally.

--Gabriel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]