Bug 1248758 - match the OEM ID and OEM Table ID fields of the FADT and the RSDT to those of the SLIC
match the OEM ID and OEM Table ID fields of the FADT and the RSDT to those of...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.1
x86_64 Linux
high Severity high
: pre-dev-freeze
: ---
Assigned To: Laszlo Ersek
Virtualization Bugs
: ZStream
Depends On:
Blocks: 1327537 1330969 1380310
  Show dependency treegraph
 
Reported: 2015-07-30 14:37 EDT by Gena Makhomed
Modified: 2016-11-07 15:31 EST (History)
26 users (show)

See Also:
Fixed In Version: QEMU 2.6
Doc Type: If docs needed, set a value
Doc Text:
undefined
Story Points: ---
Clone Of:
: 1327537 1330969 1380310 (view as bug list)
Environment:
Last Closed: 2016-11-07 15:31:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
copy OEM ACPI parameters from SLIC table to RSDT (2.94 KB, text/plain)
2015-07-30 14:37 EDT, Gena Makhomed
no flags Details
copy OEM ACPI parameters from SLIC table to RSDT (2.94 KB, patch)
2015-07-30 14:40 EDT, Gena Makhomed
no flags Details | Diff
related patch for qemu-kvm.spec (825 bytes, patch)
2015-07-30 14:41 EDT, Gena Makhomed
no flags Details | Diff
bash script for createrepo (485 bytes, application/x-shellscript)
2015-07-30 14:42 EDT, Gena Makhomed
no flags Details
config for local privat.repo (121 bytes, text/plain)
2015-07-30 14:43 EDT, Gena Makhomed
no flags Details
"slic.dat" file, for testing by QE (36 bytes, application/octet-stream)
2016-04-16 17:48 EDT, Laszlo Ersek
no flags Details

  None (edit)
Description Gena Makhomed 2015-07-30 14:37:58 EDT
Created attachment 1057809 [details]
copy OEM ACPI parameters from SLIC table to RSDT

Description of problem:

qemu-kvm option '-acpitable' does not reliable work for SLIC acpi tables
with Windows VMs due to Windows bug of working with oem_id/oem_table_id.

oVirt/RHEV 3.5.3 qemu-kvm does not contains workaround for this windows bug.
Such workaround already used in Debian, and Windows VMs works as expected
under Debian version of qemu-kvm 2.1.2.

Version-Release number of selected component (if applicable):

This bugreport about package qemu-kvm-ev from oVirt 3.5.3 located at:
http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/SRPMS/qemu-kvm-ev-2.1.2-23.el7_1.3.1.src.rpm

Sorry, but site bugzilla.redhat.com for oVirt Product 
does not contains partition for qemu-kvm-ev Component
so only possible way to report bugs about qemu-kvm-ev
is fill bugreport for the same package qemu-kvm-rhev 
at Red Hat Enterprise Virtualization Manager Product

How reproducible:

Always.

Steps to Reproduce:
1. install CentOS 7.1 
2. install binary packages build from qemu-kvm-ev-2.1.2-23.el7_1.3.1.src.rpm
3. create Windows VM with xml config
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
  <qemu:commandline>
    <qemu:arg value='-acpitable'/>
    <qemu:arg value='file=/path/to/sys/firmware/acpi/tables/SLIC'/>
  </qemu:commandline>
</domain>

4. start Windows VM
5. ensure what Windows VM does not recognise SLIC table as expected

Actual results:

Windows VM does not recognise SLIC table

Expected results:

Windows VM recognise SLIC table

Additional info:

This is Windows bug, which prevent seabless migration Windows 
from hardware node to VM inside CentOS/RHEL - Windows requires
what oem_id and oem_table_id from SLIC table must be 
also placed into oem_id and oem_table_id of RSDT. 

Debian version of qemu-kvm contains workaround for this windows bug,
and using Debian - Windows VM will works fine. But oVirt packages
does not contain such workaround, so qemu-kvm-ev now must be patched
manually with each new release.

Patch already was created by Michael Tokarev in 2014:
this is file mjt-set-oem-in-rsdt-like-slic.diff
from https://packages.debian.org/jessie/qemu-kvm

This patch cleanly applies also to qemu-kvm-ev-2.1.2-23.el7_1.3.1

