qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] acpi: Allow ACPI default OEM ID and OEM tab


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH 1/2] acpi: Allow ACPI default OEM ID and OEM table ID fields to be set.
Date: Thu, 3 Sep 2015 17:37:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 09/03/15 17:17, Michael Tokarev wrote:
> 03.09.2015 18:09, Laszlo Ersek wrote:
>> On 09/02/15 23:32, Michael S. Tsirkin wrote:
>>> On Wed, Sep 02, 2015 at 08:03:37PM +0100, Richard W.M. Jones wrote:
>>>> When using qemu's internal ACPI table generation, qemu sets the fields
>>>> OEM ID and OEM table ID to arbitrary default values.  OEM ID is set to
>>>> "BOCHS " and OEM table ID is set to "BXPCxxxx" where "xxxx" is
>>>> replaced by the ACPI table name (eg. "BXPCRSDT" for the RSDT table).
>>>>
>>>> This patch allows you to override these default values.
>>>>
>>>> Use one of these alternatives:
>>>>
>>>>   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGH
>>>>   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
>>>>
>>>> In the first case, the last four types of the OEM table name field are
>>>> set to the ACPI table name.
>>>>
>>>> This does not affect the -acpitable option (for user-defined ACPI
>>>> tables), which has its own method for setting these fields.
>>>>
>>>> Signed-off-by: Richard W.M. Jones <address@hidden>
>>>
>>> I don't think the 1st option makes sense - why force
>>> 4 bytes of the ID?
>>>
>>> And the issue with the 2nd one is that it won't work if
>>> there are two tables with same ID - which might be the
>>> case for SSID and UEFI tables at least.
>>>
>>> Maybe specify this per signature?
>>
>> I agree with these remarks, but I'd propose a different idea for solving
>> the OEM Table ID problem.
>>
>> As can be seen from the previous discussion that Rich linked in the
>> blurb, and from Michael Tokarev's patch, and from Chris Evich's earlier
>> testing of Win8.1 (linked in the previous discussion), the *only* guest
>> OS where this matters is Windows 7. And Windows 7 doesn't care about the
>> OEM Table Id, only the OEM Id.
> 
> Actually win7 do care about oem table id.  And my patch shows it.  This
> is the minimal portion of RSDT (and also FACP in UEFI mode) which should
> match SLIC -- oem_id (6 bytes) and oem_table_id (8 bytes). My patch copies
> 10 bytes starting with oem_id.

Actually, 6 + 4 + 4 = 14, so OemID and OemTableID. But, you are right, I
was working off the commit message & comments only, not the actual
amount of bytes copied.

This ties down both OemID and OemTableId, between all of RSDT, SLIC, and
FADT. Since
- I argue against exposing a generic oem_table_id on the command
  line (unlike oem_id),
- and I also find that an oem_table_id "map" would be overkill,

I think it follows that I can only ask for the special SLIC-handling
logic already visible in your patch. "User passed in SLIC --> adapt RSDT
and FADT." That is, it is already user-controlled.

(The FADT change will ensure that OVMF will update the RSDT that *it*
installs.)

This is just my preference, of course... But at least it doesn't seem to
conflict with Michael's! :)

Thanks
Laszlo

> Without that, win7 offline activation
> doesn't work.
> 
> FWIW :)
> 
> Thanks,
> 
> /mjt
> 




reply via email to

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