CentOS virt - Jul 2015 - qemu-kvm SLIC acpitable workaround of Windows bug

On 29.07.2015 21:34, Nux! wrote:
> Yes, you can.
> In fact you can use the binaries from the ovirt repo itself, no need to
rebuild.
Thank you!

In fact - I can't use raw binaries from the ovirt repo itself,
because these qemu-kvm binaries contains one bug,
which is already fixed in Debian:

If you want to migrate Windows from hardware node
to VM using CentOS 7.1 on hardware node and libvirt 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=/sys/firmware/acpi/tables/SLIC'/>
   </qemu:commandline>
</domain>

Winodws not working correctly in this case, because Windows requires,
what oem_id and oem_table_id from SLIC 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 CentOS 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).
> ----- Original Message -----
>> Is it possible to use binary packages build from
>>
http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/SRPMS/qemu-kvm-ev-2.1.2-23.el7_1.3.1.src.rpm
>> with plain CentOS 7.1 and use all other packages from CentOS
>> (libvirt, virt-manager, etc)
>>
>> Is it have reasons, if I not use live migrations and qcow2 snapshots?
>> (instead use zfs, zvols and zfs snapshots for VM disks online backups)
>>
>> Is using qemu-kvm-ev with CentOS 7.1 have any disadvantages?
-- 
Best regards,
  Gena
-------------- next part --------------
--- qemu-kvm.spec.orig	2015-05-15 13:27:19.000000000 +0300
+++ qemu-kvm.spec	2015-07-29 23:25:04.421842297 +0300
@@ -93,7 +93,7 @@
 Version: 2.1.2
 Release: 23%{?dist}_1.3.1
 # Epoch because we pushed a qemu-1.0 package. AIUI this can't ever be
dropped
-Epoch: 10
+Epoch: 77
 License: GPLv2+ and LGPLv2+ and BSD
 Group: Development/Tools
 URL: http://www.qemu.org/
@@ -847,6 +847,8 @@
 Patch341: kvm-block-Fix-max-nb_sectors-in-bdrv_make_zero.patch
 # For bz#1219271 - 
 Patch342: kvm-fdc-force-the-fifo-access-to-be-in-bounds-of-the-all.patch
+# copy OEM ACPI parameters from SLIC table to RSDT
+Patch999: mjt-set-oem-in-rsdt-like-slic.diff 
 
 BuildRequires: zlib-devel
 BuildRequires: SDL-devel
@@ -1400,6 +1402,7 @@
 %patch340 -p1
 %patch341 -p1
 %patch342 -p1
+%patch999 -p1
 
 %build
 buildarch="%{kvm_target}-softmmu"
-------------- next part --------------
commit 4933716beef26b353a1c374d6d8e6dd2e09333af
Author: Michael Tokarev <mjt at tls.msk.ru>
Date:   Sat Apr 5 19:17:54 2014 +0400
Subject: copy OEM ACPI parameters from SLIC table to RSDT
    
When building RSDT table, pick OEM ID fields from uer-supplied SLIC
table instead of using hard-coded QEMU defaults.  This way, say,
OEM version of Windows7 can be run inside qemu using the same OEM
activation as on bare metal, by pointing at system firmware:

  -acpitable file=/sys/firmware/acpi/tables/SLIC

Windows7 requires that OEM ID in RSDT matches those in SLIC to
consider SLIC to be valid.

This is somewhat hackish approach, but it works fairy well in
practice.
    
Signed-off-by: Michael Tokarev <mjt at tls.msk.ru>

diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 79414b4..a8a3f26 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -53,6 +53,7 @@ static const char unsigned dfl_hdr[ACPI_TABLE_HDR_SIZE -
ACPI_TABLE_PFX_SIZE]
 char unsigned *acpi_tables;
 size_t acpi_tables_len;
+size_t slic_table_offset;
 
 static QemuOptsList qemu_acpi_opts = {
     .name = "acpi",
@@ -226,6 +227,10 @@ static void acpi_table_install(const char unsigned *blob,
size_t bloblen,
     /* recalculate checksum */
     ext_hdr->checksum = acpi_checksum((const char unsigned *)ext_hdr +
                                       ACPI_TABLE_PFX_SIZE, acpi_payload_size);
+
+    if (memcmp(ext_hdr->sig, "SLIC", 4) == 0) {
+       slic_table_offset = acpi_tables_len - acpi_payload_size;
+    }
 }
 
 void acpi_table_add(const QemuOpts *opts, Error **errp)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a5d3fbf..9e0e16a 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -224,6 +224,8 @@ static void acpi_get_pci_info(PcPciInfo *info)
 #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
 #define ACPI_BUILD_RSDP_FILE "etc/acpi/rsdp"
 
+extern size_t slic_table_offset;
+
 static void
 build_header(GArray *linker, GArray *table_data,
              AcpiTableHeader *h, const char *sig, int len, uint8_t rev)
@@ -237,6 +239,11 @@ build_header(GArray *linker, GArray *table_data,
     h->oem_revision = cpu_to_le32(1);
     memcpy(h->asl_compiler_id, ACPI_BUILD_APPNAME4, 4);
     h->asl_compiler_revision = cpu_to_le32(1);
+    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);
+    }
     h->checksum = 0;
     /* Checksum to be filled in by Guest linker */
     bios_linker_loader_add_checksum(linker, ACPI_BUILD_TABLE_FILE,
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1349,6 +1349,8 @@
 For data=, only data
 portion of the table is used, all header information is specified in the
 command line.
+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).
 ETEXI
 
 DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