See mjt-set-oem-in-rsdt-like-slic.diff
and qemu-kvm.spec.patch in attach for details.

After executing rpmbuild -ba qemu-kvm.spec
you can place new qemu-kvm binaries into
/srv/download/centos/7/privat/x86_64/Packages
create local repo and use it for upgrading rpm packages,
for example, see privat.repo and privat-createrepo-7-x86_64
in attach.

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

Better if this workaround of Windows bug will be included
into RHEL/CentOS ovirt repo binaries, and this will allow
to anybody easy migrate Windows from hardware nodes
to VMs and easy run CentOS/RHEL at hardware nodes.

P.S.
     After patching qemu-kvm - option
     acpitable works without any bugs:

  # man qemu-kvm

    -acpitable [sig=str][...]
        If a SLIC table is supplied to qemu,
        then the oem_id from the SLIC table
        will be copied into the RSDT table
        (this is a Debian addition).
Comment 1 Gena Makhomed 2015-07-30 14:40:03 EDT
Created attachment 1057813 [details]
copy OEM ACPI parameters from SLIC table to RSDT
Comment 2 Gena Makhomed 2015-07-30 14:41:01 EDT
Created attachment 1057823 [details]
related patch for qemu-kvm.spec
Comment 3 Gena Makhomed 2015-07-30 14:42:22 EDT
Created attachment 1057824 [details]
bash script for createrepo
Comment 4 Gena Makhomed 2015-07-30 14:43:25 EDT
Created attachment 1057825 [details]
config for local privat.repo
Comment 6 Paolo Bonzini 2015-08-03 09:38:54 EDT
Does it work if you instead modify the OEM ID and OEM table ID of the SLIC table?
Comment 8 Karen Noel 2015-08-28 12:11:52 EDT
(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?
Comment 9 Gena Makhomed 2015-08-28 12:36:40 EDT
(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.
Comment 10 Gena Makhomed 2015-08-28 12:46:15 EDT
(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
Comment 11 Michael S. Tsirkin 2015-08-30 02:33:00 EDT
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.
Comment 12 Richard W.M. Jones 2015-09-01 04:48:11 EDT
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?
Comment 13 Richard W.M. Jones 2015-09-02 12:43:09 EDT
I just posted a couple of patches to qemu-devel.  No link yet
because the mailing list is very slow.
Comment 15 Gena Makhomed 2015-09-03 15:04:42 EDT
(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.
Comment 16 Sven Kieske 2015-09-04 04:27:56 EDT
(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 :)
Comment 17 Laszlo Ersek 2016-01-13 13:15:06 EST
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
Comment 18 Aleksei Kovura 2016-01-13 15:58:02 EST
(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.
Comment 19 Laszlo Ersek 2016-01-13 20:42:02 EST
Posted upstream patches
http://thread.gmane.org/gmane.comp.emulators.qemu/386728
Comment 20 Aleksei Kovura 2016-01-14 04:52:17 EST
(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.
Comment 21 Laszlo Ersek 2016-01-14 08:10:36 EST
(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.
Comment 22 Aleksei Kovura 2016-01-14 09:00:32 EST
(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).
Comment 23 Michael S. Tsirkin 2016-01-14 09:51:52 EST
yes, but what if you activate upon request, then apply patch?
Comment 24 starbuck 2016-01-15 16:13:36 EST
(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
Comment 25 Aleksei Kovura 2016-01-16 10:23:31 EST
(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"?
Comment 26 Laszlo Ersek 2016-01-18 04:17:09 EST
(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!
Comment 27 Laszlo Ersek 2016-01-18 09:13:16 EST
Posted upstream v2:
http://thread.gmane.org/gmane.comp.emulators.qemu/387508
Comment 28 Aleksei Kovura 2016-01-18 14:42:57 EST
(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.
Comment 29 Laszlo Ersek 2016-02-10 06:14:16 EST
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
Comment 30 Mike McCune 2016-03-28 18:55:34 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 35 Laszlo Ersek 2016-04-15 06:59:49 EDT
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.
Comment 42 Laszlo Ersek 2016-04-16 17:48 EDT
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.
Comment 51 Chao Yang 2016-09-07 04:32:51 EDT
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.
Comment 54 errata-xmlrpc 2016-11-07 15:31:37 EST
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

Note You need to log in before you can comment on or make changes to this bug.