qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] copy OEM ACPI parameters from SLIC table to RSDT


From: Michael Tokarev
Subject: Re: [Qemu-devel] [RFC] copy OEM ACPI parameters from SLIC table to RSDT
Date: Sun, 06 Apr 2014 17:58:33 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

06.04.2014 16:25, Michael S. Tsirkin wrote:
[]
>>>> Windows7 requires that OEM ID in RSDT matches those in SLIC to
>>>> consider SLIC to be valid.
>>>
>>> Which fields need to match which, exactly?
>>
>> As can be seen in the patch itself, that's 2 fields - oem_id [4]
> 
> Surely oem_id[6]?

Yes you're right.

>> and oem_table_id[8], in SLIC and RSDT.  This is enough for win7
>> at least.

All 14 bytes in this place are needed.  Omitting any of those 3
(actually that's 3 not 2) fields -- oem_id[6], oem_table_id[4]
and oem_table_sig[4] makes windows 7 activation void.

I'm sorry I missed this question initially:

>>>> +    if (memcmp(sig, "RSDT", 4) == 0 && slic_table_offset) {
>>>> +      /* for win7: OEM info in RSDT and SLIC should be the same */
>>>> +      AcpiTableHeader *s = (AcpiTableHeader *)(acpi_tables + 
>>>> slic_table_offset);
>>>> +      memcpy(h->oem_id, s->oem_id, 6 + 4 + 4);
>>>
>>>
>>> what does 6 + 4 +4 mean?
>>> I see:
>>>     uint8_t  oem_id [6];             /* OEM identification */ \
>>>     uint8_t  oem_table_id [8];       /* OEM table identification */ \
>>>     uint32_t oem_revision;           /* OEM revision number */ \

In some specs I found oem_table_id[8] is represented by 2 4-byte fields.

>>> Do table id have to match? It seems a bit wrong to have two tables
>>> with the same id.

Yes it should match, whole oem_table_id[8] plus oem_id[6] itself.
I don't know what exactly those identifications mean, but without
any of those 14 bytes windows activation does not work.
oem_revision can be anything, it is not part of the equation.

It is easy to verify by playing with the memcpy() above -- this is
actually how I found the minimal amount of bytes which should match
initially.

Thanks,

/mjt



reply via email to

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