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 18:44:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 09/03/15 18:33, Michael Tokarev wrote:
> 03.09.2015 18:37, Laszlo Ersek wrote:
> []
>> 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.
> 
> It might be useful to have it controllable by user in other cases too.
> But I don't have any usage case for that.
> 
>> (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! :)
> 
> Yes, it might just work. Especially since in case when SLIC is specified,
> the oem_table&Co should come from SLIC, not forcing user to specify them
> on command line.  Command line can be used anyway, with the default value
> coming from slic if it is provided.
> 
> BTW, I updated the patch for 2.4 a few days ago, it is hackish as I wanted
> to touch as few files as possible.
> 
> And BTW2, the code in acpi/core.c uses its own local definition of ACPI
> table data structures, instead of using common code from acpi.h... ;)

True, but the SDT header struct in "hw/acpi/core.c" (from 2009-2013)
seems to predate the same in "include/hw/acpi/acpi-defs.h" (from Summer
2013) by quite a few years! :)

> Thanks,
> 
> /mjt
> 




reply via email to

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