From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: OEM version of Windows in kvm (SLIC &Co) Date: Thu, 25 Mar 2010 13:58:00 +0200 Message-ID: <4BAB4FC8.7040800@redhat.com> References: <4BAA3126.8070509@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list To: Michael Tokarev Return-path: Received: from mx1.redhat.com ([209.132.183.28]:4880 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772Ab0CYL6F (ORCPT ); Thu, 25 Mar 2010 07:58:05 -0400 In-Reply-To: <4BAA3126.8070509@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: On 03/24/2010 05:35 PM, Michael Tokarev wrote: > At least having a way to accept complete acpi table (with header > and checksum and everything) is - IMHO - a good thing. > Agreed. > But I'm not sure about the OEM ID strings in other tables in seabios, -- > it is quite ugly, both in implementation (how to tell bios to change > its identify?) There is the firmware configuration interface, see hw/fw_cfg.[ch] (used to expose the acpi tables as well). > and in the whole fact of it, since we're lying to the > (virtual) machine. But from another point of view, it should be a > good debugging tool, since some software behaves differently given > one or another strings in the BIOS... > It's perfectly legitimate to lie to your guests. For the OEM ID, we really need to change it to qemu for 0.13, so we'll need a firmware config interface for this even if we don't want to expose it to users. -- error compiling committee.c: too many arguments to function