All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] copy OEM ACPI parameters from SLIC table to RSDT
Date: Sun, 06 Apr 2014 17:58:33 +0400	[thread overview]
Message-ID: <53415D89.2010203@msgid.tls.msk.ru> (raw)
In-Reply-To: <20140406122507.GA8995@redhat.com>

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	other threads:[~2014-04-06 13:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-06  9:49 [Qemu-devel] [RFC] copy OEM ACPI parameters from SLIC table to RSDT Michael Tokarev
2014-04-06 10:53 ` Michael S. Tsirkin
2014-04-06 11:08   ` Michael Tokarev
2014-04-06 12:21     ` Laszlo Ersek
2014-04-07 15:38       ` Chris Evich
2014-04-06 12:25     ` Michael S. Tsirkin
2014-04-06 13:58       ` Michael Tokarev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53415D89.2010203@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.