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, arm...@redhat.com wrote: > >> From: Markus Armbruster <arm...@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 <arm...@redhat.com> > >> Reviewed-by: Eric Blake <ebl...@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 >