-------------- next part --------------
#!/bin/bash

VERSION=7
REPO=privat
ARCH=x86_64
OS=centos

REPO_BASEDIR=/srv/download
CACHE_BASEDIR=/var/cache/createrepo
VARIABLE=$OS/$VERSION/$REPO/$ARCH
CACHEDIR=$CACHE_BASEDIR/$VARIABLE
REPO_DIR=$REPO_BASEDIR/$VARIABLE

echo
echo "<<< createrepo $VARIABLE >>>"
echo 

chown root:root /srv/download/centos/7/privat/x86_64/Packages/*.rpm
chmod 644 /srv/download/centos/7/privat/x86_64/Packages/*.rpm

mkdir -p $CACHEDIR
createrepo --cachedir $CACHEDIR --database --verbose $REPO_DIR

-------------- next part --------------

[privat]
name=CentOS-$releasever - Privat
baseurl=file:///srv/download/centos/$releasever/privat/$basearch/
gpgcheck=0

Then you should definitely submit a bug with redhat about this, seems like a
serious one.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Gena Makhomed" <gmm at csdoc.com>
> To: centos-virt at centos.org
> Sent: Wednesday, 29 July, 2015 23:09:14
> Subject: [CentOS-virt] CentOS 7.1 + qemu-kvm-ev + SLIC acpitable windows
bug	workaround
> On 29.07.2015 21:34, Nux! wrote:
> 
>> Yes, you can.
>> In fact you can use the binaries from the ovirt repo itself, no need to
rebuild.
> 
> Thank you!
> 
> In fact - I can't use raw binaries from the ovirt repo itself,
> because these qemu-kvm binaries contains one bug,
> which is already fixed in Debian:
> 
> If you want to migrate Windows from hardware node
> to VM using CentOS 7.1 on hardware node and libvirt 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=/sys/firmware/acpi/tables/SLIC'/>
>   </qemu:commandline>
> </domain>
> 
> Winodws not working correctly in this case, because Windows requires,
> what oem_id and oem_table_id from SLIC 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 CentOS 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).
> 
>> ----- Original Message -----
> 
>>> Is it possible to use binary packages build from
>>>
http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/SRPMS/qemu-kvm-ev-2.1.2-23.el7_1.3.1.src.rpm
>>> with plain CentOS 7.1 and use all other packages from CentOS
>>> (libvirt, virt-manager, etc)
>>>
>>> Is it have reasons, if I not use live migrations and qcow2
snapshots?
>>> (instead use zfs, zvols and zfs snapshots for VM disks online
backups)
>>>
>>> Is using qemu-kvm-ev with CentOS 7.1 have any disadvantages?
> 
> --
> Best regards,
>  Gena
> 
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt at centos.org
> http://lists.centos.org/mailman/listinfo/centos-virt

On 30.07.2015 10:49, Nux! wrote:
> Then you should definitely submit a bug with redhat about this, seems like
a serious one.
Ok, done:

https://bugzilla.redhat.com/show_bug.cgi?id=1248758

P.S.

As I can see - bugzilla.redhat.com for oVirt Product
does not contain qemu-kvm-ev Component at all - looks
like this is yet another bug - in the bugzilla settings.

But I can't find how to report this bugzilla misconfiguration,
so I just report this oVirt bugreport as bugreport for package
qemu-kvm-rhev from Red Hat Enterprise Virtualization Manager Product.

I hope this help.
> ----- Original Message -----
>> On 29.07.2015 21:34, Nux! wrote:
>>
>>> Yes, you can.
>>> In fact you can use the binaries from the ovirt repo itself, no
need to rebuild.
>>
>> Thank you!
>>
>> In fact - I can't use raw binaries from the ovirt repo itself,
>> because these qemu-kvm binaries contains one bug,
>> which is already fixed in Debian:
>>
>> If you want to migrate Windows from hardware node
>> to VM using CentOS 7.1 on hardware node and libvirt 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=/sys/firmware/acpi/tables/SLIC'/>
>>    </qemu:commandline>
>> </domain>
>>
>> Winodws not working correctly in this case, because Windows requires,
>> what oem_id and oem_table_id from SLIC 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 CentOS 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).
>>
>>> ----- Original Message -----
>>
>>>> Is it possible to use binary packages build from
>>>>
http://resources.ovirt.org/pub/ovirt-3.5/rpm/el7/SRPMS/qemu-kvm-ev-2.1.2-23.el7_1.3.1.src.rpm
>>>> with plain CentOS 7.1 and use all other packages from CentOS
>>>> (libvirt, virt-manager, etc)
>>>>
>>>> Is it have reasons, if I not use live migrations and qcow2
snapshots?
>>>> (instead use zfs, zvols and zfs snapshots for VM disks online
backups)
>>>>
>>>> Is using qemu-kvm-ev with CentOS 7.1 have any disadvantages?
-- 
Best regards,
  Gena