kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@hp.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
Date: Mon, 06 Apr 2009 16:34:33 -0600	[thread overview]
Message-ID: <1239057273.4726.76.camel@lappy> (raw)
In-Reply-To: <49DA5CEA.7040209@us.ibm.com>

Hi Anthony,

On Mon, 2009-04-06 at 14:50 -0500, Anthony Liguori wrote:
> Alex Williamson wrote:
> 
> I know we have to support blobs because of OEM specific smbios entries, 
> but there are a number of common ones that it would probably be good to 
> specify in a less user-unfriendly way.  What do you think?

Yeah, I'll admit this is a pretty unfriendly interface.  I get from your
comment on the other part of the patch that you'd prefer not to get into
the mess of having both binary blobs and command line switches
augmenting the blobs.  This seems reasonable, but also means that we
need a way to fully define the tables we generate from the command line.
For a type 0 entry, that might mean the following set of switches:

-bios-version, -bios-date, -bios-characteristics, -bios-release

And for a type 1:

-system-manufacturer, -system-name, -system-version, -system-serial,
-system-sku, -system-family

type 3:

-chassis-manufacturer, -chassis-type, -chassis-version, -chassis-serial,
-chassis-asset, -chassis-oem

I'm sure I'm missing some, plus we might want to allow the memory and
processor entries to have some fields changed.  Do we want to add that
many switches and means to access them from the rombios?

> Anyway, comments below.
> 
> > diff --git a/hw/acpi.c b/hw/acpi.c
> > index 52f50a0..0bd93bf 100644
> > --- a/hw/acpi.c
> > +++ b/hw/acpi.c
> > @@ -915,3 +915,69 @@ out:
> >      }
> >      return -1;
> >  }
> > +
> > +char *smbios_entries;
> > +size_t smbios_entries_len;
> >   
> 
> I think an accessor would be better than making these variables global.

Ok

> > +int smbios_entry_add(const char *t)
> > +{
> >   
> 
> acpi.c is hardware emulation, I'd rather see the command line parsing 
> done somewhere else (like vl.c).

Ok.  acpi.c was just a convenient place to not bother architectures that
don't care about smbios.

> > +    struct stat s;
> > +    char file[1024], *p, *f, *n;
> > +    int fd, r;
> > +    size_t len, off;
> > +
> > +    f = (char *)t;
> > +    do {
> > +        n = strchr(f, ',');
> > +        if (n) {
> > +            strncpy(file, f, (n - f));
> > +            file[n - f] = '\0';
> > +            f = n + 1;
> > +        } else {
> > +            strcpy(file, f);
> > +            f += strlen(file);
> > +        }
> >   
> 
> I'm happy to just require multiple -smbios options.  I dislike 
> overloading with ','s even though we do it a lot in QEMU.

Yup, I didn't have it initially, but added it because I thought someone
might complain other qemu options allow it.

> > +        fd = open(file, O_RDONLY);
> > +        if (fd < 0)
> > +            return -1;
> > +
> > +        if (fstat(fd, &s) < 0) {
> > +            close(fd);
> > +            return -1;
> > +        }
> >   
> 
> May want to look at load_image/get_image_size.

Will do.  Thanks,

Alex



  reply	other threads:[~2009-04-06 22:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-23 19:05 [PATCH 0/2] qemu: SMBIOS passing support Alex Williamson
2009-03-23 19:11 ` [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS Alex Williamson
2009-04-06 19:50   ` Anthony Liguori
2009-04-06 22:34     ` Alex Williamson [this message]
2009-04-06 22:42       ` Anthony Liguori
2009-04-07 19:34         ` Alex Williamson
2009-04-07 19:49           ` Anthony Liguori
2009-03-23 19:11 ` [PATCH 2/2] qemu:bios: Read external SMBIOS entries from the VM Alex Williamson
2009-04-06 19:52   ` Anthony Liguori
2009-03-30 13:59 ` [PATCH 0/2] qemu: SMBIOS passing support Alex Williamson
2009-03-30 14:05   ` Gleb Natapov
2009-03-30 14:38   ` Daniel P. Berrange
2009-03-30 14:59     ` Avi Kivity
2009-03-30 15:40       ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1239057273.4726.76.camel@lappy \
    --to=alex.williamson@hp.com \
    --cc=aliguori@us.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).