Created attachment 1057813 [details]
copy OEM ACPI parameters from SLIC table to RSDT

Created attachment 1057823 [details]
related patch for qemu-kvm.spec

Created attachment 1057824 [details]
bash script for createrepo

Created attachment 1057825 [details]
config for local privat.repo

Does it work if you instead modify the OEM ID and OEM table ID of the SLIC table?

(In reply to Paolo Bonzini from comment #6)
> Does it work if you instead modify the OEM ID and OEM table ID of the SLIC
> table?

Can you answer Paolo's question?

Also, what versions of Windows are affected?

(In reply to Paolo Bonzini from comment #6)
> Does it work if you instead modify the OEM ID and OEM table ID of the SLIC
> table?

This is not possible, because OEM ID and OEM table ID of the SLIC table also
stored *inside* SLIC table and Windows will reject all modified SLIC tables.

Even if you change OEM ID and OEM table ID of the SLIC table twice, 
in all places - because inside SLIC table you can see text fragment "RSA1", 
so content of SLIC table is plobably cryptographically signed, 
and validated on the SLIC load.

I don't know internal format of Microsoft SLIC table and I don't know how to
modify content of SLIC table and how to change RSA1 signature of it content.

Therefore, the only possible way how to make workaround
of this Windows bug is to modify OEM ID and OEM table ID of the RSDT table.

(In reply to Karen Noel from comment #8)
> (In reply to Paolo Bonzini from comment #6)
> > Does it work if you instead modify the OEM ID and OEM table ID of the SLIC
> > table?
> 
> Can you answer Paolo's question?

Ok, done. 
Sorry for delay.
 
> Also, what versions of Windows are affected?

I can't check every Windows version for obvious reasons,
but as far I know - such Windows bug present on every Windows
version, which use offline Windows Activation method via SLIC tables.

So, the only possible way how to migrate Windows from hardware node
to VM - is to use provided patch mjt-set-oem-in-rsdt-like-slic.diff

This patch already heavy tested in Debian and also tested in CentOS:
https://lists.centos.org/pipermail/centos-virt/2015-August/004548.html

RSDT description in ACPI spec says:

OEM Table ID 8 16 For the RSDT, the table ID is the manufacture model ID. This
field must match the OEM Table ID in the FADT.

With the supplied patch, the IDs for RSDT and FADT differ.

There is some upstream discussion of the patch here:

https://lists.gnu.org/archive/html/qemu-devel/2014-04/threads.html#00879

(I'm not a huge expert on ACPI, but it seems to me that this
could be fixed with an option to override the RSDT oem_id,
oem_table_id and OEM signature fields -- currently these are
hardcoded to "BOCHS ", "BXPC" and "RSDT" respectively.)

Was there any further upstream discussion, or was that it?
Was there any resolution upstream about the best way to fix this?

I just posted a couple of patches to qemu-devel.  No link yet
because the mailing list is very slow.

https://lists.nongnu.org/archive/html/qemu-devel/2015-09/threads.html#00555

(In reply to Richard W.M. Jones from comment #12)
> There is some upstream discussion of the patch here:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2014-04/threads.html#00879
> 
> (I'm not a huge expert on ACPI, but it seems to me that this
> could be fixed with an option to override the RSDT oem_id,
> oem_table_id and OEM signature fields -- currently these are
> hardcoded to "BOCHS ", "BXPC" and "RSDT" respectively.)
> 
> Was there any further upstream discussion, or was that it?
> Was there any resolution upstream about the best way to fix this?

In upstream mail list people say, what Windows 7 in near EOL and Windows 8.1 is not use SLIC, so such changes is not need at all. This is not true, because the same offline activation method used not only for desktop Windows versions, but also it widely used for all Windows Server OS variants, at lest Windows 2008 R2.

Windows 2008 R2 will be supported at lest before 1/14/2020.

As it described in page 
https://en.wikipedia.org/wiki/System_Locked_Pre-installation
Windows Server 2008 R2 uses SLP 2.1 and newer Windows Server 
versions use just more new SLP versions, at lest Windows Server 2012 
and Windows Server 2012 R2 uses SLP 2.2 and SLP 2.3 correspondingly.
Windows Server 2012 R2 will be EOL 1/10/2023.

RHEL used mostly on servers, so task for easy migrating legacy Windows Servers
from hardware nodes to VMs inside RHEL Servers will be actual even after 2023.

===================================================================

From usability point of view: Patch from Michael Tokarev is very good.
After fixing bug with FADT such approach will be almost ideal.

Do you know any situations, when RSDT OEM ID and OEM table ID should 
be changed independently from OEM ID and OEM table ID of SLIC table?

We have 100% correlation between SLIC OEM ID and OEM table ID 
and RSDT/FADT value of OEM ID and OEM table ID, so such extra 
flexibility with custom ACPI tables renaming probably just not need.

But even if you think what it really need, the better approach is:

1. if no SLIC acpitable provided - RSDT/FADT OEM ID and OEM table ID
is leaved unchanged, as it now it QEMU.

2. if SLIC acpitable provided - RSDT/FADT OEM ID and OEM table ID
changed accordingly, to values from SLIC table as in current patch.

3. if -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL provided - 
change RSDT/FADT OEM ID and OEM table ID as requested, and if 
SLIC acpitable also provided - print warning message if OEM ID 
and OEM table ID values of SLIC table and RSDT/FADT tables is mismatch.

This will be most flexible and also most user-friendly solution.
(it allow rename RSDT/FADT IDs even if no SLIC table was provided)
Also it does not break all existing installations, which already
use patch created by Michael Tokarev in 2014. In RHEL/CentOS too,
and in all current working Debian installations around the world.
Breaking backward compatibility without very significant reasons
- is bad thing, and should be avoided, especially in RHEL distro.

But from my point of view, step #3 is overengineered and it will 
(almost) not be used in practice at all, steps #1 and #2 will be enough,
if not exists other, except SLIC table reasons for changing RSDT/FADT IDs.
And if such reasons appears sometimes in future - step #3 can be easy
added to steps #1 and #2 to make complete and most universal solution
in any moment of time in future.

See also https://en.wikipedia.org/wiki/YAGNI principle, 
and "If it ain't broke, don't fix it" principle.

====================================================================

> Was there any resolution upstream about the best way to fix this?

I am not sure, what Microsoft allow add such patch with workaround into upsteam.

(In reply to Gena Makhomed from comment #15)
> In upstream mail list people say, what Windows 7 in near EOL and Windows 8.1
> is not use SLIC, so such changes is not need at all. This is not true,
> because the same offline activation method used not only for desktop Windows
> versions, but also it widely used for all Windows Server OS variants, at
> lest Windows 2008 R2.
> 
> Windows 2008 R2 will be supported at lest before 1/14/2020.

Just a very quick add, in case someone thinks win7 would not be important:

it is not EOL, it will get patches until 2020 and it has one of the largest installations bases world wide, so I would really like to see this fixed upstream in qemu :)

For a QEMU solution that works with OVMF as well, the FADT's OEM fields should be exposed. It is not sufficient to patch the OEM fields in the RSDT / XSDT.

https://github.com/tianocore/edk2/issues/5#issuecomment-171384272

(In reply to Laszlo Ersek from comment #17)
> For a QEMU solution that works with OVMF as well, the FADT's OEM fields
> should be exposed. It is not sufficient to patch the OEM fields in the RSDT
> / XSDT.
> 
> https://github.com/tianocore/edk2/issues/5#issuecomment-171384272

Please throw some patches my way - I'm ready to test them with Windows 7 x64 guest on Qemu/OVMF and report here. Tried already attached patches - the a5d3fbf..9e0e16a one doesn't apply on fresh qemu fetched from Github.

Posted upstream patches
http://thread.gmane.org/gmane.comp.emulators.qemu/386728

(In reply to Laszlo Ersek from comment #19)
> Posted upstream patches
> http://thread.gmane.org/gmane.comp.emulators.qemu/386728

Thanks Laszlo.
Applied them cleanly on master branch of git://git.qemu-project.org/qemu.git, below are the results for Windows 7 Pro SP1. 
Qemu is run with "-acpitable slic_table.bin", file taken from /sys/firmware/acpi/tables/ (Arch Linux).
I'm doing acpi checks in guest Win7 with official ACPICA binaries (https://www.acpica.org/downloads/binary-tools) - tell me if you need something else.

In VM:
$ acpidump.exe -s
ACPI: DSDT 0x0000000000000000 001DF2 (v01 BOCHS  BXPCDSDT 00000001 BXPC 00000001)
ACPI: XSDT 0x0000000000000000 000054 (v01 <vend> <vend-id>     00000001      01000013)
ACPI: FACS 0x0000000000000000 000040
ACPI: FACP 0x0000000000000000 000074 (v01 <vend> <oem-id>     00000001 BXPC 00000001)

On bare metal host that SLIC table was copied from, running Windows:
$ acpidump.exe -s                                                                   
ACPI: DSDT 0x0000000000000000 014857 (v02 <vend>   <oem-id>     01072009 <semiconductor-vendor1> 20120913)   
ACPI: XSDT 0x0000000000000000 0000D4 (v01 <vend>   <oem-id>     01072009 <semiconductor-vendor2>  00010013)   
ACPI: FACS 0x0000000000000000 000040                                                
ACPI: FACP 0x0000000000000000 00010C (v05 <vend>   <oem-id>     01072009 <semiconductor-vendor2>  00010013)   


<vend> and <oem-id> are the same everywhere above.

(In reply to Aleksei Kovura from comment #20)
> (In reply to Laszlo Ersek from comment #19)
> > Posted upstream patches
> > http://thread.gmane.org/gmane.comp.emulators.qemu/386728
> 
> Thanks Laszlo.
> Applied them cleanly on master branch of
> git://git.qemu-project.org/qemu.git, below are the results for Windows 7 Pro
> SP1. 
> Qemu is run with "-acpitable slic_table.bin", file taken from
> /sys/firmware/acpi/tables/ (Arch Linux).
> I'm doing acpi checks in guest Win7 with official ACPICA binaries
> (https://www.acpica.org/downloads/binary-tools) - tell me if you need
> something else.
> 
> In VM:
> $ acpidump.exe -s
> ACPI: DSDT 0x0000000000000000 001DF2 (v01 BOCHS  BXPCDSDT 00000001 BXPC
> 00000001)
> ACPI: XSDT 0x0000000000000000 000054 (v01 <vend> <vend-id>     00000001     
> 01000013)
> ACPI: FACS 0x0000000000000000 000040
> ACPI: FACP 0x0000000000000000 000074 (v01 <vend> <oem-id>     00000001 BXPC
> 00000001)
> 
> On bare metal host that SLIC table was copied from, running Windows:
> $ acpidump.exe -s                                                           
> 
> ACPI: DSDT 0x0000000000000000 014857 (v02 <vend>   <oem-id>     01072009
> <semiconductor-vendor1> 20120913)   
> ACPI: XSDT 0x0000000000000000 0000D4 (v01 <vend>   <oem-id>     01072009
> <semiconductor-vendor2>  00010013)   
> ACPI: FACS 0x0000000000000000 000040                                        
> 
> ACPI: FACP 0x0000000000000000 00010C (v05 <vend>   <oem-id>     01072009
> <semiconductor-vendor2>  00010013)   
> 
> 
> <vend> and <oem-id> are the same everywhere above.

The OEM ID and OEM Table ID fields look good in the XSDT and the FACP, so that's great.

However, as far as SLIC itself is concerned, can you confirm you are actually loading it with:

    -acpitable file=slic_table.bin

? (This is the form that you pasted in the github issue tracker, and it is the correct form.) Because here you wrote

    -acpitable slic_table.bin

which is equivalent to

    -acpitable data=slic_table.bin

and that would not be right, given that you dumped the full table (including the headers) from the physical host.

Summary:
(1) XSDT and FACP (aka FADT) look good,

(2) please confirm that "-acpitable slic_table.bin" is just a typo in comment
    20, and that you actually used "-acpitable file=slic_table.bin".

(3) The test that would bring the most proof is not a synthetic one
    (i.e., with acpidump.exe), but checking that the *activation status* of
    the p2v-converted Windows instance remains intact. Can you check that
    please?

Thanks.

(In reply to Laszlo Ersek from comment #21)
> (2) please confirm that "-acpitable slic_table.bin" is just a typo in comment
>     20, and that you actually used "-acpitable file=slic_table.bin".
> 
> (3) The test that would bring the most proof is not a synthetic one
>     (i.e., with acpidump.exe), but checking that the *activation status* of
>     the p2v-converted Windows instance remains intact. Can you check that
>     please?

Yes, that was a typo, command used is "-acpitable file=slic_table.bin". There's another small typo there - "<vend-id>" should be "<oem-id>" in first output.

Windows activation is intact (it actually "returned back" to activated status - in previous boots into unpatched qemu Windows displayed a request to activate in system properties, now it says windows is activated).

yes, but what if you activate upon request, then apply patch?

(In reply to Laszlo Ersek from comment #21)

> (3) The test that would bring the most proof is not a synthetic one
>     (i.e., with acpidump.exe), but checking that the *activation status* of
>     the p2v-converted Windows instance remains intact. Can you check that
>     please?
> 
> Thanks.

Hi, i could help testing if needed. The Win7 OEM license from my Dell workstation will not activate in RHEL 7.2. Problem is, i have only a desktop subscription and so not able to apply patches. So i think would need a rpm package

(In reply to Michael S. Tsirkin from comment #23)
> yes, but what if you activate upon request, then apply patch?

What you mean by "activate upon request"?

(In reply to starbuck from comment #24)
> (In reply to Laszlo Ersek from comment #21)
> 
> > (3) The test that would bring the most proof is not a synthetic one
> >     (i.e., with acpidump.exe), but checking that the *activation status* of
> >     the p2v-converted Windows instance remains intact. Can you check that
> >     please?
> > 
> > Thanks.
> 
> Hi, i could help testing if needed. The Win7 OEM license from my Dell
> workstation will not activate in RHEL 7.2. Problem is, i have only a desktop
> subscription and so not able to apply patches. So i think would need a rpm
> package

Thanks for the offer!

At the moment we're working on the upstream patch, so testing should target upstream QEMU as well. Can you apply patches from qemu-devel and build & install upstream QEMU to e.g. /opt/qemu? It can peacefully coexist with the RHEL-shipped qemu-kvm[-rhev] package. You can even use it with the RHEL-shipped libvirt package, just need to set the machine type in the domain XML to one of the upstream types.

(None of this is supported, of course; I'm just saying that it's possible to develop & test upstream QEMU on a RHEL host, without disturbing the RHEL package.)

The link to the upstream patch set and the discussion is in comment 19.

Thanks!

Posted upstream v2:
http://thread.gmane.org/gmane.comp.emulators.qemu/387508

(In reply to Laszlo Ersek from comment #27)
> Posted upstream v2:
> http://thread.gmane.org/gmane.comp.emulators.qemu/387508

Applied to 649a1bbaf95adb228f1030ab0618a932bc26aa8b of git.qemu-project.org/qemu.git - working fine on my win7 P2V setup - acpidump reports vendor's  IDs and windows is activated.

Upstream commits:

1  37ad223 acpi: take oem_id in build_header(), optionally
2  5151355 acpi: expose oem_id and oem_table_id in build_rsdt()
3  88594e4 acpi: add function to extract oem_id and oem_table_id from the user's
           SLIC
4  ae12374 pc: set the OEM fields in the RSDT and the FADT from the SLIC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

I am changing the title of this RHBZ. The current title suggests that QEMU is trying to work around a Windows bug. It is not a Windows bug; the OEM ID and OEM Table ID identities between the SLIC, FADT and RSDT are required and documented in Microsoft's SLIC spec. So this RHBZ is about improving QEMU's conformance to that spec.

Created attachment 1148027 [details]
"slic.dat" file, for testing by QE

Test steps for QE:

(1) Download the attached "slic.dat" example file to your virt host, under
    the filename "/tmp/slic.dat".

    (FYI, this is a very simple, example SLIC table ("Software Licensing
    Description Table") that I created, following the SLIC spec from
    Microsoft. When decompiled with "iasl -d", the output is:

      [000h 0000   4]             Signature : "SLIC"
      [004h 0004   4]          Table Length : 00000024
      [008h 0008   1]              Revision : 01
      [009h 0009   1]              Checksum : 3A
      [00Ah 0010   6]                Oem ID : "ABRACA"
      [010h 0016   8]          Oem Table ID : "DABRAXYZ"
      [018h 0024   4]          Oem Revision : 01020304
      [01Ch 0028   4]       Asl Compiler ID : "QUUX"
      [020h 0032   4] Asl Compiler Revision : 05060708

    )

(2) As root, run the following commands (note that these are in general not
    secure for storing a genuine "slic.dat", since it contains sensitive
    information, but for the purposes of this test, the following will do):

    chmod -c 0444 /tmp/slic.dat
    chcon -v -t svirt_tmp_t /tmp/slic.dat

(3) Install a Linux guest (or use a preexistent Linux guest); the guest
    firmware (SeaBIOS or OVMF) does not matter.

(4) Edit the domain XML as follows. Replace the tag

      <domain type='kvm'>

    with

      <domain type='kvm'
       xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

    plus add the following snippet, immediately before the closing </domain>
    tag:

      <qemu:commandline>
        <qemu:arg value='-acpitable'/>
        <qemu:arg value='file=/tmp/slic.dat'/>
      </qemu:commandline>

(5) This step is for reproducing the bug. Start the guest, ssh into it, then
    run the following command:

      dmesg -t | egrep '^ACPI: [A-Z]{4} ' | tee tables.pre.txt

    It will list the header fields for the ACPI tables (and save them in a
    file, for later).

    Focus on the RSDT, FACP and SLIC ones (their physical addresses are
    redacted below for brevity):

      egrep '^ACPI: (SLIC|FACP|RSDT)' tables.pre.txt

    It will list something like:

                                       OEM
                                OEM ID Table ID
                                ------ --------
      ACPI: RSDT ... 00034 (v01 BOCHS  BXPCRSDT 00000001 BXPC 00000001)
      ACPI: FACP ... 00074 (v01 BOCHS  BXPCFACP 00000001 BXPC 00000001)
      ACPI: SLIC ... 00024 (v01 ABRACA DABRAXYZ 01020304 QUUX 05060708)

    The bug is that the OEM ID and OEM Table ID fields of the RSDT and the
    FACP (a.k.a. FADT), namely BOCHS and BXPC????, do not match the same
    fields in the SLIC (ABRACA and DABRAXYZ, respectively).

(6) Shut down the guest, and install the qemu-kvm[-rhev] package that
    contains the fix.

(7) Boot the guest again, ssh into it, then run the following commands:

      (
        dmesg -t | egrep '^ACPI: [A-Z]{4} ' | tee tables.post.txt
        printf -- '--------\n'
        diff -u tables.pre.txt tables.post.txt
      )

    In both of the RSDT and FACP tables, the OEM ID and OEM Table ID values
    should be ABRACA and DABRAXYZ, respectively; matching the same fields in
    the SLIC. Furthermore, there should be no other difference.

      -ACPI: RSDT ... 00034 (v01 BOCHS  BXPCRSDT 00000001 BXPC 00000001)
      -ACPI: FACP ... 00074 (v01 BOCHS  BXPCFACP 00000001 BXPC 00000001)
      +ACPI: RSDT ... 00034 (v01 ABRACA DABRAXYZ 00000001 BXPC 00000001)
      +ACPI: FACP ... 00074 (v01 ABRACA DABRAXYZ 00000001 BXPC 00000001)

(8) Regression check: the before-after comparison should also be done
    without step (4) -- that is, without passing "slic.dat" to the guest.

    In this scenario, the SLIC table should not be present at all, and there
    should be no difference in the ACPI tables between the original package
    and the upgraded package.

Thanks Laszlo for your kindness of providing detailed test steps.

-- Reproduced with qemu-kvm-rhev-2.3.0-31.el7_2.21. After step 5 in Comment 42:

# egrep '^ACPI: (SLIC|FACP|RSDT)' tables.pre.txt
ACPI: RSDT 000000007ffe170a 00034 (v01 BOCHS  BXPCRSDT 00000001 BXPC 00000001)
ACPI: FACP 000000007ffe0c14 00074 (v01 BOCHS  BXPCFACP 00000001 BXPC 00000001)
ACPI: SLIC 000000007ffe16e6 00024 (v01 ABRACA DABRAXYZ 01020304 QUUX 05060708)

The OEM ID and OEM Table ID fields of the RSDT and the FACP doesn't match that of the SLIC

-- Verified pass with qemu-kvm-rhev-2.6.0-22.el7. 

# egrep '^ACPI: (SLIC|FACP|RSDT)' tables.post.txt
ACPI: RSDT 000000007ffe18d6 00030 (v01 ABRACA DABRAXYZ 00000001 BXPC 00000001)
ACPI: FACP 000000007ffe17be 00074 (v01 ABRACA DABRAXYZ 00000001 BXPC 00000001)
ACPI: SLIC 000000007ffe18b2 00024 (v01 ABRACA DABRAXYZ 01020304 QUUX 05060708)

The OEM ID and OEM Table ID fields of the RSDT and the FACP exactly matches that of the SLIC

Besides, without slic.dat passed in guest there is no SLIC field at all and no difference noticed in both RSDT and FACP.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html