Re: [Qemu-devel] [PATCH v2 7/7] smbios: Set system manufacturer, product & version by default

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Aug 27, 2013 at 05:22:19PM -0600, Eric Blake wrote:
> On 08/27/2013 11:04 AM, Michael S. Tsirkin wrote:
> > On Fri, Aug 16, 2013 at 03:18:34PM +0200, armbru@redhat.com wrote:
> >> From: Markus Armbruster <armbru@redhat.com>
> >>
> >> Currently, we get SeaBIOS defaults: manufacturer Bochs, product Bochs,
> >> no version.  Best SeaBIOS can do, but we can provide better defaults:
> >> manufacturer QEMU, product & version taken from QEMUMachine desc and
> >> name.
> >>
> >> Take care to do this only for new machine types, of course.
> >>
> >> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> >> Reviewed-by: Eric Blake <eblake@redhat.com>
> > 
> > We can do this of course, but why is this better?
> > It seems to expose new information to the guest
> > for no reason, we just might come to regret it
> > later if guests start implementing hacks keying
> > off the version number.
> 
> Some guests (cough: some OEM builds of windows) already DO key off of
> SMBIOS information to determine if they are running in a valid
> environment.

Well they are unlikely to like either QEMU or Bochs.

> Furthermore, making this change to qemu makes it easier to
> decouple the strings being presented to guests by default; it's always
> better to have a situation where changing just qemu works, instead of
> having to patch both qemu and BIOS in tandem.
> 
> The choice of whether to present the different information MUST be tied
> to machine types (we cannot change SMBIOS data without an explicit
> change to a newer machine type, precisely _because_ there are guests
> that base their licensing decisions on constancy of BIOS information).
> But for a new machine type, presenting qemu as the machine type rather
> than being stuck to a particular SeaBIOS build seems nicer.

Yes but why change anything at all?

We have command line flags to set these fields
for whatever you want to boot OEM windows -
which is highly unlikely to match any QEMU version.
Why isn't this enough?

> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>