qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).