qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 7/7] smbios: Set system manufacturer, product & version by default
Date: Tue, 27 Aug 2013 17:22:19 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

On 08/27/2013 11:04 AM, Michael S. Tsirkin wrote:
> On Fri, Aug 16, 2013 at 03:18:34PM +0200, address@hidden wrote:
>> From: Markus Armbruster <address@hidden>
>>
>> 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 <address@hidden>
>> Reviewed-by: Eric Blake <address@hidden>
> 
> 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.  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.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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