Re: The latest Qemu release can't bootup VM with latest guest kernel.
Hi Yang, On Thu, 20 May 2021 at 11:27, Yang Zhong wrote: > Hello all, > > I found the latest Qemu release can't bootup the VM with latest guest > kernel(>5.13). > > The normal v6.0.0 release is good to bootup the latest guest kernel. > > There are two issues were found > 1. Guest kernel panic. > 2. kvm disabled by bios > > The panic log as below: > [2.250024] BUG: unable to handle page fault for address: > ac06c55f > [2.252226] #PF: supervisor write access in kernel mode > [2.253892] #PF: error_code(0x0003) - permissions violation > [2.255671] PGD 5940e067 P4D 5940f067 PUD 59410063 PMD 580001e1 > [2.257567] Oops: 0003 [#1] SMP NOPTI > [2.258738] CPU: 2 PID: 313 Comm: systemd-udevd Not tainted 5.13.0-rc1+ > #1 > [2.260899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > 0.0.0 02/06/2015 > [2.263375] RIP: 0010:__send_ipi_mask+0x1bf/0x240 > [2.264855] Code: c0 48 c7 44 24 18 00 00 00 00 e9 48 ff ff ff 48 89 d0 > 4c 09 c8 74 1b 49 63 d7 48 63 74 24 0c b8 0a 00 00 00 4c 89 cb 4c 89 d1 > <0f> 01 d9 48 85 c0 78 4a 48 f7 04 24 00 02 00 00 0f 84 80 fe ff ff > [2.270643] RSP: 0018:ff591a62c0193ab0 EFLAGS: 00010006 > [2.272277] RAX: 000a RBX: 0009 RCX: > > [2.274482] RDX: RSI: 00fc RDI: > ff13a83dc003c830 > [2.276663] RBP: ff591a62c0193b08 R08: 0004 R09: > 0009 > [2.278866] R10: R11: R12: > > [2.281065] R13: ff13a83dc003c830 R14: 00011580 R15: > > [2.283272] FS: 7f23ebd07940() GS:ff13a83e3bd0() > knlGS: > [2.285794] CS: 0010 DS: ES: CR0: 80050033 > [2.287574] CR2: ac06c55f CR3: 000106ce2003 CR4: > 00771ee0 > [2.289757] DR0: DR1: DR2: > > [2.291972] DR3: DR6: fffe0ff0 DR7: > 0400 > [2.294177] PKRU: 5554 > [2.295043] Call Trace: > [2.295820] kvm_smp_send_call_func_ipi+0xe/0x60 > [2.297220] smp_call_function_many_cond+0x25d/0x2a0 > [2.298772] ? flush_tlb_one_kernel+0x20/0x20 > [2.300145] on_each_cpu_cond_mask+0x1e/0x20 > [2.301514] flush_tlb_kernel_range+0x8d/0x90 > [2.302799] __purge_vmap_area_lazy+0xc1/0x6a0 > [2.304097] ? cpumask_next+0x1f/0x20 > [2.305160] ? purge_fragmented_blocks_allcpus+0x3d/0x210 > [2.306686] _vm_unmap_aliases+0xf1/0x120 > [2.307861] change_page_attr_set_clr+0x95/0x280 > [2.309203] set_memory_ro+0x26/0x30 > [2.310259] ? 0xc00f7000 > [2.311214] module_enable_ro.part.58+0x62/0xc0 > [2.312417] do_init_module+0x17a/0x230 > [2.313460] load_module+0x1a30/0x1b00 > [2.314463] ? __do_sys_finit_module+0xad/0x110 > [2.315702] __do_sys_finit_module+0xad/0x110 > [2.316890] do_syscall_64+0x39/0x80 > [2.317868] entry_SYSCALL_64_after_hwframe+0x44/0xae > [2.319226] RIP: 0033:0x7f23ea8f32bd > > > I also used the bisect to get the bad commit id: > f5cc5a5c168674f84bf061cdb307c2d25fba5448 > > This issue is known issue? or some fixs are ready to fix those issues? > thanks! > What's your qemu command line? I'm also having a kernel crash (although I think mine is with a different call stack) when using "-cpu host". The crash doesn't occur when I use "kvm64" cpu type. Gal. > > Regards, > > Yang > > > >
[PATCH] target/i386: Add PDCM feature bit when when CPU's pmu property is enabled
The PDCM feature bit is not enabled when adding the pmu property to a CPU
without this capability (e.g. -cpu qemu64,pmu).
Signed-off-by: Gal Hammer
---
target/i386/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 588f32e136..6e1c8b6019 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5535,6 +5535,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
}
if (!cpu->enable_pmu) {
*ecx &= ~CPUID_EXT_PDCM;
+} else {
+*ecx |= CPUID_EXT_PDCM;
}
break;
case 2:
--
2.26.2
Re: [Qemu-devel] [PATCH V10 3/9] include/standard-headers: add pvrdma related headers
Hi, I'm not familiar with the pvrdma device itself, but I reviewed the changes to the update-linux-headers.sh script. Reviewed-by: Gal Hammer <gham...@redhat.com> Gal. On Mon, Feb 12, 2018 at 8:08 PM, Marcel Apfelbaum <mar...@redhat.com> wrote: > Also modify update-linux-headers.sh script to manage > the headers needed by the pvrdma device. > > Signed-off-by: Marcel Apfelbaum <mar...@redhat.com> > Signed-off-by: Yuval Shaia <yuval.sh...@oracle.com> > --- > .../infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h | 667 > + > .../drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h | 114 > .../infiniband/hw/vmw_pvrdma/pvrdma_verbs.h| 383 > include/standard-headers/rdma/vmw_pvrdma-abi.h | 293 + > scripts/update-linux-headers.sh| 27 + > 5 files changed, 1484 insertions(+) > create mode 100644 > include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h > create mode 100644 > include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_ring.h > create mode 100644 > include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_verbs.h > create mode 100644 include/standard-headers/rdma/vmw_pvrdma-abi.h > > diff --git > a/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h > b/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h > new file mode 100644 > index 00..422eb3f4c1 > --- /dev/null > +++ > b/include/standard-headers/drivers/infiniband/hw/vmw_pvrdma/pvrdma_dev_api.h > @@ -0,0 +1,667 @@ > +/* > + * Copyright (c) 2012-2016 VMware, Inc. All rights reserved. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of EITHER the GNU General Public License > + * version 2 as published by the Free Software Foundation or the BSD > + * 2-Clause License. This program is distributed in the hope that it > + * will be useful, but WITHOUT ANY WARRANTY; WITHOUT EVEN THE IMPLIED > + * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > + * See the GNU General Public License version 2 for more details at > + * http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program available in the file COPYING in the main > + * directory of this source tree. > + * > + * The BSD 2-Clause License > + * > + * Redistribution and use in source and binary forms, with or > + * without modification, are permitted provided that the following > + * conditions are met: > + * > + * - Redistributions of source code must retain the above > + *copyright notice, this list of conditions and the following > + *disclaimer. > + * > + * - Redistributions in binary form must reproduce the above > + *copyright notice, this list of conditions and the following > + *disclaimer in the documentation and/or other materials > + *provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS > + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > + * COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, > + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED > + * OF THE POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#ifndef __PVRDMA_DEV_API_H__ > +#define __PVRDMA_DEV_API_H__ > + > +#include "standard-headers/linux/types.h" > + > +#include "pvrdma_verbs.h" > + > +/* > + * PVRDMA version macros. Some new features require updates to > PVRDMA_VERSION. > + * These macros allow us to check for different features if necessary. > + */ > + > +#define PVRDMA_ROCEV1_VERSION 17 > +#define PVRDMA_ROCEV2_VERSION 18 > +#define PVRDMA_VERSION PVRDMA_ROCEV2_VERSION > + > +#define PVRDMA_BOARD_ID1 > +#define PVRDMA_REV_ID 1 > + > +/* > + * Masks and accessors for page directory, which is a two-level lookup: > + * page directory -> page table -> page. Only one directory for now, but
Re: [Qemu-devel] [PATCH v3 0/2] virtio: improve virtio devices initialization time
Hi Greg, On Mon, Jan 29, 2018 at 7:47 PM, Greg Kurz <gr...@kaod.org> wrote: > On Mon, 29 Jan 2018 16:20:55 +0200 > Gal Hammer <gham...@redhat.com> wrote: > >> Using a cleanup callback function (Version 2 of this patches) in order to >> support transactions fails when the same event notifier fd was used by more >> than one Memory Region. >> >> This time I ask the caller to do the event notifier cleanup by himself. >> > > Much better ! QEMU no longer aborts. Also I could observe a speed-up when > booting a fedora27 guest with 5 virtio-serial devices (max_ports=511), from > 1m40s down to 1m10s. Impressive. :) Thanks for the quick review, testing, and the kudos ;-). After spending some time trying to understand why the previous patch fails I was able to figure it out. I was using "disable-legacy=on,disable-modern=off", so I missed the fact that a "transition" device registers two different memory regions with the same event fd. > For all the patches in this series: > > Reviewed-by: Greg Kurz <gr...@kaod.org> > > and > > Tested-by: Greg Kurz <gr...@kaod.org> > >> Gal Hammer (2): >> virtio: remove event notifier cleanup call on de-assign >> virtio: improve virtio devices initialization time >> >> hw/block/dataplane/virtio-blk.c | 2 ++ >> hw/scsi/virtio-scsi-dataplane.c | 2 ++ >> hw/virtio/vhost.c | 2 ++ >> hw/virtio/virtio-bus.c | 14 ++ >> hw/virtio/virtio.c | 22 +- >> include/hw/virtio/virtio-bus.h | 2 ++ >> 6 files changed, 39 insertions(+), 5 deletions(-) >> > BTW: There is a pending patch for kvm that will trim few more seconds from the boot time... Gal.
[Qemu-devel] [PATCH v3 1/2] virtio: remove event notifier cleanup call on de-assign
The virtio_bus_set_host_notifier function no longer calls
event_notifier_cleanup when a event notifier is removed.
The commit updates the code to match the new behavior and calls
virtio_bus_cleanup_host_notifier after the notifier was de-assign
and no longer in use.
This change is a preparation to allow executing the
virtio_bus_set_host_notifier function in a memory region
transaction.
Signed-off-by: Gal Hammer <gham...@redhat.com>
---
hw/block/dataplane/virtio-blk.c | 2 ++
hw/scsi/virtio-scsi-dataplane.c | 2 ++
hw/virtio/vhost.c | 2 ++
hw/virtio/virtio-bus.c | 14 ++
hw/virtio/virtio.c | 2 ++
include/hw/virtio/virtio-bus.h | 2 ++
6 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index f6fc639..2cb9909 100644
--- a/hw/block/dataplane/virtio-blk.c
+++ b/hw/block/dataplane/virtio-blk.c
@@ -192,6 +192,7 @@ int virtio_blk_data_plane_start(VirtIODevice *vdev)
fprintf(stderr, "virtio-blk failed to set host notifier (%d)\n",
r);
while (i--) {
virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), i, false);
+virtio_bus_cleanup_host_notifier(VIRTIO_BUS(qbus), i);
}
goto fail_guest_notifiers;
}
@@ -267,6 +268,7 @@ void virtio_blk_data_plane_stop(VirtIODevice *vdev)
for (i = 0; i < nvqs; i++) {
virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), i, false);
+virtio_bus_cleanup_host_notifier(VIRTIO_BUS(qbus), i);
}
/* Clean up guest notifier (irq) */
diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c
index add4b3f..1c33322 100644
--- a/hw/scsi/virtio-scsi-dataplane.c
+++ b/hw/scsi/virtio-scsi-dataplane.c
@@ -175,6 +175,7 @@ fail_vrings:
aio_context_release(s->ctx);
for (i = 0; i < vs->conf.num_queues + 2; i++) {
virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), i, false);
+virtio_bus_cleanup_host_notifier(VIRTIO_BUS(qbus), i);
}
k->set_guest_notifiers(qbus->parent, vs->conf.num_queues + 2, false);
fail_guest_notifiers:
@@ -213,6 +214,7 @@ void virtio_scsi_dataplane_stop(VirtIODevice *vdev)
for (i = 0; i < vs->conf.num_queues + 2; i++) {
virtio_bus_set_host_notifier(VIRTIO_BUS(qbus), i, false);
+virtio_bus_cleanup_host_notifier(VIRTIO_BUS(qbus), i);
}
/* Clean up guest notifier (irq) */
diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
index 386aef8..2ee1f37 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vhost.c
@@ -1416,6 +1416,7 @@ fail_vq:
error_report("vhost VQ %d notifier cleanup error: %d", i, -r);
}
assert (e >= 0);
+virtio_bus_cleanup_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i);
}
virtio_device_release_ioeventfd(vdev);
fail:
@@ -1439,6 +1440,7 @@ void vhost_dev_disable_notifiers(struct vhost_dev *hdev,
VirtIODevice *vdev)
error_report("vhost VQ %d notifier cleanup failed: %d", i, -r);
}
assert (r >= 0);
+virtio_bus_cleanup_host_notifier(VIRTIO_BUS(qbus), hdev->vq_index + i);
}
virtio_device_release_ioeventfd(vdev);
}
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index 3042232..f9bc9ea 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -283,20 +283,26 @@ int virtio_bus_set_host_notifier(VirtioBusState *bus, int
n, bool assign)
r = k->ioeventfd_assign(proxy, notifier, n, true);
if (r < 0) {
error_report("%s: unable to assign ioeventfd: %d", __func__, r);
-goto cleanup_event_notifier;
+virtio_bus_cleanup_host_notifier(bus, n);
}
-return 0;
} else {
k->ioeventfd_assign(proxy, notifier, n, false);
}
-cleanup_event_notifier:
+return r;
+}
+
+void virtio_bus_cleanup_host_notifier(VirtioBusState *bus, int n)
+{
+VirtIODevice *vdev = virtio_bus_get_device(bus);
+VirtQueue *vq = virtio_get_queue(vdev, n);
+EventNotifier *notifier = virtio_queue_get_host_notifier(vq);
+
/* Test and clear notifier after disabling event,
* in case poll callback didn't have time to run.
*/
virtio_queue_host_notifier_read(notifier);
event_notifier_cleanup(notifier);
-return r;
}
static char *virtio_bus_get_dev_path(DeviceState *dev)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index d6002ee..3667cd6 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2608,6 +2608,7 @@ assign_error:
event_notifier_set_handler(>host_notifier, NULL);
r = virtio_bus_set_host_notifier(qbus, n, false);
assert(r >= 0);
+virtio_bus_cleanup_host_notifier(qbus, n);
}
return err;
}
@@ -2634,6 +2635,7 @@ static void
virtio_device_stop_ioeventfd_impl(VirtIODevice *vdev)
[Qemu-devel] [PATCH v3 0/2] virtio: improve virtio devices initialization time
Using a cleanup callback function (Version 2 of this patches) in order to support transactions fails when the same event notifier fd was used by more than one Memory Region. This time I ask the caller to do the event notifier cleanup by himself. Gal Hammer (2): virtio: remove event notifier cleanup call on de-assign virtio: improve virtio devices initialization time hw/block/dataplane/virtio-blk.c | 2 ++ hw/scsi/virtio-scsi-dataplane.c | 2 ++ hw/virtio/vhost.c | 2 ++ hw/virtio/virtio-bus.c | 14 ++ hw/virtio/virtio.c | 22 +- include/hw/virtio/virtio-bus.h | 2 ++ 6 files changed, 39 insertions(+), 5 deletions(-) -- 2.7.5
[Qemu-devel] [PATCH v3 2/2] virtio: improve virtio devices initialization time
The loading time of a VM is quite significant when its virtio
devices use a large amount of virt-queues (e.g. a virtio-serial
device with max_ports=511). Most of the time is spend in the
creation of all the required event notifiers (ioeventfd and memory
regions).
This patch pack all the changes to the memory regions in a
single memory transaction.
Reported-by: Sitong Liu <address@hidden>
Reported-by: Xiaoling Gao <address@hidden>
Signed-off-by: Gal Hammer <gham...@redhat.com>
---
hw/virtio/virtio.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 3667cd6..006d3d1 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2572,8 +2572,9 @@ static Property virtio_properties[] = {
static int virtio_device_start_ioeventfd_impl(VirtIODevice *vdev)
{
VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_bus(DEVICE(vdev)));
-int n, r, err;
+int i, n, r, err;
+memory_region_transaction_begin();
for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
VirtQueue *vq = >vq[n];
if (!virtio_queue_get_num(vdev, n)) {
@@ -2596,9 +2597,11 @@ static int
virtio_device_start_ioeventfd_impl(VirtIODevice *vdev)
}
event_notifier_set(>host_notifier);
}
+memory_region_transaction_commit();
return 0;
assign_error:
+i = n; /* save n for a second iteration after transaction is committed. */
while (--n >= 0) {
VirtQueue *vq = >vq[n];
if (!virtio_queue_get_num(vdev, n)) {
@@ -2608,7 +2611,14 @@ assign_error:
event_notifier_set_handler(>host_notifier, NULL);
r = virtio_bus_set_host_notifier(qbus, n, false);
assert(r >= 0);
-virtio_bus_cleanup_host_notifier(qbus, n);
+}
+memory_region_transaction_commit();
+
+while (--i >= 0) {
+if (!virtio_queue_get_num(vdev, i)) {
+continue;
+}
+virtio_bus_cleanup_host_notifier(qbus, i);
}
return err;
}
@@ -2626,6 +2636,7 @@ static void
virtio_device_stop_ioeventfd_impl(VirtIODevice *vdev)
VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_bus(DEVICE(vdev)));
int n, r;
+memory_region_transaction_begin();
for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
VirtQueue *vq = >vq[n];
@@ -2635,6 +2646,13 @@ static void
virtio_device_stop_ioeventfd_impl(VirtIODevice *vdev)
event_notifier_set_handler(>host_notifier, NULL);
r = virtio_bus_set_host_notifier(qbus, n, false);
assert(r >= 0);
+}
+memory_region_transaction_commit();
+
+for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
+if (!virtio_queue_get_num(vdev, n)) {
+continue;
+}
virtio_bus_cleanup_host_notifier(qbus, n);
}
}
--
2.7.5
Re: [Qemu-devel] [PULL 1/1] kvm-all: Partially reverts 4fe6d78b2e to remove the cleanup call
On Mon, Jan 29, 2018 at 6:45 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Sun, Jan 28, 2018 at 04:07:27PM +0200, Gal Hammer wrote: >> Hi, >> >> Sorry for a bad patch and the problems it may have caused. > > Not at all, these things happen. Do you have short term plans to work > on a new version? I already have a solution for it (which I abandoned because I liked the "cleanup" option), I'll submit a patch for a review later today. Gal.
Re: [Qemu-devel] [PULL 1/1] kvm-all: Partially reverts 4fe6d78b2e to remove the cleanup call
Hi,
Sorry for a bad patch and the problems it may have caused.
On Wed, Jan 24, 2018 at 7:08 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Wed, Jan 24, 2018 at 10:34:02AM +0100, Greg Kurz wrote:
>> On Wed, 24 Jan 2018 10:14:57 +0100
>> Paolo Bonzini <pbonz...@redhat.com> wrote:
>>
>> > On 24/01/2018 10:05, Greg Kurz wrote:
>> > > On Wed, 24 Jan 2018 09:46:21 +0100
>> > > Greg Kurz <gr...@kaod.org> wrote:
>> > >
>> > >> Please note that Peter usually doesn't work on Wednesdays. The master
>> > >> branch
>> > >> might remain broken for everyone until tomorrow... :-\
>> > >>
>> > >> And I don't think this is the right fix anyway. See below.
>> > >>
>> > >> On Wed, 24 Jan 2018 00:44:14 +0200
>> > >> "Michael S. Tsirkin" <m...@redhat.com> wrote:
>> > >>
>> > >>> From: Jose Ricardo Ziviani <jos...@linux.vnet.ibm.com>
>> > >>>
>> > >>> This commit partially reverts the commit 4fe6d78b2e because of issues
>> > >>> reported in the virtio.
>> > >>>
>> > >>> Examples:
>> > >>>
>> > >>> $ qemu-system-ppc64 -cpu POWER8 -nographic -vga none -m 4G \
>> > >>> -M pseries,accel=kvm -netdev type=user,id=net0 \
>> > >>> -device virtio-net-pci,netdev=net0 -drive
>> > >>> file=../disk.qcow2,if=virtio
>> > >>>
>> > >>> Populating /vdevice/nvram@7101
>> > >>> Populating /vdevice/v-scsi@7102
>> > >>>SCSI: Looking for devices
>> > >>> 8200 CD-ROM : "QEMU QEMU CD-ROM 2.5+"
>> > >>> Populating /pci@8002000
>> > >>> 00 (D) : 1af4 1000virtio [ net ]
>> > >>> Aborted
>> > >>>
>> > >>> $ qemu-system-x86_64 -m 4G -enable-kvm -drive file=util.qcow2,if=virtio
>> > >>>
>> > >>> Running QEMU with GTK 2.x is deprecated, and will be removed
>> > >>> in a future release. Please switch to GTK 3.x instead
>> > >>> [1]5282 abort
>> > >>>
>> > >>> Reference
>> > >>> http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg05457.html
>> > >>>
>> > >>> Reported-by: Anton Blanchard <an...@samba.org>
>> > >>> Signed-off-by: Jose Ricardo Ziviani <jos...@linux.vnet.ibm.com>
>> > >>> Reviewed-by: Daniel Henrique Barboza <danie...@linux.vnet.ibm.com>
>> > >>> Tested-by: Daniel Henrique Barboza <danie...@linux.vnet.ibm.com>
>> > >>> Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
>> > >>> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
>> > >>> ---
>> > >>> accel/kvm/kvm-all.c | 4
>> > >>> 1 file changed, 4 deletions(-)
>> > >>>
>> > >>> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
>> > >>> index 071f4f5..f290f48 100644
>> > >>> --- a/accel/kvm/kvm-all.c
>> > >>> +++ b/accel/kvm/kvm-all.c
>> > >>> @@ -812,10 +812,6 @@ static void kvm_mem_ioeventfd_del(MemoryListener
>> > >>> *listener,
>> > >>> if (r < 0) {
>> > >>> abort();
>> > >>> }
>> > >>> -
>> > >>> -if (e->cleanup) {
>> > >>> -e->cleanup(e);
>> > >>> -}
>> > >>
>> > >> This looks wrong as the cleanup is expected to do things like closing
>> > >> fds:
>> > >>
>> > >> static void virtio_bus_cleanup_event_notifier(EventNotifier *notifier)
>> > >> {
>> > >> /* Test and clear notifier after disabling event,
>> > >> * in case poll callback didn't have time to run.
>> > >> */
>> > >> virtio_queue_host_notifier_read(notifier);
>> > >> event_notifier_cleanup(notifier);
>> > >> }
>> > >>
>> > >> void event_notifier_cleanup(EventNotifier *e)
>> > >> {
>> > >> if (e->rfd != e->wfd) {
>> > >> close(e->rfd);
>> > >> }
>> &g
Re: [Qemu-devel] [PATCH 0/3 v2] virtio: improve virtio devices initialization time
Hi Ray, On Tue, Jan 16, 2018 at 5:40 PM, Kinsella, Ray <m...@ashroe.eu> wrote: > Hi Gal, > > Brilliant - will test this in the next day or two. > Hopefully this will help resolve the issues I reported last summer. > > http://lists.nongnu.org/archive/html/qemu-devel/2017-07/msg05268.html Thanks for the compliment although a little over-tuned. ;-) I'm not sure my patch will help with your problem of multiple PCI devices (lots of devices). My patch improves the eventfd registration path while it seems that the source of your problem is either limitation enforced by the PCI specifications or by the QEMU's PCI emulation code. > Ray K Gal. > > On 14/01/2018 10:06, Gal Hammer wrote: >> >> A bug was reported about a very slow boot time and a 100% CPU usage of >> both Windows and Linux guests when running a VM with multiple >> virtio-serial devices (https://bugzilla.redhat.com/1528588). >> >> For example, running a VM with 25 virtio-serial devices, each one with >> max_ports=511, could have a boot time of around 30 minutes. With this >> patch (and another patch to kvm) the boot time is reduced to >> approximately 3 minutes. >> >> The patch wraps all the changes made to the Memory Regions during the >> eventfd registrations in a memory regions transaction. I had to add a >> cleanup callback function to the EventNotifier struct, so it will be >> possible to use a transaction in the shutdown code path as well. >> >> Gal Hammer (3): >>qemu: add a cleanup callback function to EventNotifier >>virtio: postpone the execution of event_notifier_cleanup function >>virtio: improve virtio devices initialization time >> >> accel/kvm/kvm-all.c | 4 >> hw/virtio/virtio-bus.c| 19 +++ >> hw/virtio/virtio.c| 5 + >> include/qemu/event_notifier.h | 1 + >> util/event_notifier-posix.c | 5 - >> util/event_notifier-win32.c | 2 ++ >> 6 files changed, 27 insertions(+), 9 deletions(-) >> >
[Qemu-devel] [PATCH 3/3] virtio: improve virtio devices initialization time
The loading time of a VM is quite significant when its virtio
devices use a large amount of virt-queues (e.g. a virtio-serial
device with max_ports=511). Most of the time is spend in the
creation of all the required event notifiers (ioeventfd and memory
regions).
This patch pack all the changes to the memory regions in a
single memory transaction.
Reported-by: Sitong Liu <si...@redhat.com>
Reported-by: Xiaoling Gao <xia...@redhat.com>
Signed-off-by: Gal Hammer <gham...@redhat.com>
---
hw/virtio/virtio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index d6002ee..3ac3491 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2574,6 +2574,7 @@ static int
virtio_device_start_ioeventfd_impl(VirtIODevice *vdev)
VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_bus(DEVICE(vdev)));
int n, r, err;
+memory_region_transaction_begin();
for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
VirtQueue *vq = >vq[n];
if (!virtio_queue_get_num(vdev, n)) {
@@ -2596,6 +2597,7 @@ static int
virtio_device_start_ioeventfd_impl(VirtIODevice *vdev)
}
event_notifier_set(>host_notifier);
}
+memory_region_transaction_commit();
return 0;
assign_error:
@@ -2609,6 +2611,7 @@ assign_error:
r = virtio_bus_set_host_notifier(qbus, n, false);
assert(r >= 0);
}
+memory_region_transaction_commit();
return err;
}
@@ -2625,6 +2628,7 @@ static void
virtio_device_stop_ioeventfd_impl(VirtIODevice *vdev)
VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_bus(DEVICE(vdev)));
int n, r;
+memory_region_transaction_begin();
for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
VirtQueue *vq = >vq[n];
@@ -2635,6 +2639,7 @@ static void
virtio_device_stop_ioeventfd_impl(VirtIODevice *vdev)
r = virtio_bus_set_host_notifier(qbus, n, false);
assert(r >= 0);
}
+memory_region_transaction_commit();
}
void virtio_device_stop_ioeventfd(VirtIODevice *vdev)
--
2.7.5
[Qemu-devel] [PATCH 2/3] virtio: postpone the execution of event_notifier_cleanup function
Use the EventNotifier's cleanup callback function to execute the
event_notifier_cleanup function after kvm unregistered the eventfd.
This change supports running the virtio_bus_set_host_notifier
function inside a memory region transaction. Otherwise, a closed
fd is sent to kvm, which results in a failure.
Signed-off-by: Gal Hammer <gham...@redhat.com>
---
accel/kvm/kvm-all.c| 4
hw/virtio/virtio-bus.c | 19 +++
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index f290f48..071f4f5 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -812,6 +812,10 @@ static void kvm_mem_ioeventfd_del(MemoryListener *listener,
if (r < 0) {
abort();
}
+
+if (e->cleanup) {
+e->cleanup(e);
+}
}
static void kvm_io_ioeventfd_add(MemoryListener *listener,
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index 3042232..8106346 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -256,6 +256,15 @@ bool virtio_bus_ioeventfd_enabled(VirtioBusState *bus)
return k->ioeventfd_assign && k->ioeventfd_enabled(proxy);
}
+static void virtio_bus_cleanup_event_notifier(EventNotifier *notifier)
+{
+/* Test and clear notifier after disabling event,
+ * in case poll callback didn't have time to run.
+ */
+virtio_queue_host_notifier_read(notifier);
+event_notifier_cleanup(notifier);
+}
+
/*
* This function switches ioeventfd on/off in the device.
* The caller must set or clear the handlers for the EventNotifier.
@@ -283,19 +292,13 @@ int virtio_bus_set_host_notifier(VirtioBusState *bus, int
n, bool assign)
r = k->ioeventfd_assign(proxy, notifier, n, true);
if (r < 0) {
error_report("%s: unable to assign ioeventfd: %d", __func__, r);
-goto cleanup_event_notifier;
+virtio_bus_cleanup_event_notifier(notifier);
}
-return 0;
} else {
+notifier->cleanup = virtio_bus_cleanup_event_notifier;
k->ioeventfd_assign(proxy, notifier, n, false);
}
-cleanup_event_notifier:
-/* Test and clear notifier after disabling event,
- * in case poll callback didn't have time to run.
- */
-virtio_queue_host_notifier_read(notifier);
-event_notifier_cleanup(notifier);
return r;
}
--
2.7.5
[Qemu-devel] [PATCH 1/3] qemu: add a cleanup callback function to EventNotifier
Adding a cleanup callback function to the EventNotifier struct
which allows users to execute event_notifier_cleanup in a
different context.
Signed-off-by: Gal Hammer <gham...@redhat.com>
---
include/qemu/event_notifier.h | 1 +
util/event_notifier-posix.c | 5 -
util/event_notifier-win32.c | 2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/qemu/event_notifier.h b/include/qemu/event_notifier.h
index 599c99f..b30a454 100644
--- a/include/qemu/event_notifier.h
+++ b/include/qemu/event_notifier.h
@@ -26,6 +26,7 @@ struct EventNotifier {
int rfd;
int wfd;
#endif
+void (*cleanup)(EventNotifier *);
};
typedef void EventNotifierHandler(EventNotifier *);
diff --git a/util/event_notifier-posix.c b/util/event_notifier-posix.c
index 73c4046..6525666 100644
--- a/util/event_notifier-posix.c
+++ b/util/event_notifier-posix.c
@@ -29,6 +29,7 @@ void event_notifier_init_fd(EventNotifier *e, int fd)
{
e->rfd = fd;
e->wfd = fd;
+e->cleanup = NULL;
}
#endif
@@ -65,6 +66,7 @@ int event_notifier_init(EventNotifier *e, int active)
e->rfd = fds[0];
e->wfd = fds[1];
}
+e->cleanup = NULL;
if (active) {
event_notifier_set(e);
}
@@ -80,10 +82,11 @@ void event_notifier_cleanup(EventNotifier *e)
{
if (e->rfd != e->wfd) {
close(e->rfd);
-e->rfd = -1;
}
close(e->wfd);
+e->rfd = -1;
e->wfd = -1;
+e->cleanup = NULL;
}
int event_notifier_get_fd(const EventNotifier *e)
diff --git a/util/event_notifier-win32.c b/util/event_notifier-win32.c
index 62c53b0..eff8670 100644
--- a/util/event_notifier-win32.c
+++ b/util/event_notifier-win32.c
@@ -19,6 +19,7 @@ int event_notifier_init(EventNotifier *e, int active)
{
e->event = CreateEvent(NULL, TRUE, FALSE, NULL);
assert(e->event);
+e->cleanup = NULL;
return 0;
}
@@ -26,6 +27,7 @@ void event_notifier_cleanup(EventNotifier *e)
{
CloseHandle(e->event);
e->event = NULL;
+e->cleanup = NULL;
}
HANDLE event_notifier_get_handle(EventNotifier *e)
--
2.7.5
[Qemu-devel] [PATCH 0/3 v2] virtio: improve virtio devices initialization time
A bug was reported about a very slow boot time and a 100% CPU usage of both Windows and Linux guests when running a VM with multiple virtio-serial devices (https://bugzilla.redhat.com/1528588). For example, running a VM with 25 virtio-serial devices, each one with max_ports=511, could have a boot time of around 30 minutes. With this patch (and another patch to kvm) the boot time is reduced to approximately 3 minutes. The patch wraps all the changes made to the Memory Regions during the eventfd registrations in a memory regions transaction. I had to add a cleanup callback function to the EventNotifier struct, so it will be possible to use a transaction in the shutdown code path as well. Gal Hammer (3): qemu: add a cleanup callback function to EventNotifier virtio: postpone the execution of event_notifier_cleanup function virtio: improve virtio devices initialization time accel/kvm/kvm-all.c | 4 hw/virtio/virtio-bus.c| 19 +++ hw/virtio/virtio.c| 5 + include/qemu/event_notifier.h | 1 + util/event_notifier-posix.c | 5 - util/event_notifier-win32.c | 2 ++ 6 files changed, 27 insertions(+), 9 deletions(-) -- 2.7.5
Re: [Qemu-devel] [PATCH] virtio: improve virtio devices initialization time
On Thu, Jan 11, 2018 at 9:52 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> On Thu, Jan 11, 2018 at 12:16:56PM +0200, Gal Hammer wrote:
> > The loading time of a VM is quite significant when its virtio
> > devices uses a large amount of virt-queues (e.g. a virtio-serial
> > device with
>
> max_ports=511). Most of the time is spend in the
> > creation of all the required event notifiers (ioeventfd and memory
> > regions).
> >
> > This patch pack all the changes to the memory regions in a
> > single memory transaction.
> >
> > Reported-by: Sitong Liu <si...@redhat.com>
> > Reported-by: Xiaoling Gao <xia...@redhat.com>
> > Signed-off-by: Gal Hammer <gham...@redhat.com>
>
> Nice patch! Any timing numbers to share before/after?
>
Thanks. Unfortunately I made a mistake in the shutdown code (the
transaction is wrapping the code which doesn't modify the memory regions),
so a V2 is on its way.
As for the timing. Running a VM with 25 virtio-serial devices, each one
with max_ports=511, results in a boot time of around 30 minutes. With this
patch (and a another patch to kvm) reduce it to approximately 3 minutes.
This was reported and tracked here:
https://bugzilla.redhat.com/show_bug.cgi?id=1528588
Gal.
>
> > ---
> > hw/virtio/virtio.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index ad564b0..8d8d93d 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -2574,6 +2574,7 @@ static int
> > virtio_device_start_ioeventfd_impl(VirtIODevice
> *vdev)
> > VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_
> bus(DEVICE(vdev)));
> > int n, r, err;
> >
> > +memory_region_transaction_begin();
> > for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
> > VirtQueue *vq = >vq[n];
> > if (!virtio_queue_get_num(vdev, n)) {
> > @@ -2596,6 +2597,7 @@ static int
> > virtio_device_start_ioeventfd_impl(VirtIODevice
> *vdev)
> > }
> > event_notifier_set(>host_notifier);
> > }
> > +memory_region_transaction_commit();
> > return 0;
> >
> > assign_error:
> > @@ -2609,6 +2611,7 @@ assign_error:
> > r = virtio_bus_set_host_notifier(qbus, n, false);
> > assert(r >= 0);
> > }
> > +memory_region_transaction_commit();
> > return err;
> > }
> >
> > @@ -2625,6 +2628,7 @@ static void
> > virtio_device_stop_ioeventfd_impl(VirtIODevice
> *vdev)
> > VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_
> bus(DEVICE(vdev)));
> > int n, r;
> >
> > +memory_region_transaction_begin();
> > for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
> > VirtQueue *vq = >vq[n];
> >
> > @@ -2632,6 +2636,13 @@ static void
> > virtio_device_stop_ioeventfd_impl(VirtIODevice
> *vdev)
> > continue;
> > }
> > event_notifier_set_handler(>host_notifier, NULL);
> > +}
> > +memory_region_transaction_commit();
> > +
> > +for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
> > +if (!virtio_queue_get_num(vdev, n)) {
> > +continue;
> > +}
> > r = virtio_bus_set_host_notifier(qbus, n, false);
> > assert(r >= 0);
> > }
> > --
> > 2.7.5
>
[Qemu-devel] [PATCH] virtio: improve virtio devices initialization time
The loading time of a VM is quite significant when its virtio
devices uses a large amount of virt-queues (e.g. a virtio-serial
device with max_ports=511). Most of the time is spend in the
creation of all the required event notifiers (ioeventfd and memory
regions).
This patch pack all the changes to the memory regions in a
single memory transaction.
Reported-by: Sitong Liu <si...@redhat.com>
Reported-by: Xiaoling Gao <xia...@redhat.com>
Signed-off-by: Gal Hammer <gham...@redhat.com>
---
hw/virtio/virtio.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index ad564b0..8d8d93d 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -2574,6 +2574,7 @@ static int
virtio_device_start_ioeventfd_impl(VirtIODevice *vdev)
VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_bus(DEVICE(vdev)));
int n, r, err;
+memory_region_transaction_begin();
for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
VirtQueue *vq = >vq[n];
if (!virtio_queue_get_num(vdev, n)) {
@@ -2596,6 +2597,7 @@ static int
virtio_device_start_ioeventfd_impl(VirtIODevice *vdev)
}
event_notifier_set(>host_notifier);
}
+memory_region_transaction_commit();
return 0;
assign_error:
@@ -2609,6 +2611,7 @@ assign_error:
r = virtio_bus_set_host_notifier(qbus, n, false);
assert(r >= 0);
}
+memory_region_transaction_commit();
return err;
}
@@ -2625,6 +2628,7 @@ static void
virtio_device_stop_ioeventfd_impl(VirtIODevice *vdev)
VirtioBusState *qbus = VIRTIO_BUS(qdev_get_parent_bus(DEVICE(vdev)));
int n, r;
+memory_region_transaction_begin();
for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
VirtQueue *vq = >vq[n];
@@ -2632,6 +2636,13 @@ static void
virtio_device_stop_ioeventfd_impl(VirtIODevice *vdev)
continue;
}
event_notifier_set_handler(>host_notifier, NULL);
+}
+memory_region_transaction_commit();
+
+for (n = 0; n < VIRTIO_QUEUE_MAX; n++) {
+if (!virtio_queue_get_num(vdev, n)) {
+continue;
+}
r = virtio_bus_set_host_notifier(qbus, n, false);
assert(r >= 0);
}
--
2.7.5
[Qemu-devel] [PATCH] qga: implement the guest-set-vcpus for windows
Signed-off-by: Gal Hammer <gham...@redhat.com>
---
qga/commands-win32.c | 66 ++--
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index d9de23b..a8eb4a0 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -1181,7 +1181,69 @@ void qmp_guest_set_time(bool has_time, int64_t time_ns,
Error **errp)
GuestLogicalProcessorList *qmp_guest_get_vcpus(Error **errp)
{
-error_setg(errp, QERR_UNSUPPORTED);
+PSYSTEM_LOGICAL_PROCESSOR_INFORMATION pslpi, ptr;
+DWORD length;
+GuestLogicalProcessorList *head, **link;
+Error *local_err = NULL;
+int64_t current;
+
+ptr = pslpi = NULL;
+length = 0;
+current = 0;
+head = NULL;
+link =
+
+if ((GetLogicalProcessorInformation(pslpi, ) == FALSE) &&
+(GetLastError() == ERROR_INSUFFICIENT_BUFFER) &&
+(length > sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION))) {
+ptr = pslpi = g_malloc0(length);
+if (GetLogicalProcessorInformation(pslpi, ) == FALSE) {
+error_setg(_err, "Failed to get processor information: %d",
+ (int)GetLastError());
+}
+} else {
+error_setg(_err,
+ "Failed to get processor information buffer length: %d",
+ (int)GetLastError());
+}
+
+while ((local_err == NULL) && (length > 0)) {
+if (pslpi->Relationship == RelationProcessorCore) {
+ULONG_PTR cpu_bits = pslpi->ProcessorMask;
+
+while (cpu_bits > 0) {
+if (!!(cpu_bits & 1)) {
+GuestLogicalProcessor *vcpu;
+GuestLogicalProcessorList *entry;
+
+vcpu = g_malloc0(sizeof *vcpu);
+vcpu->logical_id = current++;
+vcpu->online = true;
+vcpu->has_can_offline = false;
+
+entry = g_malloc0(sizeof *entry);
+entry->value = vcpu;
+
+*link = entry;
+link = >next;
+}
+cpu_bits >>= 1;
+}
+}
+length -= sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION);
+pslpi++; /* next entry */
+}
+
+g_free(ptr);
+
+if (local_err == NULL) {
+/* there's no guest with zero VCPUs */
+g_assert(head != NULL);
+return head;
+}
+
+qapi_free_GuestLogicalProcessorList(head);
+error_propagate(errp, local_err);
return NULL;
}
@@ -1295,7 +1357,7 @@ GList *ga_command_blacklist_init(GList *blacklist)
{
const char *list_unsupported[] = {
"guest-suspend-hybrid",
-"guest-get-vcpus", "guest-set-vcpus",
+"guest-set-vcpus",
"guest-get-memory-blocks", "guest-set-memory-blocks",
"guest-get-memory-block-size",
"guest-fsfreeze-freeze-list",
--
2.1.0
[Qemu-devel] [PATCH] acpi: fix pvpanic device is not shown in ui
Commit 2332333c added a _STA method that hides the device. The fact that the device is not shown in the gui make it harder to install its Windows' device. https://bugzilla.redhat.com/show_bug.cgi?id=1238141 Signed-off-by: Gal Hammer gham...@redhat.com --- hw/i386/acpi-build.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index aed811a..46eddb8 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -1108,8 +1108,8 @@ build_ssdt(GArray *table_data, GArray *linker, aml_append(field, aml_named_field(PEPT, 8)); aml_append(dev, field); -/* device present, functioning, decoding, not shown in UI */ -aml_append(dev, aml_name_decl(_STA, aml_int(0xB))); +/* device present, functioning, decoding, shown in UI */ +aml_append(dev, aml_name_decl(_STA, aml_int(0xF))); method = aml_method(RDPT, 0); aml_append(method, aml_store(aml_name(PEPT), aml_local(0))); -- 2.1.0
[Qemu-devel] [PATCH V16 3/4] i386: add a Virtual Machine Generation ID device
Based on Microsoft's specifications (paper can be downloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/acpi-build.c | 32 +
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 140 +
include/hw/i386/pc.h | 3 +
6 files changed, 178 insertions(+)
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 91d602c..3c2fda8 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -48,3 +48,4 @@ CONFIG_MEM_HOTPLUG=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
CONFIG_I82801B11=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 62575eb..36e654d 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -49,3 +49,4 @@ CONFIG_MEM_HOTPLUG=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
CONFIG_I82801B11=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index b71e942..784e23d 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -112,6 +112,7 @@ typedef struct AcpiMiscInfo {
unsigned dsdt_size;
uint16_t pvpanic_port;
uint16_t applesmc_io_base;
+uint64_t vm_generation_addr;
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -238,6 +239,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-tpm_version = tpm_get_version();
info-pvpanic_port = pvpanic_port();
info-applesmc_io_base = applesmc_port();
+info-vm_generation_addr = vm_generation_addr();
}
/*
@@ -1128,6 +1130,36 @@ build_ssdt(GArray *table_data, GArray *linker,
}
sb_scope = aml_scope(\\_SB);
+
+if (misc-vm_generation_addr) {
+dev = aml_device(VMGI);
+aml_append(dev, aml_name_decl(_HID, aml_string(QEMU0002)));
+aml_append(dev,
+aml_name_decl(_CID, aml_string(VM_Gen_Counter)));
+aml_append(dev,
+aml_name_decl(_DDN, aml_string(VM_Gen_Counter)));
+
+method = aml_method(ADDR, 0);
+pkg = aml_package(2);
+aml_append(pkg, aml_int(misc-vm_generation_addr 0x));
+aml_append(pkg, aml_int(misc-vm_generation_addr 32));
+aml_append(method, aml_store(pkg, aml_local(0)));
+aml_append(method, aml_return(aml_local(0)));
+aml_append(dev, method);
+
+aml_append(sb_scope, dev);
+aml_append(ssdt, sb_scope);
+
+scope = aml_scope(\\_GPE);
+
+method = aml_method(_E00, 0);
+aml_append(method,
+aml_notify(aml_name(\\_SB.VMGI), aml_int(0x80)));
+
+aml_append(scope, method);
+aml_append(ssdt, scope);
+}
+
{
/* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
dev = aml_device(PCI0. stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 4aa76ff..3db11de 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -40,3 +40,4 @@ obj-$(CONFIG_STM32F2XX_SYSCFG) += stm32f2xx_syscfg.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_EDU) += edu.o
+obj-$(CONFIG_VMGENID) += vmgenid.o
diff --git a/hw/misc/vmgenid.c b/hw/misc/vmgenid.c
new file mode 100644
index 000..4484952
--- /dev/null
+++ b/hw/misc/vmgenid.c
@@ -0,0 +1,140 @@
+/*
+ * Virtual Machine Generation ID Device
+ *
+ * Copyright (C) 2015 Red Hat Inc.
+ *
+ * Authors: Gal Hammer gham...@redhat.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include hw/i386/pc.h
+#include hw/acpi/acpi_dev_interface.h
+
+#define VMGENID_DEVICE vmgenid
+
+/* Use the memory address which follows HPET for no special reason. */
+#define VMGENID_DEFAULT_ADDRESS 0xfedf
+
+#define PROPERTY_ADDR addr
+#define PROPERTY_UUID uuid
+
+#define VMGENID(obj) OBJECT_CHECK(VmGenIdState, (obj), VMGENID_DEVICE)
+
+typedef struct VmGenIdState {
+DeviceState parent_obj;
+MemoryRegion iomem;
+uint64_t addr;
+uint8_t guid[16];
+bool guid_set;
+} VmGenIdState;
+
+uint64_t vm_generation_addr(void)
+{
+Object *obj = object_resolve_path_type(, VMGENID_DEVICE, NULL);
+VmGenIdState *s = VMGENID(obj);
+
+if (!obj) {
+return 0;
+}
+return s-addr;
+}
+
+static void update_guest(VmGenIdState *s, bool notify)
+{
+void *ptr = memory_region_get_ram_ptr(s-iomem);
+Object *acpi_obj;
+
+memcpy(ptr, s-guid, sizeof(s-guid));
+memory_region_set_dirty(s-iomem, 0, sizeof(s-guid));
+
+if (notify) {
+acpi_obj = object_resolve_path_type
[Qemu-devel] [PATCH V16 2/4] acpi: add a vm_generation_id_changed method
Add a new method to the AcpiDeviceIfClass interface. The new
method sends an ACPI notfication when the VM generation id is
changed.
Signed-off-by: Gal Hammer gham...@redhat.com
---
hw/acpi/core.c | 8
hw/acpi/ich9.c | 8
hw/acpi/piix4.c | 8
hw/isa/lpc_ich9.c| 1 +
include/hw/acpi/acpi.h | 2 ++
include/hw/acpi/acpi_dev_interface.h | 4
include/hw/acpi/ich9.h | 2 ++
7 files changed, 33 insertions(+)
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 0f201d8..3c8d1eb 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -29,6 +29,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -703,3 +705,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 8a64ffb..cab1af7 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -429,3 +429,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 3bd1d5a..101a13a 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -580,6 +580,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -618,6 +625,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-unplug_request = piix4_device_unplug_request_cb;
hc-unplug = piix4_device_unplug_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index b3e0b1f..f240a3a 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -702,6 +702,7 @@ static void ich9_lpc_class_init(ObjectClass *klass, void
*data)
hc-unplug_request = ich9_device_unplug_request_cb;
hc-unplug = ich9_device_unplug_cb;
adevc-ospm_status = ich9_pm_ospm_status;
+adevc-vm_generation_id_changed = ich9_vm_generation_id_changed;
}
static const TypeInfo ich9_lpc_info = {
diff --git a/include/hw/acpi/acpi.h b/include/hw/acpi/acpi.h
index b20bd55..1a4caf2 100644
--- a/include/hw/acpi/acpi.h
+++ b/include/hw/acpi/acpi.h
@@ -196,4 +196,6 @@ unsigned acpi_table_len(void *current);
void acpi_table_add(const QemuOpts *opts, Error **errp);
void acpi_table_add_builtin(const QemuOpts *opts, Error **errp);
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq);
+
#endif /* !QEMU_HW_ACPI_H */
diff --git a/include/hw/acpi/acpi_dev_interface.h
b/include/hw/acpi/acpi_dev_interface.h
index f245f8d..757ce60 100644
--- a/include/hw/acpi/acpi_dev_interface.h
+++ b/include/hw/acpi/acpi_dev_interface.h
@@ -28,6 +28,9 @@ typedef struct AcpiDeviceIf {
* ospm_status: returns status of ACPI device objects, reported
* via _OST method if device supports it.
*
+ * vm_generation_id_changed: notify the guest that it generation
+ * id was changed.
+ *
* Interface is designed for providing unified interface
* to generic ACPI functionality that could be used without
* knowledge about internals of actual device that implements
@@ -39,5 +42,6 @@ typedef struct AcpiDeviceIfClass {
/* public */
void (*ospm_status)(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
+void (*vm_generation_id_changed)(AcpiDeviceIf *adev);
} AcpiDeviceIfClass;
#endif
diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h
index 77cc65c..497c004 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -70,4 +70,6 @@ void ich9_pm_device_unplug_cb(ICH9LPCPMRegs *pm, DeviceState
*dev,
Error **errp);
void ich9_pm_ospm_status(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
+
+void
[Qemu-devel] [PATCH V16 1/4] docs: vm generation id device's description
Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 33 + 1 file changed, 33 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..d06977a --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,33 @@ +VIRTUAL MACHINE GENERATION ID += + +Copyright (C) 2015 Red Hat, Inc. + +This work is licensed under the terms of the GNU GPL, version 2 or later. +See the COPYING file in the top-level directory. + +=== + +The VM generation ID (vmgenid) device is an emulated device which +is expected to exposes a 128-bit, cryptographically random, integer value +identifier, provided by a management system (It is NOT in the device's +responsibilty to ensure that the value is cryptographically random). + +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +This is specified on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a device with the following ACPI ID: QEMU0002. + +It has two properties: + +uuid - The virtual machine generation ID (A required UUID string) +addr - The uuid memory location (A 64-bit address, defaults to 0xfedf) + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. -- 2.1.0
[Qemu-devel] [PATCH V16 0/4] Virtual Machine Generation ID
Hi, Resending after applying changes requested from Paolo, Igor and Michael. Thanks, Gal. V16 - Remove the sysbus device and use directly a DeviceClass. - Device is created with -device command line parameter - Device have uuid and addr parameters. - Support for 64-bit address. - Shorten the ACPI device description. V15 - Version is based on V7 (fixed address) with new aml apis. V13, V14 - Igor Mammedov's patches. V12 - Fixed bios_linker_loader_add_pointer call parameters. Offset should be relative to the table. V11 - Add required missing files. V10 - Fixed typos in docs and a few clarification. V9 - Add a unit test. - Rebased to version 2.2. - Removed hex.generated the binary files from patch. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (4): docs: vm generation id device's description acpi: add a vm_generation_id_changed method i386: add a Virtual Machine Generation ID device tests: add a unit test for the vmgenid device default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 33 + hw/acpi/core.c | 8 ++ hw/acpi/ich9.c | 8 ++ hw/acpi/piix4.c | 8 ++ hw/i386/acpi-build.c | 32 hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + hw/misc/vmgenid.c| 140 +++ include/hw/acpi/acpi.h | 2 + include/hw/acpi/acpi_dev_interface.h | 4 + include/hw/acpi/ich9.h | 2 + include/hw/i386/pc.h | 3 + tests/Makefile | 2 + tests/vmgenid-test.c | 44 +++ 16 files changed, 290 insertions(+) create mode 100644 docs/specs/vmgenid.txt create mode 100644 hw/misc/vmgenid.c create mode 100644 tests/vmgenid-test.c -- 2.1.0
[Qemu-devel] [PATCH V16 4/4] tests: add a unit test for the vmgenid device
Signed-off-by: Gal Hammer gham...@redhat.com
---
tests/Makefile | 2 ++
tests/vmgenid-test.c | 44
2 files changed, 46 insertions(+)
create mode 100644 tests/vmgenid-test.c
diff --git a/tests/Makefile b/tests/Makefile
index c5e4744..3608068 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -177,6 +177,7 @@ check-qtest-i386-y += tests/pc-cpu-test$(EXESUF)
check-qtest-i386-y += tests/q35-test$(EXESUF)
gcov-files-i386-y += hw/pci-host/q35.c
check-qtest-i386-$(CONFIG_LINUX) += tests/vhost-user-test$(EXESUF)
+check-qtest-i386-y += tests/vmgenid-test$(EXESUF)
check-qtest-x86_64-y = $(check-qtest-i386-y)
gcov-files-i386-y += i386-softmmu/hw/timer/mc146818rtc.c
gcov-files-x86_64-y = $(subst
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y))
@@ -396,6 +397,7 @@ tests/vhost-user-test$(EXESUF): tests/vhost-user-test.o
qemu-char.o qemu-timer.o
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o libqemuutil.a
libqemustub.a
tests/test-write-threshold$(EXESUF): tests/test-write-threshold.o
$(block-obj-y) libqemuutil.a libqemustub.a
+tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o
ifeq ($(CONFIG_POSIX),y)
LIBS += -lutil
diff --git a/tests/vmgenid-test.c b/tests/vmgenid-test.c
new file mode 100644
index 000..dad1f1b
--- /dev/null
+++ b/tests/vmgenid-test.c
@@ -0,0 +1,44 @@
+/*
+ * QTest testcase for VM Generation ID
+ *
+ * Copyright (c) 2015 Red Hat, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include string.h
+#include libqtest.h
+
+static void vmgenid_test(void)
+{
+static const uint8_t expected[16] = {
+0x32, 0x4e, 0x6e, 0xaf, 0xd1, 0xd1, 0x4b, 0xf6,
+0xbf, 0x41, 0xb9, 0xbb, 0x6c, 0x91, 0xfb, 0x87
+};
+uint8_t guid[16];
+uint32_t i;
+
+/* Skip the ACPI ADDR method and read the GUID directly from memory. */
+for (i = 0; i 16; i++) {
+guid[i] = readb(0xfedf + i);
+}
+
+g_assert_cmpuint(sizeof(guid), ==, sizeof(expected));
+g_assert(memcmp(guid, expected, sizeof(guid)) == 0);
+}
+
+int main(int argc, char **argv)
+{
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/vmgenid/vmgenid, vmgenid_test);
+
+qtest_start(-device vmgenid,uuid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87);
+ret = g_test_run();
+
+qtest_end();
+
+return ret;
+}
--
2.1.0
Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
On 08/06/2015 16:58, Daniel P. Berrange wrote: On Mon, Jun 08, 2015 at 03:55:14PM +0200, Paolo Bonzini wrote: On 08/06/2015 15:52, Gal Hammer wrote: 2. Is it possible to create a sysbus device using the -device command line argument? I vaguely recall that it is not possible to do it and that's the reason that I specifically add the device in the pc init. It's now possible, but it is somewhat complicated. I think it's simpler to initialize this unconditionally and hide it (via ACPI _STA) if the vmgenid is all zeros. I didn't understand. I need the device to be a sysbus device so it won't be found as an ISA or a PCI device by Windows. So I need to know what ever or not it is possible to create a sysbus device using -device. In either way it won't be created if vmgenid is not given so no need to hide it using _STA. Windows doesn't enumerate ISA devices when you create them with -device. It just enumerates devices from the ACPI DSDT/SSDT. So it's okay to make it an ISADevice, or to make it a part of another device (e.g. the ISA bridge or the power management device). It's still ugly though. If you make it a sysbus device, you can just add it unconditionally, and define _STA so that Windows only sees it under the appropriate circumstances: for example, return 0 from _STA if the vmgenid (from the command line) is all zeroes. What is the command line option like? Is it -global vmgenid.uuid=foo? FWIW, although the spec for this feature comes from Windows/Microsoft, I'd expect that when we enable it in libvirt, we'll want to make it unconditionally available to all VMs, since its a generically useful information source for guest OS'. Once qemu part will be completed it will be possible to add a module to Linux as well (and maybe use it as a RNG generator source too). Gal. Regards, Daniel
Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
On 08/06/2015 16:43, Paolo Bonzini wrote: On 08/06/2015 15:42, Gal Hammer wrote: On 03/06/2015 19:37, Paolo Bonzini wrote: Since Michael said he'd merge this version, there's just one thing I would change. You can access the region only one byte at a time, and let the memory core fix endianness here: I've applied the change offered below. Thanks. There are two unanswered questions: 1. You wrote that I should not use the memory_region_init_io() function. Should I use memory_region_init_ram() instead? This is related to the uncached vs. cached memory discussion. Michael agreed that it's okay to do it this way. OK. Nothing is changed for now. 2. Is it possible to create a sysbus device using the -device command line argument? I vaguely recall that it is not possible to do it and that's the reason that I specifically add the device in the pc init. It's now possible, but it is somewhat complicated. I think it's simpler to initialize this unconditionally and hide it (via ACPI _STA) if the vmgenid is all zeros. I didn't understand. I need the device to be a sysbus device so it won't be found as an ISA or a PCI device by Windows. So I need to know what ever or not it is possible to create a sysbus device using -device. In either way it won't be created if vmgenid is not given so no need to hide it using _STA. Gal. Paolo
Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
On 08/06/2015 16:55, Paolo Bonzini wrote: On 08/06/2015 15:52, Gal Hammer wrote: 2. Is it possible to create a sysbus device using the -device command line argument? I vaguely recall that it is not possible to do it and that's the reason that I specifically add the device in the pc init. It's now possible, but it is somewhat complicated. I think it's simpler to initialize this unconditionally and hide it (via ACPI _STA) if the vmgenid is all zeros. I didn't understand. I need the device to be a sysbus device so it won't be found as an ISA or a PCI device by Windows. So I need to know what ever or not it is possible to create a sysbus device using -device. In either way it won't be created if vmgenid is not given so no need to hide it using _STA. Windows doesn't enumerate ISA devices when you create them with -device. It just enumerates devices from the ACPI DSDT/SSDT. So it's okay to make it an ISADevice, or to make it a part of another device (e.g. the ISA bridge or the power management device). It's still ugly though. If you make it a sysbus device, you can just add it unconditionally, and define _STA so that Windows only sees it under the appropriate circumstances: for example, return 0 from _STA if the vmgenid (from the command line) is all zeroes. What is the command line option like? Is it -global vmgenid.uuid=foo? Yes. Right now it is a -global and I've been asked to change it to -device, which I remember couldn't be done back then. Gal. Paolo
Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
On 03/06/2015 19:37, Paolo Bonzini wrote:
Since Michael said he'd merge this version, there's just one thing I
would change. You can access the region only one byte at a time, and
let the memory core fix endianness here:
I've applied the change offered below. Thanks.
There are two unanswered questions:
1. You wrote that I should not use the memory_region_init_io() function.
Should I use memory_region_init_ram() instead?
2. Is it possible to create a sysbus device using the -device command
line argument? I vaguely recall that it is not possible to do it and
that's the reason that I specifically add the device in the pc init.
Thanks,
Gal.
On 27/04/2015 13:19, Gal Hammer wrote:
+static uint64_t vmgenid_ram_read(void *opaque, hwaddr addr,
+ unsigned size)
+{
+VmGenIdState *s = VMGENID(opaque);
+uint64_t value;
+
+memcpy(value, s-guid + addr, size);
value = s-guid[addr];
+return value;
+}
+
+static const MemoryRegionOps vmgenid_ram_ops = {
+.read = vmgenid_ram_read,
+.valid = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
And instead of this .valid declaration, use this:
.valid.min_access_size = 1,
.valid.max_access_size = 4,
.impl.min_access_size = 1,
.impl.max_access_size = 1,
+.endianness = DEVICE_NATIVE_ENDIAN,
.endianness = DEVICE_LITTLE_ENDIAN
+};
Thanks,
Paolo
Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
On 08/06/2015 18:22, Michael S. Tsirkin wrote: On Mon, Jun 08, 2015 at 05:17:31PM +0200, Paolo Bonzini wrote: On 08/06/2015 17:01, Michael S. Tsirkin wrote: Are there applications that would actually use this? For microsoft this seems to be mostly driven by ActiveDirectory needs. It seems quite possible that applications solve the problem differently on Linux. I'm not aware of a different solution to the problem on Linux. Paolo Adding it by default for everyone still seems too aggressive. We had a ton of pain with pvpanic exactly because of a similar can't hurt approach. I think a better approach would be to merge the code in qemu, merge a linux driver. Once that's available, and some apps use it, enabling it by default will seem more reasonable. You should not enable it by default. It should be left for the management system to decide. QEmu by itself can't follow rules/spec on when to change the UUID. Gal.
Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
On 28/05/2015 13:25, Paolo Bonzini wrote:
On 27/04/2015 13:19, Gal Hammer wrote:
+static void vmgenid_init(Object *obj)
+{
+SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+VmGenIdState *s = VMGENID(obj);
+
+memory_region_init_io(s-iomem, obj, vmgenid_ram_ops, s, vgid, 16);
This is a small problem. The spec says the memory of the VMGENID should
not be uncacheable, but MMIO _should_ be uncacheable.
This is running on a VM so we maybe not care, but it's worth pointing it
out.
And the way I can fix it would be...? Is there another memory region I
can use?
Thanks,
Gal.
Paolo
+sysbus_init_mmio(sbd, s-iomem);
+
+object_property_add_str(obj, PROPERTY_UUID, NULL, vmgenid_set_uuid, NULL);
+}
+
Re: [Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
On 27/04/2015 16:38, Michael S. Tsirkin wrote:
On Mon, Apr 27, 2015 at 02:19:50PM +0300, Gal Hammer wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/acpi-build.c | 41 +
hw/i386/pc.c | 8 +++
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 116 +
include/hw/i386/pc.h | 3 +
include/hw/misc/vmgenid.h | 21 +++
8 files changed, 192 insertions(+)
create mode 100644 hw/misc/vmgenid.c
create mode 100644 include/hw/misc/vmgenid.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 6a74e00..9fc0a3c 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_MEM_HOTPLUG=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
CONFIG_I82801B11=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 46b87dd..f66fd3c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_MEM_HOTPLUG=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
CONFIG_I82801B11=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index e761005..8d1a761 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -42,6 +42,7 @@
#include hw/acpi/memory_hotplug.h
#include sysemu/tpm.h
#include hw/acpi/tpm.h
+#include hw/misc/vmgenid.h
/* Supported chipsets: */
#include hw/acpi/piix4.h
@@ -116,6 +117,7 @@ typedef struct AcpiMiscInfo {
unsigned dsdt_size;
uint16_t pvpanic_port;
uint16_t applesmc_io_base;
+bool vm_generation_id_set;
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -242,6 +244,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-has_tpm = tpm_find();
info-pvpanic_port = pvpanic_port();
info-applesmc_io_base = applesmc_port();
+info-vm_generation_id_set = vm_generation_id_set();
}
static void acpi_get_pci_info(PcPciInfo *info)
@@ -815,6 +818,44 @@ build_ssdt(GArray *table_data, GArray *linker,
aml_append(ssdt, scope);
}
+if (misc-vm_generation_id_set) {
+scope = aml_scope(\\_SB);
+
+dev = aml_device(VMGI);
+aml_append(dev, aml_name_decl(_HID, aml_string(QEMU0002)));
+aml_append(dev,
+aml_name_decl(_CID, aml_string(VM_Gen_Counter)));
+aml_append(dev,
+aml_name_decl(_DDN, aml_string(VM_Gen_Counter)));
+
+crs = aml_resource_template();
+aml_append(crs, aml_memory32_fixed(aml_ReadOnly,
+VMGENID_BASE_ADDRESS, VMGENID_BASE_ADDR_LEN));
+aml_append(dev, aml_name_decl(_CRS, crs));
+
+aml_append(dev, aml_name_decl(_STA, aml_int(0xF)));
+
+method = aml_method(ADDR, 0);
+pkg = aml_package(2);
+aml_append(pkg, aml_int(VMGENID_BASE_ADDRESS));
+aml_append(pkg, aml_int(0)); /* high 32 bits of UUID buffer addr */
So VMGENID_BASE_ADDRESS 32 then, won't need a comment.
Comments are not evil, you know. But it should be fixed because the
addresses can be 64-bit in this solution.
+aml_append(method, aml_store(pkg, aml_local(0)));
+aml_append(method, aml_return(aml_local(0)));
+aml_append(dev, method);
+
+aml_append(scope, dev);
+aml_append(ssdt, scope);
+
+scope = aml_scope(\\_GPE);
+
+method = aml_method(_E00, 0);
+aml_append(method,
+aml_notify(aml_name(\\_SB.VMGI), aml_int(0x80)));
+
+aml_append(scope, method);
+aml_append(ssdt, scope);
+}
+
sb_scope = aml_scope(_SB);
{
/* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a8e6be1..266c5f3 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -63,6 +63,7 @@
#include hw/pci/pci_host.h
#include acpi-build.h
#include hw/mem/pc-dimm.h
+#include hw/misc/vmgenid.h
#include trace.h
#include qapi/visitor.h
#include qapi-visit.h
@@ -1402,6 +1403,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
int i;
DriveInfo *fd[MAX_FD];
DeviceState *hpet = NULL;
+DeviceState *vmgenid;
int pit_isa_irq = 0;
qemu_irq pit_alt_irq = NULL;
qemu_irq rtc_irq = NULL;
@@ -1491,6 +1493,12 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
fd[i] = drive_get(IF_FLOPPY, 0, i);
}
*floppy = fdctrl_init_isa(isa_bus, fd);
+
+vmgenid = qdev_try_create(NULL, VMGENID_DEVICE);
+if (vmgenid
Re: [Qemu-devel] [PATCH V15 1/5] docs: vm generation id device's description
On 27/04/2015 17:56, Eric Blake wrote: On 04/27/2015 05:19 AM, Gal Hammer wrote: Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 35 +++ 1 file changed, 35 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..86ce6ab --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,35 @@ +VIRTUAL MACHINE GENERATION ID += + +Copyright (C) 2014 Red Hat, Inc. Do you want to include 2015? Done. What you have is good. But it might also be worth documenting how one would set a new value via QMP (I assume it is a matter of finding the right QOM path to the device, then using 'qom-set' on the property). Can be done as a separate patch on top, so: Good idea. I'll add it. Reviewed-by: Eric Blake ebl...@redhat.com Thanks! :-) Gal.
Re: [Qemu-devel] [PATCH V15 1/5] docs: vm generation id device's description
On 27/04/2015 16:55, Michael S. Tsirkin wrote: On Mon, Apr 27, 2015 at 02:19:47PM +0300, Gal Hammer wrote: Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 35 +++ 1 file changed, 35 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..86ce6ab --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,35 @@ +VIRTUAL MACHINE GENERATION ID += + +Copyright (C) 2014 Red Hat, Inc. It's 2015, isn't it? + +This work is licensed under the terms of the GNU GPL, version 2 or later. +See the COPYING file in the top-level directory. + +=== + +The VM generation ID (vmgenid) device is an emulated device which +exposes a 128-bit, cryptographically random, integer value identifier. The value is up to user, let's not claim it's cryptographically random. I'll add a sentence that clear this issue. +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +This is specified on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. No one is expected to locate it using that ID, right? Nope. According to the specs the device should be identified through its _CID and/or _DDN names. + +The device adds a vmgenid.uuid property, which can be modified using +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf000f to store +the GUID's buffer. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. + +Although not specified in Microsoft's document, it is assumed that the +device is expected to use the little-endian system. -- 2.1.0
[Qemu-devel] [PATCH V15 1/5] docs: vm generation id device's description
Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 35 +++ 1 file changed, 35 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..86ce6ab --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,35 @@ +VIRTUAL MACHINE GENERATION ID += + +Copyright (C) 2014 Red Hat, Inc. + +This work is licensed under the terms of the GNU GPL, version 2 or later. +See the COPYING file in the top-level directory. + +=== + +The VM generation ID (vmgenid) device is an emulated device which +exposes a 128-bit, cryptographically random, integer value identifier. +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +This is specified on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. + +The device adds a vmgenid.uuid property, which can be modified using +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf000f to store +the GUID's buffer. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. + +Although not specified in Microsoft's document, it is assumed that the +device is expected to use the little-endian system. -- 2.1.0
[Qemu-devel] [PATCH V15 2/5] acpi: add a vm_generation_id_changed method
Add a new method to the AcpiDeviceIfClass interface. The new
method send an ACPI notfication when the VM generation id is
changed.
Signed-off-by: Gal Hammer gham...@redhat.com
---
hw/acpi/core.c | 8
hw/acpi/ich9.c | 8
hw/acpi/piix4.c | 8
hw/isa/lpc_ich9.c| 1 +
include/hw/acpi/acpi.h | 2 ++
include/hw/acpi/acpi_dev_interface.h | 4
include/hw/acpi/ich9.h | 2 ++
7 files changed, 33 insertions(+)
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 51913d6..d4597c6 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -683,3 +685,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 5352e19..613b82e 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -417,3 +417,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index d1f1179..4708cfc 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -580,6 +580,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -618,6 +625,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-unplug_request = piix4_device_unplug_request_cb;
hc-unplug = piix4_device_unplug_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index dba7585..2626fd5 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -688,6 +688,7 @@ static void ich9_lpc_class_init(ObjectClass *klass, void
*data)
hc-unplug_request = ich9_device_unplug_request_cb;
hc-unplug = ich9_device_unplug_cb;
adevc-ospm_status = ich9_pm_ospm_status;
+adevc-vm_generation_id_changed = ich9_vm_generation_id_changed;
}
static const TypeInfo ich9_lpc_info = {
diff --git a/include/hw/acpi/acpi.h b/include/hw/acpi/acpi.h
index 1f678b4..9373b4d 100644
--- a/include/hw/acpi/acpi.h
+++ b/include/hw/acpi/acpi.h
@@ -185,4 +185,6 @@ unsigned acpi_table_len(void *current);
void acpi_table_add(const QemuOpts *opts, Error **errp);
void acpi_table_add_builtin(const QemuOpts *opts, Error **errp);
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq);
+
#endif /* !QEMU_HW_ACPI_H */
diff --git a/include/hw/acpi/acpi_dev_interface.h
b/include/hw/acpi/acpi_dev_interface.h
index f245f8d..757ce60 100644
--- a/include/hw/acpi/acpi_dev_interface.h
+++ b/include/hw/acpi/acpi_dev_interface.h
@@ -28,6 +28,9 @@ typedef struct AcpiDeviceIf {
* ospm_status: returns status of ACPI device objects, reported
* via _OST method if device supports it.
*
+ * vm_generation_id_changed: notify the guest that it generation
+ * id was changed.
+ *
* Interface is designed for providing unified interface
* to generic ACPI functionality that could be used without
* knowledge about internals of actual device that implements
@@ -39,5 +42,6 @@ typedef struct AcpiDeviceIfClass {
/* public */
void (*ospm_status)(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
+void (*vm_generation_id_changed)(AcpiDeviceIf *adev);
} AcpiDeviceIfClass;
#endif
diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h
index c2d3dba..255a113 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -69,4 +69,6 @@ void ich9_pm_device_unplug_cb(ICH9LPCPMRegs *pm, DeviceState
*dev,
Error **errp);
void ich9_pm_ospm_status(AcpiDeviceIf *adev, ACPIOSTInfoList ***list);
+
+void
[Qemu-devel] [PATCH V15 3/5] aml: implement a 32-bit fixed memory range descriptor
Signed-off-by: Gal Hammer gham...@redhat.com
---
hw/acpi/aml-build.c | 18 ++
include/hw/acpi/aml-build.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index d7945f6..038384f 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -891,3 +891,21 @@ Aml *aml_qword_memory(AmlDecode dec, AmlMinFixed min_fixed,
dec, addr_gran, addr_min, addr_max,
addr_trans, len, flags);
}
+
+Aml *aml_memory32_fixed(AmlReadAndWrite read_and_write,
+uint32_t addr_base, uint32_t addr_len)
+{
+Aml *var = aml_alloc();
+
+/* 32-bit Fixed Memory Range Descriptor */
+build_append_byte(var-buf, 0x86);
+/* minimum length since we do not encode optional fields */
+build_append_byte(var-buf, 0x9);
+build_append_byte(var-buf, 0x0);
+
+build_append_byte(var-buf, !!read_and_write 1);
+build_append_int_noprefix(var-buf, addr_base, sizeof(addr_base));
+build_append_int_noprefix(var-buf, addr_len, sizeof(addr_len));
+
+return var;
+}
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 17d3beb..e3cdd70 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -177,6 +177,9 @@ Aml *aml_qword_memory(AmlDecode dec, AmlMinFixed min_fixed,
uint64_t addr_max, uint64_t addr_trans,
uint64_t len);
+Aml *aml_memory32_fixed(AmlReadAndWrite read_and_write,
+uint32_t addr_base, uint32_t addr_len);
+
/* Block AML object primitives */
Aml *aml_scope(const char *name_format, ...) GCC_FMT_ATTR(1, 2);
Aml *aml_device(const char *name_format, ...) GCC_FMT_ATTR(1, 2);
--
2.1.0
[Qemu-devel] [PATCH V15 0/5] Virtual Machine Generation ID
Hi, Resending patches after going back to the fixed address solution and updating the code to work with the new aml apis. Thanks, Gal. V15 - Version is based on V7 (fixed address) with new aml apis. V13, V14 - Igor Mammedov's patches. V12 - Fixed bios_linker_loader_add_pointer call parameters. Offset should be relative to the table. V11 - Add required missing files. V10 - Fixed typos in docs and a few clarification. V9 - Add a unit test. - Rebased to version 2.2. - Removed hex.generated the binary files from patch. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (5): docs: vm generation id device's description acpi: add a vm_generation_id_changed method aml: implement a 32-bit fixed memory range descriptor i386: add a Virtual Machine Generation ID device tests: add a unit test for the vmgenid device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 35 +++ hw/acpi/aml-build.c | 18 ++ hw/acpi/core.c | 8 +++ hw/acpi/ich9.c | 8 +++ hw/acpi/piix4.c | 8 +++ hw/i386/acpi-build.c | 41 + hw/i386/pc.c | 8 +++ hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + hw/misc/vmgenid.c| 116 +++ include/hw/acpi/acpi.h | 2 + include/hw/acpi/acpi_dev_interface.h | 4 ++ include/hw/acpi/aml-build.h | 3 + include/hw/acpi/ich9.h | 2 + include/hw/i386/pc.h | 3 + include/hw/misc/vmgenid.h| 21 +++ tests/Makefile | 2 + tests/vmgenid-test.c | 44 + 20 files changed, 327 insertions(+) create mode 100644 docs/specs/vmgenid.txt create mode 100644 hw/misc/vmgenid.c create mode 100644 include/hw/misc/vmgenid.h create mode 100644 tests/vmgenid-test.c -- 2.1.0
[Qemu-devel] [PATCH V15 4/5] i386: add a Virtual Machine Generation ID device
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/acpi-build.c | 41 +
hw/i386/pc.c | 8 +++
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 116 +
include/hw/i386/pc.h | 3 +
include/hw/misc/vmgenid.h | 21 +++
8 files changed, 192 insertions(+)
create mode 100644 hw/misc/vmgenid.c
create mode 100644 include/hw/misc/vmgenid.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 6a74e00..9fc0a3c 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_MEM_HOTPLUG=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
CONFIG_I82801B11=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 46b87dd..f66fd3c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_MEM_HOTPLUG=y
CONFIG_XIO3130=y
CONFIG_IOH3420=y
CONFIG_I82801B11=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index e761005..8d1a761 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -42,6 +42,7 @@
#include hw/acpi/memory_hotplug.h
#include sysemu/tpm.h
#include hw/acpi/tpm.h
+#include hw/misc/vmgenid.h
/* Supported chipsets: */
#include hw/acpi/piix4.h
@@ -116,6 +117,7 @@ typedef struct AcpiMiscInfo {
unsigned dsdt_size;
uint16_t pvpanic_port;
uint16_t applesmc_io_base;
+bool vm_generation_id_set;
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -242,6 +244,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-has_tpm = tpm_find();
info-pvpanic_port = pvpanic_port();
info-applesmc_io_base = applesmc_port();
+info-vm_generation_id_set = vm_generation_id_set();
}
static void acpi_get_pci_info(PcPciInfo *info)
@@ -815,6 +818,44 @@ build_ssdt(GArray *table_data, GArray *linker,
aml_append(ssdt, scope);
}
+if (misc-vm_generation_id_set) {
+scope = aml_scope(\\_SB);
+
+dev = aml_device(VMGI);
+aml_append(dev, aml_name_decl(_HID, aml_string(QEMU0002)));
+aml_append(dev,
+aml_name_decl(_CID, aml_string(VM_Gen_Counter)));
+aml_append(dev,
+aml_name_decl(_DDN, aml_string(VM_Gen_Counter)));
+
+crs = aml_resource_template();
+aml_append(crs, aml_memory32_fixed(aml_ReadOnly,
+VMGENID_BASE_ADDRESS, VMGENID_BASE_ADDR_LEN));
+aml_append(dev, aml_name_decl(_CRS, crs));
+
+aml_append(dev, aml_name_decl(_STA, aml_int(0xF)));
+
+method = aml_method(ADDR, 0);
+pkg = aml_package(2);
+aml_append(pkg, aml_int(VMGENID_BASE_ADDRESS));
+aml_append(pkg, aml_int(0)); /* high 32 bits of UUID buffer addr */
+aml_append(method, aml_store(pkg, aml_local(0)));
+aml_append(method, aml_return(aml_local(0)));
+aml_append(dev, method);
+
+aml_append(scope, dev);
+aml_append(ssdt, scope);
+
+scope = aml_scope(\\_GPE);
+
+method = aml_method(_E00, 0);
+aml_append(method,
+aml_notify(aml_name(\\_SB.VMGI), aml_int(0x80)));
+
+aml_append(scope, method);
+aml_append(ssdt, scope);
+}
+
sb_scope = aml_scope(_SB);
{
/* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a8e6be1..266c5f3 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -63,6 +63,7 @@
#include hw/pci/pci_host.h
#include acpi-build.h
#include hw/mem/pc-dimm.h
+#include hw/misc/vmgenid.h
#include trace.h
#include qapi/visitor.h
#include qapi-visit.h
@@ -1402,6 +1403,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
int i;
DriveInfo *fd[MAX_FD];
DeviceState *hpet = NULL;
+DeviceState *vmgenid;
int pit_isa_irq = 0;
qemu_irq pit_alt_irq = NULL;
qemu_irq rtc_irq = NULL;
@@ -1491,6 +1493,12 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
fd[i] = drive_get(IF_FLOPPY, 0, i);
}
*floppy = fdctrl_init_isa(isa_bus, fd);
+
+vmgenid = qdev_try_create(NULL, VMGENID_DEVICE);
+if (vmgenid) {
+qdev_init_nofail(vmgenid);
+sysbus_mmio_map(SYS_BUS_DEVICE(vmgenid), 0, VMGENID_BASE_ADDRESS);
+}
}
void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 4aa76ff..3db11de 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -40,3 +40,4 @@ obj
[Qemu-devel] [PATCH V15 5/5] tests: add a unit test for the vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
tests/Makefile | 2 ++
tests/vmgenid-test.c | 44
2 files changed, 46 insertions(+)
create mode 100644 tests/vmgenid-test.c
diff --git a/tests/Makefile b/tests/Makefile
index 55aa745..6e4905c 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -175,6 +175,7 @@ check-qtest-i386-y += tests/usb-hcd-xhci-test$(EXESUF)
gcov-files-i386-y += hw/usb/hcd-xhci.c
check-qtest-i386-y += tests/pc-cpu-test$(EXESUF)
check-qtest-i386-$(CONFIG_LINUX) += tests/vhost-user-test$(EXESUF)
+check-qtest-i386-y += tests/vmgenid-test$(EXESUF)
check-qtest-x86_64-y = $(check-qtest-i386-y)
gcov-files-i386-y += i386-softmmu/hw/timer/mc146818rtc.c
gcov-files-x86_64-y = $(subst
i386-softmmu/,x86_64-softmmu/,$(gcov-files-i386-y))
@@ -369,6 +370,7 @@ tests/vhost-user-test$(EXESUF): tests/vhost-user-test.o
qemu-char.o qemu-timer.o
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o libqemuutil.a
libqemustub.a
tests/test-write-threshold$(EXESUF): tests/test-write-threshold.o
$(block-obj-y) libqemuutil.a libqemustub.a
+tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o
ifeq ($(CONFIG_POSIX),y)
LIBS += -lutil
diff --git a/tests/vmgenid-test.c b/tests/vmgenid-test.c
new file mode 100644
index 000..abb7974
--- /dev/null
+++ b/tests/vmgenid-test.c
@@ -0,0 +1,44 @@
+/*
+ * QTest testcase for VM Generation ID
+ *
+ * Copyright (c) 2014 Red Hat, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include string.h
+#include libqtest.h
+
+static void vmgenid_test(void)
+{
+static const uint8_t expected[16] = {
+0x32, 0x4e, 0x6e, 0xaf, 0xd1, 0xd1, 0x4b, 0xf6,
+0xbf, 0x41, 0xb9, 0xbb, 0x6c, 0x91, 0xfb, 0x87
+};
+uint8_t guid[16];
+uint32_t i;
+
+/* Skip the ACPI ADDR method and read the GUID directly from memory. */
+for (i = 0; i 16; i++) {
+guid[i] = readb(0xfedf + i);
+}
+
+g_assert_cmpuint(sizeof(guid), ==, sizeof(expected));
+g_assert(memcmp(guid, expected, sizeof(guid)) == 0);
+}
+
+int main(int argc, char **argv)
+{
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/vmgenid/vmgenid, vmgenid_test);
+
+qtest_start(-global vmgenid.uuid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87);
+ret = g_test_run();
+
+qtest_end();
+
+return ret;
+}
--
2.1.0
[Qemu-devel] [PATCH] acpi: add a missing backslash to the \_SB scope.
A predefined scope in the ACPI specs is precede with a backslash.
Signed-off-by: Gal Hammer gham...@redhat.com
---
hw/i386/acpi-build.c| 2 +-
include/hw/acpi/aml-build.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 8d1a761..05c1d34 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -856,7 +856,7 @@ build_ssdt(GArray *table_data, GArray *linker,
aml_append(ssdt, scope);
}
-sb_scope = aml_scope(_SB);
+sb_scope = aml_scope(\\_SB);
{
/* create PCI0.PRES device and its _CRS to reserve CPU hotplug MMIO */
dev = aml_device(PCI0. stringify(CPU_HOTPLUG_RESOURCE_DEVICE));
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 48afb72..cb80f2a 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -120,7 +120,7 @@ void free_aml_allocator(void);
* Joins Aml elements together and helps to construct AML tables
* Examle of usage:
* Aml *table = aml_def_block(SSDT, ...);
- * Aml *sb = aml_scope(\_SB);
+ * Aml *sb = aml_scope(\\_SB);
* Aml *dev = aml_device(PCI0);
*
* aml_append(dev, aml_name_decl(HID, aml_eisaid(PNP0A03)));
--
2.1.0
Re: [Qemu-devel] [PATCH V14 2/3] pc: add a Virtual Machine Generation ID device
On 19/03/2015 11:50, Michael S. Tsirkin wrote: On Wed, Mar 11, 2015 at 04:35:41PM +1100, David Gibson wrote: So it boils down to the fact that windows thinks it's RAM, It thinks it's PCI Standard RAM Controller not RAM itself. so it binds a generic driver to it, but then we get According to device manager no driver is bound to it and neither needed. lucky and it does not try to use it as RAM. Video cards also use a bunch of PCI Standard RAM Controller devices I guess to expose additional VRAM, That doesn't mean that BARs are to be used by OS as conventional RAM it's rather for usage by vendor's driver. Same goes for ivshmem which is also expose RAM bar and has the same CLASS ID, BAR's RAM is used only by means of ivshmem driver. But yes we get lucky that Windows has stub device description. OK. So if you are going to rely on this, I think it's a good idea to get ack from David to confirm this is solvable for pseries. I've looked into this a bit more. We've confirmed it's definitely a bug in SLOF - but fixing it is a bit more subtle than I thought. Basically, SLOF is setting the device_type property for all PCI devices based on the PCI class code - it's device_type = memory that causes the kernel to erroneously pick up the PCI device as regular RAM. In fact, device_type is supposed to indicate the capabilities of the OF driver attached to the device, so it should only be set by an actual OF driver binding to the device, not generically in the PCI code. The catch is whether we'll break any existing SLOF supported devices is we remove setting of the device_type. This will need some testing. I guess we can look for some other IDs to use, as well. Host pci bridge class binds to NO_DRV too: class 0x0604. So that's one other option. There are also many devices for which windows won't require a driver. For example, Intel, taken at random: 2620E8500/E8501 eXternal Memory Bridge 277c82975X Memory Controller Hub 36007300 Chipset Memory Controller Hub Are we more, or less likely to see problems with one of these? It seems hard to decide, either way. I think it is wrong to have a fake PCI device just to avoid the fact that Windows will show the device in the devices tree. If the device doesn't implement the required interface, then it should impersonate to be one. The PCI device implementation might be a simpler/cleaner solution but it can cause more problems if an application or a driver will try to access the device and get might get an access to the GUID memory region. Gal. -- David Gibson dgib...@redhat.com Senior Software Engineer, Virtualization, Red Hat
[Qemu-devel] [PATCH V12 0/3] Virtual Machine Generation ID
Hi, Resending patches after a bug was found in the call to the bios_linker_loader_add_pointer function. Please note that this patch set doesn't include the *.hex.generated files and the binary ACPI tables (make check will fail). Thanks, Gal. V12 - Fixed bios_linker_loader_add_pointer call parameters. Offset should be relative to the table. V11 - Add required missing files. V10 - Fixed typos in docs and a few clarification. V9 - Add a unit test. - Rebased to version 2.2. - Removed hex.generated the binary files from patch. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (3): docs: vm generation id device's description i386: Add a Virtual Machine Generation ID device tests: add a unit test for the vmgenid device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 38 ++ hw/acpi/core.c | 8 +++ hw/acpi/ich9.c | 8 +++ hw/acpi/piix4.c | 8 +++ hw/i386/acpi-build.c | 25 +++ hw/i386/acpi-dsdt.dsl| 4 +- hw/i386/pc.c | 8 +++ hw/i386/q35-acpi-dsdt.dsl| 5 +- hw/i386/ssdt-misc.dsl| 43 hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + hw/misc/vmgenid.c| 131 +++ include/hw/acpi/acpi.h | 2 + include/hw/acpi/acpi_dev_interface.h | 4 ++ include/hw/acpi/ich9.h | 2 + include/hw/i386/pc.h | 3 + include/hw/misc/vmgenid.h| 21 ++ tests/Makefile | 2 + tests/vmgenid-test.c | 48 + 21 files changed, 362 insertions(+), 2 deletions(-) create mode 100644 docs/specs/vmgenid.txt create mode 100644 hw/misc/vmgenid.c create mode 100644 include/hw/misc/vmgenid.h create mode 100644 tests/vmgenid-test.c -- 2.1.0
[Qemu-devel] [PATCH V12 2/3] i386: Add a Virtual Machine Generation ID device
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/core.c | 8 +++
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c | 8 +++
hw/i386/acpi-build.c | 25 +++
hw/i386/acpi-dsdt.dsl| 4 +-
hw/i386/pc.c | 8 +++
hw/i386/q35-acpi-dsdt.dsl| 5 +-
hw/i386/ssdt-misc.dsl| 43
hw/isa/lpc_ich9.c| 1 +
hw/misc/Makefile.objs| 1 +
hw/misc/vmgenid.c| 131 +++
include/hw/acpi/acpi.h | 2 +
include/hw/acpi/acpi_dev_interface.h | 4 ++
include/hw/acpi/ich9.h | 2 +
include/hw/i386/pc.h | 3 +
include/hw/misc/vmgenid.h| 21 ++
18 files changed, 274 insertions(+), 2 deletions(-)
create mode 100644 hw/misc/vmgenid.c
create mode 100644 include/hw/misc/vmgenid.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 51913d6..d4597c6 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -683,3 +685,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 884dab3..dee2b8c 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -403,3 +403,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 184e7e4..61f917d 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -574,6 +574,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -611,6 +618,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-plug = piix4_device_plug_cb;
hc-unplug_request = piix4_device_unplug_request_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4944249..5947447 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -260,6 +260,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1076,6 +1077,7 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t vm_gid_physical_address;
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
@@ -1104,6 +1106,21
[Qemu-devel] [PATCH V12 1/3] docs: vm generation id device's description
Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 38 ++ 1 file changed, 38 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..656d598 --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,38 @@ +VIRTUAL MACHINE GENERATION ID += + +Copyright (C) 2014 Red Hat, Inc. + +This work is licensed under the terms of the GNU GPL, version 2 or later. +See the COPYING file in the top-level directory. + +=== + +The VM generation ID (vmgenid) device is an emulated device which +exposes a 128-bit, cryptographically random, integer value identifier. +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +This is specified on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. + +The device adds a vmgenid.uuid property, which can be modified using +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf0003. The +guest is expected to write the physical address of the GUID's buffer +to that memory resource. This allows the device to modify the GUID if +requested by the management application. Current device's implementation +supports a 32-bit address. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. + +Although not specified in Microsoft's document, it is assumed that the +device is expected to use the little-endian system. -- 2.1.0
[Qemu-devel] [PATCH V12 3/3] tests: add a unit test for the vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
tests/Makefile | 2 ++
tests/vmgenid-test.c | 48
2 files changed, 50 insertions(+)
create mode 100644 tests/vmgenid-test.c
diff --git a/tests/Makefile b/tests/Makefile
index d5df168..6b600c3 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -70,6 +70,7 @@ check-unit-y += tests/test-qemu-opts$(EXESUF)
gcov-files-test-qemu-opts-y = qom/test-qemu-opts.c
check-unit-y += tests/test-write-threshold$(EXESUF)
gcov-files-test-write-threshold-y = block/write-threshold.c
+check-qtest-i386-y += tests/vmgenid-test$(EXESUF)
check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh
@@ -363,6 +364,7 @@ tests/vhost-user-test$(EXESUF): tests/vhost-user-test.o
qemu-char.o qemu-timer.o
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o libqemuutil.a
libqemustub.a
tests/test-write-threshold$(EXESUF): tests/test-write-threshold.o
$(block-obj-y) libqemuutil.a libqemustub.a
+tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o
ifeq ($(CONFIG_POSIX),y)
LIBS += -lutil
diff --git a/tests/vmgenid-test.c b/tests/vmgenid-test.c
new file mode 100644
index 000..d9c3e29
--- /dev/null
+++ b/tests/vmgenid-test.c
@@ -0,0 +1,48 @@
+/*
+ * QTest testcase for VM Generation ID
+ *
+ * Copyright (c) 2014 Red Hat, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include string.h
+#include libqtest.h
+
+static void vmgenid_test(void)
+{
+static const uint8_t expected[16] = {
+0x32, 0x4e, 0x6e, 0xaf, 0xd1, 0xd1, 0x4b, 0xf6,
+0xbf, 0x41, 0xb9, 0xbb, 0x6c, 0x91, 0xfb, 0x87
+};
+uint8_t guid[16];
+uint32_t i;
+
+// Emulate the ACPI _INI method (tells the device where the physical
+// memory was allocated.
+writel(0xfedf, 0x0001f000);
+
+// Skip the ACPI ADDR method and read the GUID directly from memory.
+for (i = 0; i 16; i++) {
+guid[i] = readb(0x0001f000 + i);
+}
+
+g_assert_cmpuint(sizeof(guid), ==, sizeof(expected));
+g_assert(memcmp(guid, expected, sizeof(guid)) == 0);
+}
+
+int main(int argc, char **argv)
+{
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/vmgenid/vmgenid, vmgenid_test);
+
+qtest_start(-global vmgenid.uuid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87);
+ret = g_test_run();
+
+qtest_end();
+
+return ret;
+}
--
2.1.0
Re: [Qemu-devel] [PATCH V11 2/3] i386: Add a Virtual Machine Generation ID device
Hi Igor,
- Original Message -
From: Igor Mammedov imamm...@redhat.com
To: Gal Hammer gham...@redhat.com
Cc: qemu-devel@nongnu.org, m...@redhat.com
Sent: Monday, February 2, 2015 3:55:02 PM
Subject: Re: [Qemu-devel] [PATCH V11 2/3] i386: Add a Virtual Machine
Generation ID device
On Mon, 02 Feb 2015 15:13:39 +0200
Gal Hammer gham...@redhat.com wrote:
On 02/02/2015 14:46, Igor Mammedov wrote:
On Sun, 01 Feb 2015 14:56:26 +0200
Gal Hammer gham...@redhat.com wrote:
On 22/01/2015 15:52, Igor Mammedov wrote:
On Tue, 16 Dec 2014 17:50:43 +0200
Gal Hammer gham...@redhat.com wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -257,6 +257,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1068,6 +1069,8 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t vm_gid_physical_address;
+uint32_t vm_gid_offset = 0;
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
@@ -1096,6 +1099,21 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_isa_pest[0], 16, misc-pvpanic_port);
+if (vm_generation_id_set()) {
+vm_gid_physical_address = ssdt_start +
ssdt_acpi_vm_gid_addr[0];
+bios_linker_loader_alloc(linker, ACPI_BUILD_VMGENID_FILE, 8,
true);
+bios_linker_loader_add_pointer(linker,
ACPI_BUILD_VMGENID_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ vm_gid_offset,
+ sizeof(vm_gid_offset));
could some explain how this pointer magic works,
I can try, but don't you think that a magic is gone once explained? ;-)
From my weak understanding it seems broken.
Lets see:
[1] vm_gid_offset - must be pointer inside of dest_file blob
(ACPI_BUILD_VMGENID_FILE)
[2] vm_gid_offset - should hold offset of the place inside of
src_file
(ACPI_BUILD_TABLE_FILE) where to pointer inside
of dest_file should point to
The vm_gid_offset should point where in the ACPI_BUILD_VMGENID_FILE the
VM's GUID is stored. At the moment, it should always be zero because the
GUID is stored at the begging of the ACPI_BUILD_VMGENID_FILE.
now:
vm_gid_physical_address - holds [2] i.e. offset of VGIA constant in
inside SSDT in ACPI_BUILD_TABLE_FILE.
+ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid_addr[0], 32,
vm_gid_physical_address);
Then we write this offset into VGIA in ACPI_BUILD_TABLE_FILE.
Yes. This offset is later patched by the linker to the full physical
address.
After BIOS loads tables it's going to patch at
[3] ACPI_BUILD_VMGENID_FILE + (vm_gid_offset - table_data-data) /*
only god knows where it will be/
and on top of it write in it value:
*(ACPI_BUILD_TABLE_FILE + *[3])
We know exactly where it is, no need to call for god's help :-).
This approach in general of patching arbitrary place in AML blob
to get PHY addr of buffer with UUID, is quite a hack, especially
in light of that we are trying to hide all direct access to AML
blobs with related pointer arithmetic and manual patching.
Why not reserve some potion of RAM and pass to BIOS/guest
a reservation so it won't be part of AddressRangeMemory or
AddressRangeACPI as MS spec requires? Then you won't need
jump all above hoops to just get buffer's PHY addr.
I'll be glad to hear a new idea that I didn't already try in one of
other previous patches. The problem is that the specification requires
working with a physical address, so it must be allocated from inside the
guest. Since the OS is not exist in this stage and I also don't want to
write a special driver just to allocate this buffer I had to choose this
approach.
how about creating device which will map 4K MMIO region in PCI hole
address space and passing it as a reservation via e820 table we have
Re: [Qemu-devel] [PATCH V11 2/3] i386: Add a Virtual Machine Generation ID device
On 02/02/2015 14:46, Igor Mammedov wrote:
On Sun, 01 Feb 2015 14:56:26 +0200
Gal Hammer gham...@redhat.com wrote:
On 22/01/2015 15:52, Igor Mammedov wrote:
On Tue, 16 Dec 2014 17:50:43 +0200
Gal Hammer gham...@redhat.com wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -257,6 +257,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1068,6 +1069,8 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t vm_gid_physical_address;
+uint32_t vm_gid_offset = 0;
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
@@ -1096,6 +1099,21 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_isa_pest[0], 16, misc-pvpanic_port);
+if (vm_generation_id_set()) {
+vm_gid_physical_address = ssdt_start + ssdt_acpi_vm_gid_addr[0];
+bios_linker_loader_alloc(linker, ACPI_BUILD_VMGENID_FILE, 8, true);
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_VMGENID_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ vm_gid_offset,
+ sizeof(vm_gid_offset));
could some explain how this pointer magic works,
I can try, but don't you think that a magic is gone once explained? ;-)
From my weak understanding it seems broken.
Lets see:
[1] vm_gid_offset - must be pointer inside of dest_file blob
(ACPI_BUILD_VMGENID_FILE)
[2] vm_gid_offset - should hold offset of the place inside of src_file
(ACPI_BUILD_TABLE_FILE) where to pointer inside of
dest_file should point to
The vm_gid_offset should point where in the ACPI_BUILD_VMGENID_FILE the
VM's GUID is stored. At the moment, it should always be zero because the
GUID is stored at the begging of the ACPI_BUILD_VMGENID_FILE.
now:
vm_gid_physical_address - holds [2] i.e. offset of VGIA constant in inside
SSDT in ACPI_BUILD_TABLE_FILE.
+ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid_addr[0], 32, vm_gid_physical_address);
Then we write this offset into VGIA in ACPI_BUILD_TABLE_FILE.
Yes. This offset is later patched by the linker to the full physical
address.
After BIOS loads tables it's going to patch at
[3] ACPI_BUILD_VMGENID_FILE + (vm_gid_offset - table_data-data) /* only
god knows where it will be/
and on top of it write in it value:
*(ACPI_BUILD_TABLE_FILE + *[3])
We know exactly where it is, no need to call for god's help :-).
This approach in general of patching arbitrary place in AML blob
to get PHY addr of buffer with UUID, is quite a hack, especially
in light of that we are trying to hide all direct access to AML
blobs with related pointer arithmetic and manual patching.
Why not reserve some potion of RAM and pass to BIOS/guest
a reservation so it won't be part of AddressRangeMemory or
AddressRangeACPI as MS spec requires? Then you won't need
jump all above hoops to just get buffer's PHY addr.
I'll be glad to hear a new idea that I didn't already try in one of
other previous patches. The problem is that the specification requires
working with a physical address, so it must be allocated from inside the
guest. Since the OS is not exist in this stage and I also don't want to
write a special driver just to allocate this buffer I had to choose this
approach.
how about creating device which will map 4K MMIO region in PCI hole
address space and passing it as a reservation via e820 table we have in QEMU.
Then address could be directly built in ACPI tables as constant value
at the time of ACPI tables creation.
Isn't this will cause a VMEXIT when the guest is reading the GUID? If it
is then this idea was already presented and Michael didn't approve it.
That way it would be possible to get address of buffer without
firmware + guest OS doing anything and going through quite complex
chain for getting buffer address (qemu-bios-OSPM-qemu).
If you go current route, it would be needed to teach linker a new command
to make reservation in E820 so that allocated buffer won't be part of
of AddressRangeMemory as required by spec or anything else.
Which would make already hard
Re: [Qemu-devel] [PATCH V11 2/3] i386: Add a Virtual Machine Generation ID device
On 22/01/2015 15:52, Igor Mammedov wrote:
On Tue, 16 Dec 2014 17:50:43 +0200
Gal Hammer gham...@redhat.com wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -257,6 +257,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1068,6 +1069,8 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t vm_gid_physical_address;
+uint32_t vm_gid_offset = 0;
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
@@ -1096,6 +1099,21 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_isa_pest[0], 16, misc-pvpanic_port);
+if (vm_generation_id_set()) {
+vm_gid_physical_address = ssdt_start + ssdt_acpi_vm_gid_addr[0];
+bios_linker_loader_alloc(linker, ACPI_BUILD_VMGENID_FILE, 8, true);
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_VMGENID_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ vm_gid_offset,
+ sizeof(vm_gid_offset));
could some explain how this pointer magic works,
I can try, but don't you think that a magic is gone once explained? ;-)
From my weak understanding it seems broken.
Lets see:
[1] vm_gid_offset - must be pointer inside of dest_file blob
(ACPI_BUILD_VMGENID_FILE)
[2] vm_gid_offset - should hold offset of the place inside of src_file
(ACPI_BUILD_TABLE_FILE) where to pointer inside of
dest_file should point to
The vm_gid_offset should point where in the ACPI_BUILD_VMGENID_FILE the
VM's GUID is stored. At the moment, it should always be zero because the
GUID is stored at the begging of the ACPI_BUILD_VMGENID_FILE.
now:
vm_gid_physical_address - holds [2] i.e. offset of VGIA constant in inside
SSDT in ACPI_BUILD_TABLE_FILE.
+ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid_addr[0], 32, vm_gid_physical_address);
Then we write this offset into VGIA in ACPI_BUILD_TABLE_FILE.
Yes. This offset is later patched by the linker to the full physical
address.
After BIOS loads tables it's going to patch at
[3] ACPI_BUILD_VMGENID_FILE + (vm_gid_offset - table_data-data) /* only god
knows where it will be/
and on top of it write in it value:
*(ACPI_BUILD_TABLE_FILE + *[3])
We know exactly where it is, no need to call for god's help :-).
This approach in general of patching arbitrary place in AML blob
to get PHY addr of buffer with UUID, is quite a hack, especially
in light of that we are trying to hide all direct access to AML
blobs with related pointer arithmetic and manual patching.
Why not reserve some potion of RAM and pass to BIOS/guest
a reservation so it won't be part of AddressRangeMemory or
AddressRangeACPI as MS spec requires? Then you won't need
jump all above hoops to just get buffer's PHY addr.
I'll be glad to hear a new idea that I didn't already try in one of
other previous patches. The problem is that the specification requires
working with a physical address, so it must be allocated from inside the
guest. Since the OS is not exist in this stage and I also don't want to
write a special driver just to allocate this buffer I had to choose this
approach.
[...]
typedef
@@ -1790,6 +1811,11 @@ void acpi_setup(PcGuestInfo *guest_info)
fw_cfg_add_file(guest_info-fw_cfg, ACPI_BUILD_TPMLOG_FILE,
tables.tcpalog-data, acpi_data_len(tables.tcpalog));
+/* Add a 128-bit fw cfg file which stores the VM generation id. */
+g_array_set_size(tables.vmgenid, 16);
+fw_cfg_add_file(guest_info-fw_cfg, ACPI_BUILD_VMGENID_FILE,
+tables.vmgenid-data, tables.vmgenid-len);
shouldn't it be migratable? /i.e. acpi_add_rom_blob(...)/
I'm not too familiar with the migration process, but I assume that this
memory will be copied as part of the guest memory.
Gal.
[Qemu-devel] [PATCH V2] char: restore stdio echo on resume from suspend.
The monitor's auto-completion feature stopped working when stdio is used
as an input and qemu was resumed after it was suspended (using ctrl-z).
Signed-off-by: Gal Hammer gham...@redhat.com
---
V2 - restore old echo state rather than alway disable it.
- don't check signal identifier in the handler function.
- use sigaction() and not signal().
---
qemu-char.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/qemu-char.c b/qemu-char.c
index ef84b53..5430b87 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1112,6 +1112,9 @@ static struct termios oldtty;
static int old_fd0_flags;
static bool stdio_in_use;
static bool stdio_allow_signal;
+static bool stdio_echo_state;
+
+static void qemu_chr_set_echo_stdio(CharDriverState *chr, bool echo);
static void term_exit(void)
{
@@ -1119,10 +1122,17 @@ static void term_exit(void)
fcntl(0, F_SETFL, old_fd0_flags);
}
+static void term_stdio_handler(int sig)
+{
+/* restore echo after resume from suspend. */
+qemu_chr_set_echo_stdio(NULL, stdio_echo_state);
+}
+
static void qemu_chr_set_echo_stdio(CharDriverState *chr, bool echo)
{
struct termios tty;
+stdio_echo_state = echo;
tty = oldtty;
if (!echo) {
tty.c_iflag = ~(IGNBRK|BRKINT|PARMRK|ISTRIP
@@ -1149,6 +1159,7 @@ static void qemu_chr_close_stdio(struct CharDriverState
*chr)
static CharDriverState *qemu_chr_open_stdio(ChardevStdio *opts)
{
CharDriverState *chr;
+struct sigaction act;
if (is_daemonized()) {
error_report(cannot use stdio with -daemonize);
@@ -1166,6 +1177,10 @@ static CharDriverState *qemu_chr_open_stdio(ChardevStdio
*opts)
qemu_set_nonblock(0);
atexit(term_exit);
+memset(act, 0, sizeof(act));
+act.sa_handler = term_stdio_handler;
+sigaction(SIGCONT, act, NULL);
+
chr = qemu_chr_open_fd(0, 1);
chr-chr_close = qemu_chr_close_stdio;
chr-chr_set_echo = qemu_chr_set_echo_stdio;
--
2.1.0
Re: [Qemu-devel] [PATCH] char: disable stdio echo on resume from suspend.
On 06/01/2015 15:49, Peter Maydell wrote:
On 5 January 2015 at 09:21, Gal Hammer gham...@redhat.com wrote:
The monitor's auto-completion feature stopped working when stdio is used
as an input and qemu was resumed after it was suspended (using ctrl-z).
Signed-off-by: Gal Hammer gham...@redhat.com
---
qemu-char.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/qemu-char.c b/qemu-char.c
index ef84b53..786df33 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1113,12 +1113,22 @@ static int old_fd0_flags;
static bool stdio_in_use;
static bool stdio_allow_signal;
+static void qemu_chr_set_echo_stdio(CharDriverState *chr, bool echo);
+
static void term_exit(void)
{
tcsetattr (0, TCSANOW, oldtty);
fcntl(0, F_SETFL, old_fd0_flags);
}
+static void term_stdio_handler(int sig)
+{
+if (sig == SIGCONT) {
...why do we need this check? We don't register the function
for any other signals...
It's a caution and not a must. It can be removed if you think it is
redundant.
+/* echo should be off after resume from suspend. */
+qemu_chr_set_echo_stdio(NULL, false);
Should echo really be always off, even if the thing using the
char device had set it to on?
That's what the function qemu_chr_open_stdio() do, always set the stdio
char device echo to off. I didn't change the current behavior I just
restore it.
As I understood from my tests, the auto-complete feature doesn't work if
the echo is enabled because pressing the tab key prints a tab char.
+}
+}
+
static void qemu_chr_set_echo_stdio(CharDriverState *chr, bool echo)
{
struct termios tty;
@@ -1165,6 +1175,7 @@ static CharDriverState *qemu_chr_open_stdio(ChardevStdio
*opts)
tcgetattr(0, oldtty);
qemu_set_nonblock(0);
atexit(term_exit);
+signal(SIGCONT, term_stdio_handler);
This should probably be using sigaction() which is what we use
elsewhere for signal handler registration.
signal() is used in the code. Although I can switch to sigaction() and
earn few more LOC ;-).
-- PMM
Gal.
Re: [Qemu-devel] [PATCH] char: disable stdio echo on resume from suspend.
- Original Message -
From: Peter Maydell peter.mayd...@linaro.org
To: Gal Hammer gham...@redhat.com
Cc: Paolo Bonzini pbonz...@redhat.com, QEMU Developers
qemu-devel@nongnu.org
Sent: Tuesday, January 6, 2015 4:36:19 PM
Subject: Re: [Qemu-devel] [PATCH] char: disable stdio echo on resume from
suspend.
On 6 January 2015 at 14:30, Gal Hammer gham...@redhat.com wrote:
On 06/01/2015 15:49, Peter Maydell wrote:
On 5 January 2015 at 09:21, Gal Hammer gham...@redhat.com wrote:
The monitor's auto-completion feature stopped working when stdio is used
as an input and qemu was resumed after it was suspended (using ctrl-z).
+/* echo should be off after resume from suspend. */
+qemu_chr_set_echo_stdio(NULL, false);
Should echo really be always off, even if the thing using the
char device had set it to on?
That's what the function qemu_chr_open_stdio() do, always set the stdio
char
device echo to off. I didn't change the current behavior I just restore it.
But qemu_chr_open_stdio also registers this function as the
chr_set_echo pointer in the CharDriverState, so if the
user of the CharDriverState calls qemu_chr_fe_set_echo(chr, true)
then we'll set the echo to on. And then if we ^Z and resume, your
patch will end up setting the echo to off, which seems wrong.
I've missed the fact that qemu_chr_fe_set_echo(chr, true) is called if the
monitor is in qmp mode. I'll post a new version of this patch.
As I understood from my tests, the auto-complete feature doesn't work if
the
echo is enabled because pressing the tab key prints a tab char.
Right, if the echo was disabled we want to make sure it is disabled.
But if the echo wasn't disabled we don't want to disable it.
+}
+}
+
static void qemu_chr_set_echo_stdio(CharDriverState *chr, bool echo)
{
struct termios tty;
@@ -1165,6 +1175,7 @@ static CharDriverState
*qemu_chr_open_stdio(ChardevStdio *opts)
tcgetattr(0, oldtty);
qemu_set_nonblock(0);
atexit(term_exit);
+signal(SIGCONT, term_stdio_handler);
This should probably be using sigaction() which is what we use
elsewhere for signal handler registration.
signal() is used in the code.
Only when we're setting a signal to SIG_IGN, I think. signal()'s
semantics aren't portable, which is why we use sigaction().
[See the Linux signal(2) manpage for some discussion of this.]
No problem. I'll use sigaction() and won't check the signal identifier in the
handler function.
thanks
-- PMM
Gal.
[Qemu-devel] [PATCH] char: disable stdio echo on resume from suspend.
The monitor's auto-completion feature stopped working when stdio is used
as an input and qemu was resumed after it was suspended (using ctrl-z).
Signed-off-by: Gal Hammer gham...@redhat.com
---
qemu-char.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/qemu-char.c b/qemu-char.c
index ef84b53..786df33 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1113,12 +1113,22 @@ static int old_fd0_flags;
static bool stdio_in_use;
static bool stdio_allow_signal;
+static void qemu_chr_set_echo_stdio(CharDriverState *chr, bool echo);
+
static void term_exit(void)
{
tcsetattr (0, TCSANOW, oldtty);
fcntl(0, F_SETFL, old_fd0_flags);
}
+static void term_stdio_handler(int sig)
+{
+if (sig == SIGCONT) {
+/* echo should be off after resume from suspend. */
+qemu_chr_set_echo_stdio(NULL, false);
+}
+}
+
static void qemu_chr_set_echo_stdio(CharDriverState *chr, bool echo)
{
struct termios tty;
@@ -1165,6 +1175,7 @@ static CharDriverState *qemu_chr_open_stdio(ChardevStdio
*opts)
tcgetattr(0, oldtty);
qemu_set_nonblock(0);
atexit(term_exit);
+signal(SIGCONT, term_stdio_handler);
chr = qemu_chr_open_fd(0, 1);
chr-chr_close = qemu_chr_close_stdio;
--
2.1.0
[Qemu-devel] [PATCH V11 0/3] Virtual Machine Generation ID
Hi, Resending patches after the release of version 2.2 and after I've noticed that some of the required files are missing. Please note that this patch set doesn't include the *.hex.generated files and the binary ACPI tables (make check will fail). Thanks, Gal. V11 - Add required missing files. V10 - Fixed typos in docs and a few clarification. V9 - Add a unit test. - Rebased to version 2.2. - Removed hex.generated the binary files from patch. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (3): docs: vm generation id device's description i386: Add a Virtual Machine Generation ID device tests: add a unit test for the vmgenid device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 38 ++ hw/acpi/core.c | 8 +++ hw/acpi/ich9.c | 8 +++ hw/acpi/piix4.c | 8 +++ hw/i386/acpi-build.c | 26 +++ hw/i386/acpi-dsdt.dsl| 4 +- hw/i386/pc.c | 8 +++ hw/i386/q35-acpi-dsdt.dsl| 5 +- hw/i386/ssdt-misc.dsl| 43 hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + hw/misc/vmgenid.c| 131 +++ include/hw/acpi/acpi.h | 2 + include/hw/acpi/acpi_dev_interface.h | 4 ++ include/hw/acpi/ich9.h | 2 + include/hw/i386/pc.h | 3 + include/hw/misc/vmgenid.h| 21 ++ tests/Makefile | 2 + tests/vmgenid-test.c | 48 + 21 files changed, 363 insertions(+), 2 deletions(-) create mode 100644 docs/specs/vmgenid.txt create mode 100644 hw/misc/vmgenid.c create mode 100644 include/hw/misc/vmgenid.h create mode 100644 tests/vmgenid-test.c -- 2.1.0
[Qemu-devel] [PATCH V11 2/3] i386: Add a Virtual Machine Generation ID device
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/core.c | 8 +++
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c | 8 +++
hw/i386/acpi-build.c | 26 +++
hw/i386/acpi-dsdt.dsl| 4 +-
hw/i386/pc.c | 8 +++
hw/i386/q35-acpi-dsdt.dsl| 5 +-
hw/i386/ssdt-misc.dsl| 43
hw/isa/lpc_ich9.c| 1 +
hw/misc/Makefile.objs| 1 +
hw/misc/vmgenid.c| 131 +++
include/hw/acpi/acpi.h | 2 +
include/hw/acpi/acpi_dev_interface.h | 4 ++
include/hw/acpi/ich9.h | 2 +
include/hw/i386/pc.h | 3 +
include/hw/misc/vmgenid.h| 21 ++
18 files changed, 275 insertions(+), 2 deletions(-)
create mode 100644 hw/misc/vmgenid.c
create mode 100644 include/hw/misc/vmgenid.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 51913d6..d4597c6 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -683,3 +685,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index ea991a3..12a9387 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -307,3 +307,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 481a16c..41b6eb6 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -574,6 +574,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -611,6 +618,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-plug = piix4_device_plug_cb;
hc-unplug_request = piix4_device_unplug_request_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a4d0c0c..f20a6a5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -257,6 +257,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1068,6 +1069,8 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t vm_gid_physical_address;
+uint32_t vm_gid_offset = 0;
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len
[Qemu-devel] [PATCH V11 3/3] tests: add a unit test for the vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
tests/Makefile | 2 ++
tests/vmgenid-test.c | 48
2 files changed, 50 insertions(+)
create mode 100644 tests/vmgenid-test.c
diff --git a/tests/Makefile b/tests/Makefile
index 16f0e4c..612441a 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -64,6 +64,7 @@ gcov-files-check-qom-interface-y = qom/object.c
check-unit-$(CONFIG_POSIX) += tests/test-vmstate$(EXESUF)
check-unit-y += tests/test-qemu-opts$(EXESUF)
gcov-files-test-qemu-opts-y = qom/test-qemu-opts.c
+check-qtest-i386-y += tests/vmgenid-test$(EXESUF)
check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh
@@ -351,6 +352,7 @@ tests/usb-hcd-xhci-test$(EXESUF): tests/usb-hcd-xhci-test.o
$(libqos-usb-obj-y)
tests/vhost-user-test$(EXESUF): tests/vhost-user-test.o qemu-char.o
qemu-timer.o $(qtest-obj-y)
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o libqemuutil.a
libqemustub.a
+tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o
ifeq ($(CONFIG_POSIX),y)
LIBS += -lutil
diff --git a/tests/vmgenid-test.c b/tests/vmgenid-test.c
new file mode 100644
index 000..d9c3e29
--- /dev/null
+++ b/tests/vmgenid-test.c
@@ -0,0 +1,48 @@
+/*
+ * QTest testcase for VM Generation ID
+ *
+ * Copyright (c) 2014 Red Hat, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include string.h
+#include libqtest.h
+
+static void vmgenid_test(void)
+{
+static const uint8_t expected[16] = {
+0x32, 0x4e, 0x6e, 0xaf, 0xd1, 0xd1, 0x4b, 0xf6,
+0xbf, 0x41, 0xb9, 0xbb, 0x6c, 0x91, 0xfb, 0x87
+};
+uint8_t guid[16];
+uint32_t i;
+
+// Emulate the ACPI _INI method (tells the device where the physical
+// memory was allocated.
+writel(0xfedf, 0x0001f000);
+
+// Skip the ACPI ADDR method and read the GUID directly from memory.
+for (i = 0; i 16; i++) {
+guid[i] = readb(0x0001f000 + i);
+}
+
+g_assert_cmpuint(sizeof(guid), ==, sizeof(expected));
+g_assert(memcmp(guid, expected, sizeof(guid)) == 0);
+}
+
+int main(int argc, char **argv)
+{
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/vmgenid/vmgenid, vmgenid_test);
+
+qtest_start(-global vmgenid.uuid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87);
+ret = g_test_run();
+
+qtest_end();
+
+return ret;
+}
--
2.1.0
[Qemu-devel] [PATCH V11 1/3] docs: vm generation id device's description
Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 38 ++ 1 file changed, 38 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..656d598 --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,38 @@ +VIRTUAL MACHINE GENERATION ID += + +Copyright (C) 2014 Red Hat, Inc. + +This work is licensed under the terms of the GNU GPL, version 2 or later. +See the COPYING file in the top-level directory. + +=== + +The VM generation ID (vmgenid) device is an emulated device which +exposes a 128-bit, cryptographically random, integer value identifier. +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +This is specified on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. + +The device adds a vmgenid.uuid property, which can be modified using +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf0003. The +guest is expected to write the physical address of the GUID's buffer +to that memory resource. This allows the device to modify the GUID if +requested by the management application. Current device's implementation +supports a 32-bit address. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. + +Although not specified in Microsoft's document, it is assumed that the +device is expected to use the little-endian system. -- 2.1.0
[Qemu-devel] [PATCH V10 3/3] tests: add a unit test for the vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
tests/Makefile | 2 ++
tests/vmgenid-test.c | 48
2 files changed, 50 insertions(+)
create mode 100644 tests/vmgenid-test.c
diff --git a/tests/Makefile b/tests/Makefile
index 16f0e4c..612441a 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -64,6 +64,7 @@ gcov-files-check-qom-interface-y = qom/object.c
check-unit-$(CONFIG_POSIX) += tests/test-vmstate$(EXESUF)
check-unit-y += tests/test-qemu-opts$(EXESUF)
gcov-files-test-qemu-opts-y = qom/test-qemu-opts.c
+check-qtest-i386-y += tests/vmgenid-test$(EXESUF)
check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh
@@ -351,6 +352,7 @@ tests/usb-hcd-xhci-test$(EXESUF): tests/usb-hcd-xhci-test.o
$(libqos-usb-obj-y)
tests/vhost-user-test$(EXESUF): tests/vhost-user-test.o qemu-char.o
qemu-timer.o $(qtest-obj-y)
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o libqemuutil.a
libqemustub.a
+tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o
ifeq ($(CONFIG_POSIX),y)
LIBS += -lutil
diff --git a/tests/vmgenid-test.c b/tests/vmgenid-test.c
new file mode 100644
index 000..d9c3e29
--- /dev/null
+++ b/tests/vmgenid-test.c
@@ -0,0 +1,48 @@
+/*
+ * QTest testcase for VM Generation ID
+ *
+ * Copyright (c) 2014 Red Hat, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include string.h
+#include libqtest.h
+
+static void vmgenid_test(void)
+{
+static const uint8_t expected[16] = {
+0x32, 0x4e, 0x6e, 0xaf, 0xd1, 0xd1, 0x4b, 0xf6,
+0xbf, 0x41, 0xb9, 0xbb, 0x6c, 0x91, 0xfb, 0x87
+};
+uint8_t guid[16];
+uint32_t i;
+
+// Emulate the ACPI _INI method (tells the device where the physical
+// memory was allocated.
+writel(0xfedf, 0x0001f000);
+
+// Skip the ACPI ADDR method and read the GUID directly from memory.
+for (i = 0; i 16; i++) {
+guid[i] = readb(0x0001f000 + i);
+}
+
+g_assert_cmpuint(sizeof(guid), ==, sizeof(expected));
+g_assert(memcmp(guid, expected, sizeof(guid)) == 0);
+}
+
+int main(int argc, char **argv)
+{
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/vmgenid/vmgenid, vmgenid_test);
+
+qtest_start(-global vmgenid.uuid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87);
+ret = g_test_run();
+
+qtest_end();
+
+return ret;
+}
--
1.9.3
[Qemu-devel] [PATCH V10 2/3] i386: Add a Virtual Machine Generation ID device
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/core.c | 8 +++
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c | 8 +++
hw/i386/acpi-build.c | 26 ++
hw/i386/acpi-dsdt.dsl| 4 +++-
hw/i386/pc.c | 8 +++
hw/i386/q35-acpi-dsdt.dsl| 5 -
hw/i386/ssdt-misc.dsl| 43
hw/isa/lpc_ich9.c| 1 +
hw/misc/Makefile.objs| 1 +
include/hw/acpi/acpi.h | 2 ++
include/hw/acpi/acpi_dev_interface.h | 4
include/hw/acpi/ich9.h | 2 ++
include/hw/i386/pc.h | 3 +++
16 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 51913d6..d4597c6 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -683,3 +685,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index ea991a3..12a9387 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -307,3 +307,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 481a16c..41b6eb6 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -574,6 +574,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -611,6 +618,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-plug = piix4_device_plug_cb;
hc-unplug_request = piix4_device_unplug_request_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a4d0c0c..f20a6a5 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -257,6 +257,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1068,6 +1069,8 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t vm_gid_physical_address;
+uint32_t vm_gid_offset = 0;
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
@@ -1096,6 +1099,21 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml
[Qemu-devel] [PATCH V10 0/3] Virtual Machine Generation ID
Hi, Resending patches after the release of version 2.2. Please note that this patch set doesn't include the *.hex.generated files and the binary ACPI tables (make check will fail). Thanks, Gal. VX - Fixed typos in docs and a few clarification. V9 - Add a unit test. - Rebased to version 2.2. - Removed hex.generated the binary files from patch. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (3): docs: vm generation id device's description i386: Add a Virtual Machine Generation ID device tests: add a unit test for the vmgenid device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 38 hw/acpi/core.c | 8 ++ hw/acpi/ich9.c | 8 ++ hw/acpi/piix4.c | 8 ++ hw/i386/acpi-build.c | 26 +++ hw/i386/acpi-dsdt.dsl| 4 ++- hw/i386/pc.c | 8 ++ hw/i386/q35-acpi-dsdt.dsl| 5 +++- hw/i386/ssdt-misc.dsl| 43 hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + include/hw/acpi/acpi.h | 2 ++ include/hw/acpi/acpi_dev_interface.h | 4 +++ include/hw/acpi/ich9.h | 2 ++ include/hw/i386/pc.h | 3 +++ tests/Makefile | 2 ++ tests/vmgenid-test.c | 48 19 files changed, 211 insertions(+), 2 deletions(-) create mode 100644 docs/specs/vmgenid.txt create mode 100644 tests/vmgenid-test.c -- 1.9.3
[Qemu-devel] [PATCH V10 1/3] docs: vm generation id device's description
Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 38 ++ 1 file changed, 38 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..656d598 --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,38 @@ +VIRTUAL MACHINE GENERATION ID += + +Copyright (C) 2014 Red Hat, Inc. + +This work is licensed under the terms of the GNU GPL, version 2 or later. +See the COPYING file in the top-level directory. + +=== + +The VM generation ID (vmgenid) device is an emulated device which +exposes a 128-bit, cryptographically random, integer value identifier. +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +This is specified on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. + +The device adds a vmgenid.uuid property, which can be modified using +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf0003. The +guest is expected to write the physical address of the GUID's buffer +to that memory resource. This allows the device to modify the GUID if +requested by the management application. Current device's implementation +supports a 32-bit address. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. + +Although not specified in Microsoft's document, it is assumed that the +device is expected to use the little-endian system. -- 1.9.3
Re: [Qemu-devel] [PATCH V9 1/3] docs: vm generation id device's description
- Original Message - From: Eric Blake ebl...@redhat.com To: Gal Hammer gham...@redhat.com, qemu-devel@nongnu.org Sent: Tuesday, December 9, 2014 7:50:07 PM Subject: Re: [Qemu-devel] [PATCH V9 1/3] docs: vm generation id device's description On 12/09/2014 09:14 AM, Gal Hammer wrote: Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..9a09d11 --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,27 @@ +VIRTUAL MACHINE GENERATION ID Just because we aren't consistent doesn't mean that new files can get away with not listing a license/copyright notice. Check some of the other recent doc additions for ideas on how to do it concisely. Most of the files in the docs/specs doesn't have a legal notice so I missed it. Fixed. += + +The VM generation ID (vmgenid) device is an emulated device which +expose a 128-bit, cryptographically random, integer value identifier. s/expose/exposes/ +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +Specs is on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 s/Specs is/This is specified/ + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. + +The device adds a vmgenid.uuid property, which can be modifed using s/modifed/modified/ Fixed the typos. Thanks. +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf0003. The What endianness is the memory resource? Is 4 bytes sufficient, or should it be 8 bytes because it holds a pointer? Or is the size dependent on the guest hardware? Current implementation allocates the GUID's buffer in a 32-bit address range so the device uses 4 LE bytes. +guest is expected to write the physical address of the GUID's buffer +to that memory resource. This allows the device to modify the GUID if +requested by the management application. What endianness is the GUID buffer? The spec say nothing about it. I assumed it is LE. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org Thanks, Gal.
[Qemu-devel] [PATCH V9 0/3] Virtual Machine Generation ID
Hi, Resending patches after the release of version 2.2. Please note that this patch set doesn't include the *.hex.generated files and the binary ACPI tables (make check will fail). Thanks, Gal. V9 - Add a unit test. - Rebased to version 2.2. - Removed hex.generated the binary files from patch. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (3): docs: vm generation id device's description i386: Add a Virtual Machine Generation ID device tests: add a unit test for the vmgenid device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 27 hw/acpi/core.c | 8 ++ hw/acpi/ich9.c | 8 ++ hw/acpi/piix4.c | 8 ++ hw/i386/acpi-build.c | 26 +++ hw/i386/acpi-dsdt.dsl| 4 ++- hw/i386/pc.c | 8 ++ hw/i386/q35-acpi-dsdt.dsl| 5 +++- hw/i386/ssdt-misc.dsl| 43 hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + include/hw/acpi/acpi.h | 2 ++ include/hw/acpi/acpi_dev_interface.h | 4 +++ include/hw/acpi/ich9.h | 2 ++ include/hw/i386/pc.h | 3 +++ tests/Makefile | 2 ++ tests/vmgenid-test.c | 48 19 files changed, 200 insertions(+), 2 deletions(-) create mode 100644 docs/specs/vmgenid.txt create mode 100644 tests/vmgenid-test.c -- 1.9.3
[Qemu-devel] [PATCH V9 2/3] i386: Add a Virtual Machine Generation ID device
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/core.c | 8 +++
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c | 8 +++
hw/i386/acpi-build.c | 26 ++
hw/i386/acpi-dsdt.dsl| 4 +++-
hw/i386/pc.c | 8 +++
hw/i386/q35-acpi-dsdt.dsl| 5 -
hw/i386/ssdt-misc.dsl| 43
hw/isa/lpc_ich9.c| 1 +
hw/misc/Makefile.objs| 1 +
include/hw/acpi/acpi.h | 2 ++
include/hw/acpi/acpi_dev_interface.h | 4
include/hw/acpi/ich9.h | 2 ++
include/hw/i386/pc.h | 3 +++
16 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 51913d6..d4597c6 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -683,3 +685,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index ea991a3..12a9387 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -307,3 +307,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 481a16c..41b6eb6 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -574,6 +574,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -611,6 +618,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-plug = piix4_device_plug_cb;
hc-unplug_request = piix4_device_unplug_request_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index b37a397..bb53182 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -251,6 +251,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1062,6 +1063,8 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t vm_gid_physical_address;
+uint32_t vm_gid_offset = 0;
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
@@ -1090,6 +1093,21 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml
[Qemu-devel] [PATCH V9 3/3] tests: add a unit test for the vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
tests/Makefile | 2 ++
tests/vmgenid-test.c | 48
2 files changed, 50 insertions(+)
create mode 100644 tests/vmgenid-test.c
diff --git a/tests/Makefile b/tests/Makefile
index 16f0e4c..612441a 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -64,6 +64,7 @@ gcov-files-check-qom-interface-y = qom/object.c
check-unit-$(CONFIG_POSIX) += tests/test-vmstate$(EXESUF)
check-unit-y += tests/test-qemu-opts$(EXESUF)
gcov-files-test-qemu-opts-y = qom/test-qemu-opts.c
+check-qtest-i386-y += tests/vmgenid-test$(EXESUF)
check-block-$(CONFIG_POSIX) += tests/qemu-iotests-quick.sh
@@ -351,6 +352,7 @@ tests/usb-hcd-xhci-test$(EXESUF): tests/usb-hcd-xhci-test.o
$(libqos-usb-obj-y)
tests/vhost-user-test$(EXESUF): tests/vhost-user-test.o qemu-char.o
qemu-timer.o $(qtest-obj-y)
tests/qemu-iotests/socket_scm_helper$(EXESUF):
tests/qemu-iotests/socket_scm_helper.o
tests/test-qemu-opts$(EXESUF): tests/test-qemu-opts.o libqemuutil.a
libqemustub.a
+tests/vmgenid-test$(EXESUF): tests/vmgenid-test.o
ifeq ($(CONFIG_POSIX),y)
LIBS += -lutil
diff --git a/tests/vmgenid-test.c b/tests/vmgenid-test.c
new file mode 100644
index 000..d9c3e29
--- /dev/null
+++ b/tests/vmgenid-test.c
@@ -0,0 +1,48 @@
+/*
+ * QTest testcase for VM Generation ID
+ *
+ * Copyright (c) 2014 Red Hat, Inc.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include string.h
+#include libqtest.h
+
+static void vmgenid_test(void)
+{
+static const uint8_t expected[16] = {
+0x32, 0x4e, 0x6e, 0xaf, 0xd1, 0xd1, 0x4b, 0xf6,
+0xbf, 0x41, 0xb9, 0xbb, 0x6c, 0x91, 0xfb, 0x87
+};
+uint8_t guid[16];
+uint32_t i;
+
+// Emulate the ACPI _INI method (tells the device where the physical
+// memory was allocated.
+writel(0xfedf, 0x0001f000);
+
+// Skip the ACPI ADDR method and read the GUID directly from memory.
+for (i = 0; i 16; i++) {
+guid[i] = readb(0x0001f000 + i);
+}
+
+g_assert_cmpuint(sizeof(guid), ==, sizeof(expected));
+g_assert(memcmp(guid, expected, sizeof(guid)) == 0);
+}
+
+int main(int argc, char **argv)
+{
+int ret;
+
+g_test_init(argc, argv, NULL);
+qtest_add_func(/vmgenid/vmgenid, vmgenid_test);
+
+qtest_start(-global vmgenid.uuid=324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87);
+ret = g_test_run();
+
+qtest_end();
+
+return ret;
+}
--
1.9.3
[Qemu-devel] [PATCH V9 1/3] docs: vm generation id device's description
Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..9a09d11 --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,27 @@ +VIRTUAL MACHINE GENERATION ID += + +The VM generation ID (vmgenid) device is an emulated device which +expose a 128-bit, cryptographically random, integer value identifier. +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +Specs is on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. + +The device adds a vmgenid.uuid property, which can be modifed using +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf0003. The +guest is expected to write the physical address of the GUID's buffer +to that memory resource. This allows the device to modify the GUID if +requested by the management application. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. -- 1.9.3
Re: [Qemu-devel] [PATCH V8 0/3] Virtual Machine Generation ID
- Original Message - From: Michael S. Tsirkin m...@redhat.com To: Gal Hammer gham...@redhat.com Cc: pbonz...@redhat.com, qemu-devel@nongnu.org Sent: Sunday, November 16, 2014 9:49:37 PM Subject: Re: [Qemu-devel] [PATCH V8 0/3] Virtual Machine Generation ID On Sun, Nov 16, 2014 at 12:15:56PM +0200, Gal Hammer wrote: Hi, The patch grow to three parts now. Although it is still add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first is a short device's description, then the ACPI tables changes and the actual device and the last patch updates the tests' ACPI tables. Your comment are welcomed. Thanks, Gal. Looks good, but how about a unit test? Should be easy: give device a physical address, read back memory to see that it's been written to. I thought it would make sense to add the tests only after the patch is accepted and the device's implementation is final. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (3): docs: vm generation id device's description i386: Add a Virtual Machine Generation ID device tests: update acpi tables after adding the vmgenid device default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 27 hw/acpi/core.c | 8 +++ hw/acpi/ich9.c | 8 +++ hw/acpi/piix4.c | 8 +++ hw/i386/acpi-build.c | 26 +++ hw/i386/acpi-dsdt.dsl| 4 +- hw/i386/acpi-dsdt.hex.generated | 6 +- hw/i386/pc.c | 8 +++ hw/i386/q35-acpi-dsdt.dsl| 5 +- hw/i386/q35-acpi-dsdt.hex.generated | 8 +-- hw/i386/ssdt-misc.dsl| 43 hw/i386/ssdt-misc.hex.generated | 8 +-- hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + hw/misc/vmgenid.c| 131 +++ include/hw/acpi/acpi.h | 2 + include/hw/acpi/acpi_dev_interface.h | 4 ++ include/hw/acpi/ich9.h | 2 + include/hw/i386/pc.h | 3 + include/hw/misc/vmgenid.h| 21 ++ tests/acpi-test-data/pc/DSDT | Bin 2807 - 2820 bytes tests/acpi-test-data/pc/SSDT | Bin 3065 - 3268 bytes tests/acpi-test-data/q35/DSDT| Bin 7397 - 7410 bytes tests/acpi-test-data/q35/SSDT| Bin 1346 - 1549 bytes 26 files changed, 313 insertions(+), 13 deletions(-) create mode 100644 docs/specs/vmgenid.txt create mode 100644 hw/misc/vmgenid.c create mode 100644 include/hw/misc/vmgenid.h -- 1.9.3
[Qemu-devel] [PATCH V8 0/3] Virtual Machine Generation ID
Hi, The patch grow to three parts now. Although it is still add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first is a short device's description, then the ACPI tables changes and the actual device and the last patch updates the tests' ACPI tables. Your comment are welcomed. Thanks, Gal. V8 - Add a device's description file. - GUID is stored in fw cfg file and the guest writes the physical address to the device (reduces vmexits). V7 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V6 - include the pre-compiled ASL file - remove an empty line at end of files. V5 - Move device's description to SSDT table (dynamic). V4 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V3 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (3): docs: vm generation id device's description i386: Add a Virtual Machine Generation ID device tests: update acpi tables after adding the vmgenid device default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/vmgenid.txt | 27 hw/acpi/core.c | 8 +++ hw/acpi/ich9.c | 8 +++ hw/acpi/piix4.c | 8 +++ hw/i386/acpi-build.c | 26 +++ hw/i386/acpi-dsdt.dsl| 4 +- hw/i386/acpi-dsdt.hex.generated | 6 +- hw/i386/pc.c | 8 +++ hw/i386/q35-acpi-dsdt.dsl| 5 +- hw/i386/q35-acpi-dsdt.hex.generated | 8 +-- hw/i386/ssdt-misc.dsl| 43 hw/i386/ssdt-misc.hex.generated | 8 +-- hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + hw/misc/vmgenid.c| 131 +++ include/hw/acpi/acpi.h | 2 + include/hw/acpi/acpi_dev_interface.h | 4 ++ include/hw/acpi/ich9.h | 2 + include/hw/i386/pc.h | 3 + include/hw/misc/vmgenid.h| 21 ++ tests/acpi-test-data/pc/DSDT | Bin 2807 - 2820 bytes tests/acpi-test-data/pc/SSDT | Bin 3065 - 3268 bytes tests/acpi-test-data/q35/DSDT| Bin 7397 - 7410 bytes tests/acpi-test-data/q35/SSDT| Bin 1346 - 1549 bytes 26 files changed, 313 insertions(+), 13 deletions(-) create mode 100644 docs/specs/vmgenid.txt create mode 100644 hw/misc/vmgenid.c create mode 100644 include/hw/misc/vmgenid.h -- 1.9.3
[Qemu-devel] [PATCH 1/3] docs: vm generation id device's description
Signed-off-by: Gal Hammer gham...@redhat.com --- docs/specs/vmgenid.txt | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 docs/specs/vmgenid.txt diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt new file mode 100644 index 000..9a09d11 --- /dev/null +++ b/docs/specs/vmgenid.txt @@ -0,0 +1,27 @@ +VIRTUAL MACHINE GENERATION ID += + +The VM generation ID (vmgenid) device is an emulated device which +expose a 128-bit, cryptographically random, integer value identifier. +This allows management applications (e.g. libvirt) to notify the guest +operating system when the virtual machine is executed with a different +configuration (e.g. snapshot execution or creation from a template). + +Specs is on the web at: http://go.microsoft.com/fwlink/?LinkId=260709 + +--- + +The vmgenid device is a sysbus device with the following ACPI ID: +QEMU0002. + +The device adds a vmgenid.uuid property, which can be modifed using +the -global command line argument or the QMP interface. + +The device uses a fixed memory resource: 0xfedf-0xfedf0003. The +guest is expected to write the physical address of the GUID's buffer +to that memory resource. This allows the device to modify the GUID if +requested by the management application. + +According to the specification, any change to the GUID executes an +ACPI notification. The vmgenid device triggers the GPE._E00 which +executes the ACPI Notify operation. -- 1.9.3
[Qemu-devel] [PATCH 2/3] i386: Add a Virtual Machine Generation ID device
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/core.c | 8 +++
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c | 8 +++
hw/i386/acpi-build.c | 26 +++
hw/i386/acpi-dsdt.dsl| 4 +-
hw/i386/acpi-dsdt.hex.generated | 6 +-
hw/i386/pc.c | 8 +++
hw/i386/q35-acpi-dsdt.dsl| 5 +-
hw/i386/q35-acpi-dsdt.hex.generated | 8 +--
hw/i386/ssdt-misc.dsl| 43
hw/i386/ssdt-misc.hex.generated | 8 +--
hw/isa/lpc_ich9.c| 1 +
hw/misc/Makefile.objs| 1 +
hw/misc/vmgenid.c| 131 +++
include/hw/acpi/acpi.h | 2 +
include/hw/acpi/acpi_dev_interface.h | 4 ++
include/hw/acpi/ich9.h | 2 +
include/hw/i386/pc.h | 3 +
include/hw/misc/vmgenid.h| 21 ++
21 files changed, 286 insertions(+), 13 deletions(-)
create mode 100644 hw/misc/vmgenid.c
create mode 100644 include/hw/misc/vmgenid.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index 51913d6..d4597c6 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -683,3 +685,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index ea991a3..12a9387 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -307,3 +307,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 481a16c..41b6eb6 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -574,6 +574,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -611,6 +618,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-plug = piix4_device_plug_cb;
hc-unplug_request = piix4_device_unplug_request_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 4003b6b..0cfa598 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -250,6 +250,7 @@ static void acpi_get_pci_info(PcPciInfo *info)
#define ACPI_BUILD_TABLE_FILE etc/acpi/tables
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+#define ACPI_BUILD_VMGENID_FILE etc/vm-generation-id
static void
build_header(GArray *linker, GArray *table_data,
@@ -1061,6 +1062,8 @@ build_ssdt(GArray *table_data, GArray *linker,
{
MachineState *machine = MACHINE(qdev_get_machine());
uint32_t nr_mem = machine-ram_slots;
+uint32_t
[Qemu-devel] [PATCH 3/3] tests: update acpi tables after adding the vmgenid device
Signed-off-by: Gal Hammer gham...@redhat.com
---
tests/acpi-test-data/pc/DSDT | Bin 2807 - 2820 bytes
tests/acpi-test-data/pc/SSDT | Bin 3065 - 3268 bytes
tests/acpi-test-data/q35/DSDT | Bin 7397 - 7410 bytes
tests/acpi-test-data/q35/SSDT | Bin 1346 - 1549 bytes
4 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/tests/acpi-test-data/pc/DSDT b/tests/acpi-test-data/pc/DSDT
index
d37ec34454e6f3db5e91b777f94e03be67a5f583..8c86b1e39454f611ee25ababe0ef429956ba7562
100644
GIT binary patch
delta 65
zcmew^+9Jl~66_Mf!p*?I=(mwef=knhFWx=Cl_TE6(}ma3Il$Avz`%?_L^$5nz{AG
UMlU|tDL%~C-IJ?fvK`k0P4aI+5i9m
delta 52
zcmZn`!34m66_N4or{5iv0)Z1ec5}Z@hbeD@VMCrwgy6bAYFTfq@x=2wS|5fdRv0
HZ?2sHWr7Ua
diff --git a/tests/acpi-test-data/pc/SSDT b/tests/acpi-test-data/pc/SSDT
index
eb2d8b698ce6a3a910a05244a3b6cf80bf818fb9..ab75f3f382a16ec4af3a8e73e8ed9cfdab2c4599
100644
GIT binary patch
delta 228
zcmewengThIM^lR2oD1TW6(yfNXB|Eo|yPxr}*e5N1iZWcTbLZ4^J1~Kv;T0|Nsi
z299`VAUDi6-aR!h-Z{TCuOzhyDCpwihani|?%0LmVqI!9O6#odL+c|Bs6$x{({i
zWe)IbW{Ku7ZfZg$ij2~v6gAB#7Ts$x1kN5QRWGDcc0a7R;5g#1l2;nCzV4Ix4
su!LbD%Mvbr5gA7pmmrP;Att5-uDKk28IHLjs!-AB?+687^iaq0EU}9OaK4?
delta 24
fcmXi`BR)LIM^lRCpQBFWA{d`NXE^2Ow+gkWu^yS
diff --git a/tests/acpi-test-data/q35/DSDT b/tests/acpi-test-data/q35/DSDT
index
2d2bc4adaf54666fe7864e7f39203411b7c308f7..b45f6065ad6140bd987550cc22ff38b09243188f
100644
GIT binary patch
delta 65
zcmaEA`N@*YCDk8lMDj`JFB^mNJ_DT=DJ!t{m|mo-VwOHhV1_ovfBEsm1_lgm
UF?#XAPVrB?w(u?ljCLD0C3V0KL7v#
delta 52
zcmexl`P7ojCDk8sSE=Hqv%F1OBop_u6XwVSB`iOPZwTC=KxOw0|PS#5w_A0|SQ1
HIWlbke7y}n
diff --git a/tests/acpi-test-data/q35/SSDT b/tests/acpi-test-data/q35/SSDT
index
778b79bf428b5d7602b7b80c9434e38c79718bb2..dffee695109a7d97e1d15994aae4207f47639389
100644
GIT binary patch
delta 228
zcmX@a)yu;b9PARp%f`UKD7uj=lCj4Cni4FDL%T%ktfX8-IF8U!_$Q~(A788z`($W
zfg|1-$PM$2cTdfWcg`=(D@iQ^3c9%XVF-q~dphzk06}zve?X8s1CV|H9~VnBR7c4
z9N-b@r~ouBC|FRCi?59nr1Jhh7H=R`$socX@9F2sPyjLmq)d6J~+e?!cSPhHaUS|
r3By8`C0zUGL9}TK^z4_OiT%2)g1{83V4w35*O5;i9K41m_Ir2LU
delta 24
fcmeCImEk9PAR}#LB?H=(mw8l5w*h(|u+DOr!=L
--
1.9.3
[Qemu-devel] [PATCH V6 0/2] Virtual Machine Generation ID
Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one is the ACPI tables changes and the actual device and the second patch updates the tests' ACPI tables. Your comment are welcomed. Thanks, Gal. V6 - Move the device's description back to the static SSDT table. - The GUID is store in a hard coded physical address and not in the ACPI table itself. - ACPI notification is triggered when the GUID is changed. V5 - include the pre-compiled ASL file - remove an empty line at end of files. V4 - Move device's description to SSDT table (dynamic). V3 - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V2 - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (2): i386: Add a Virtual Machine Generation ID device tests: update acpi tables after adding the vmgenid device default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/acpi/core.c | 8 +++ hw/acpi/ich9.c | 8 +++ hw/acpi/piix4.c | 8 +++ hw/i386/acpi-build.c | 8 +++ hw/i386/acpi-dsdt.dsl| 4 +- hw/i386/acpi-dsdt.hex.generated | 6 +- hw/i386/pc.c | 8 +++ hw/i386/q35-acpi-dsdt.dsl| 5 +- hw/i386/q35-acpi-dsdt.hex.generated | 8 +-- hw/i386/ssdt-misc.dsl| 36 +++ hw/i386/ssdt-misc.hex.generated | 8 +-- hw/isa/lpc_ich9.c| 1 + hw/misc/Makefile.objs| 1 + hw/misc/vmgenid.c| 116 +++ include/hw/acpi/acpi.h | 2 + include/hw/acpi/acpi_dev_interface.h | 4 ++ include/hw/acpi/ich9.h | 2 + include/hw/i386/pc.h | 3 + include/hw/misc/vmgenid.h| 21 +++ tests/acpi-test-data/pc/DSDT | Bin 2807 - 2820 bytes tests/acpi-test-data/pc/SSDT | Bin 3065 - 3239 bytes tests/acpi-test-data/q35/DSDT| Bin 7397 - 7410 bytes tests/acpi-test-data/q35/SSDT| Bin 1346 - 1520 bytes 25 files changed, 246 insertions(+), 13 deletions(-) create mode 100644 hw/misc/vmgenid.c create mode 100644 include/hw/misc/vmgenid.h -- 1.9.3
[Qemu-devel] [PATCH 1/2] i386: Add a Virtual Machine Generation ID device
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/core.c | 8 +++
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c | 8 +++
hw/i386/acpi-build.c | 8 +++
hw/i386/acpi-dsdt.dsl| 4 +-
hw/i386/acpi-dsdt.hex.generated | 6 +-
hw/i386/pc.c | 8 +++
hw/i386/q35-acpi-dsdt.dsl| 5 +-
hw/i386/q35-acpi-dsdt.hex.generated | 8 +--
hw/i386/ssdt-misc.dsl| 36 +++
hw/i386/ssdt-misc.hex.generated | 8 +--
hw/isa/lpc_ich9.c| 1 +
hw/misc/Makefile.objs| 1 +
hw/misc/vmgenid.c| 116 +++
include/hw/acpi/acpi.h | 2 +
include/hw/acpi/acpi_dev_interface.h | 4 ++
include/hw/acpi/ich9.h | 2 +
include/hw/i386/pc.h | 3 +
include/hw/misc/vmgenid.h| 21 +++
21 files changed, 246 insertions(+), 13 deletions(-)
create mode 100644 hw/misc/vmgenid.c
create mode 100644 include/hw/misc/vmgenid.h
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index a7368fb..a01c980 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -680,3 +682,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 7b14bbb..5501c0e 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -316,3 +316,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 0bfa814..ad0ef68 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -580,6 +580,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -617,6 +624,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-plug = piix4_device_plug_cb;
hc-unplug_request = piix4_device_unplug_request_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 00be4bb..27d0494 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -42,6 +42,7 @@
#include hw/acpi/memory_hotplug.h
#include sysemu/tpm.h
#include hw/acpi/tpm.h
+#include hw/misc/vmgenid.h
/* Supported chipsets: */
#include hw/acpi/piix4.h
@@ -96,6 +97,7 @@ typedef struct AcpiMiscInfo {
const unsigned char *dsdt_code;
unsigned dsdt_size;
uint16_t pvpanic_port;
+bool vm_generation_id_set;
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -216,6 +218,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-has_hpet = hpet_find
[Qemu-devel] [PATCH 2/2] tests: update acpi tables after adding the vmgenid device
---
tests/acpi-test-data/pc/DSDT | Bin 2807 - 2820 bytes
tests/acpi-test-data/pc/SSDT | Bin 3065 - 3239 bytes
tests/acpi-test-data/q35/DSDT | Bin 7397 - 7410 bytes
tests/acpi-test-data/q35/SSDT | Bin 1346 - 1520 bytes
4 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/tests/acpi-test-data/pc/DSDT b/tests/acpi-test-data/pc/DSDT
index
d37ec34454e6f3db5e91b777f94e03be67a5f583..8c86b1e39454f611ee25ababe0ef429956ba7562
100644
GIT binary patch
delta 65
zcmew^+9Jl~66_Mf!p*?I=(mwef=knhFWx=Cl_TE6(}ma3Il$Avz`%?_L^$5nz{AG
UMlU|tDL%~C-IJ?fvK`k0P4aI+5i9m
delta 52
zcmZn`!34m66_N4or{5iv0)Z1ec5}Z@hbeD@VMCrwgy6bAYFTfq@x=2wS|5fdRv0
HZ?2sHWr7Ua
diff --git a/tests/acpi-test-data/pc/SSDT b/tests/acpi-test-data/pc/SSDT
index
eb2d8b698ce6a3a910a05244a3b6cf80bf818fb9..1f72e5736d825ffbf0bc5d55360f4bfe27cc198b
100644
GIT binary patch
delta 199
zcmewzFd+kIM^j*ISH^BhyB%NXB|!u9)~r}*e57p^d0cTbLZ4^J1~Kv;T0|Nsi
z299`VAUDi6-aR!h-Z{TCuOzhyDCpwihani|?%0LmVqI0myV=0J87@;}QUx5ELvZ
z$ij36i}3PXI_(GKfgT2ZuN^6zGApB`jc@oWQVzVIj*BE`AXiM;DhMjshVjri22J
WY)1kELjgla0wcqcgw08e)42erhcprZ
delta 24
fcmZ23`BR)LIM^lRCpQBFWA{d`NXE^AOw+gkVtNN8
diff --git a/tests/acpi-test-data/q35/DSDT b/tests/acpi-test-data/q35/DSDT
index
2d2bc4adaf54666fe7864e7f39203411b7c308f7..b45f6065ad6140bd987550cc22ff38b09243188f
100644
GIT binary patch
delta 65
zcmaEA`N@*YCDk8lMDj`JFB^mNJ_DT=DJ!t{m|mo-VwOHhV1_ovfBEsm1_lgm
UF?#XAPVrB?w(u?ljCLD0C3V0KL7v#
delta 52
zcmexl`P7ojCDk8sSE=Hqv%F1OBop_u6XwVSB`iOPZwTC=KxOw0|PS#5w_A0|SQ1
HIWlbke7y}n
diff --git a/tests/acpi-test-data/q35/SSDT b/tests/acpi-test-data/q35/SSDT
index
778b79bf428b5d7602b7b80c9434e38c79718bb2..5ca654bd91354a7ff023b0a380015612d53f5dd6
100644
GIT binary patch
delta 199
zcmX@a^?{o!IM^lR11kdqFSogkN}eTru%PVv!AE?i;0?w%a+9-c0|fv!x1_lO3
z3@*!KyH|CynAY1ymNkOUP)ZP|(H24?{4_-P4hW0SKZSfJ_$#Ap8D5E-qkLBWE8
zTzqYuAj$jx1b}2EgNQ_YaEK#AfgVU(!UDF*2@FdZ7P2hi;un!|ba4sdC=g;|N+xy
Wb|f$`6fkroFfuGj*qp@pfEfT^ZZ%N=
delta 24
fcmeyseTa)IIM^k`iIstY(QhMHB;#g5ru)nQRbd8W
--
1.9.3
Re: [Qemu-devel] [PATCH 1/2] i386: Add a Virtual Machine Generation ID device
On 19/10/2014 18:14, Michael S. Tsirkin wrote:
On Sun, Oct 19, 2014 at 04:43:07PM +0300, Gal Hammer wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table and its implementation.
The GUID is set using a global vmgenid.uuid parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/acpi/core.c | 8 +++
hw/acpi/ich9.c | 8 +++
hw/acpi/piix4.c | 8 +++
hw/i386/acpi-build.c | 8 +++
hw/i386/acpi-dsdt.dsl| 4 +-
hw/i386/acpi-dsdt.hex.generated | 6 +-
hw/i386/pc.c | 8 +++
hw/i386/q35-acpi-dsdt.dsl| 5 +-
hw/i386/q35-acpi-dsdt.hex.generated | 8 +--
hw/i386/ssdt-misc.dsl| 36 +++
hw/i386/ssdt-misc.hex.generated | 8 +--
hw/isa/lpc_ich9.c| 1 +
hw/misc/Makefile.objs| 1 +
hw/misc/vmgenid.c| 116 +++
include/hw/acpi/acpi.h | 2 +
include/hw/acpi/acpi_dev_interface.h | 4 ++
include/hw/acpi/ich9.h | 2 +
include/hw/i386/pc.h | 3 +
include/hw/misc/vmgenid.h| 21 +++
21 files changed, 246 insertions(+), 13 deletions(-)
create mode 100644 hw/misc/vmgenid.c
create mode 100644 include/hw/misc/vmgenid.h
Please document the host/guest API.
It seems that you are using a hard-coded hardware address,
and using up a GPE.
I'll add a document file which describes the device's implementation.
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/acpi/core.c b/hw/acpi/core.c
index a7368fb..a01c980 100644
--- a/hw/acpi/core.c
+++ b/hw/acpi/core.c
@@ -28,6 +28,8 @@
#include qapi-visit.h
#include qapi-event.h
+#define ACPI_VM_GENERATION_ID_CHANGED_STATUS 1
+
struct acpi_table_header {
uint16_t _length; /* our length, not actual part of the hdr */
/* allows easier parsing for fw_cfg clients */
@@ -680,3 +682,9 @@ void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
(regs-pm1.evt.en ACPI_BITMASK_TIMER_ENABLE)
!(pm1a_sts ACPI_BITMASK_TIMER_STATUS));
}
+
+void acpi_vm_generation_id_changed(ACPIREGS *acpi_regs, qemu_irq irq)
+{
+acpi_regs-gpe.sts[0] |= ACPI_VM_GENERATION_ID_CHANGED_STATUS;
+acpi_update_sci(acpi_regs, irq);
+}
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 7b14bbb..5501c0e 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -316,3 +316,11 @@ void ich9_pm_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-pm.acpi_memory_hotplug, list);
}
+
+void ich9_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+ICH9LPCState *s = ICH9_LPC_DEVICE(adev);
+ICH9LPCPMRegs *pm = s-pm;
+
+acpi_vm_generation_id_changed(pm-acpi_regs, pm-irq);
+}
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 0bfa814..ad0ef68 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -580,6 +580,13 @@ static void piix4_ospm_status(AcpiDeviceIf *adev,
ACPIOSTInfoList ***list)
acpi_memory_ospm_status(s-acpi_memory_hotplug, list);
}
+static void piix4_vm_generation_id_changed(AcpiDeviceIf *adev)
+{
+PIIX4PMState *s = PIIX4_PM(adev);
+
+acpi_vm_generation_id_changed(s-ar, s-irq);
+}
+
static Property piix4_pm_properties[] = {
DEFINE_PROP_UINT32(smb_io_base, PIIX4PMState, smb_io_base, 0),
DEFINE_PROP_UINT8(ACPI_PM_PROP_S3_DISABLED, PIIX4PMState, disable_s3, 0),
@@ -617,6 +624,7 @@ static void piix4_pm_class_init(ObjectClass *klass, void
*data)
hc-plug = piix4_device_plug_cb;
hc-unplug_request = piix4_device_unplug_request_cb;
adevc-ospm_status = piix4_ospm_status;
+adevc-vm_generation_id_changed = piix4_vm_generation_id_changed;
}
static const TypeInfo piix4_pm_info = {
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 00be4bb..27d0494 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -42,6 +42,7 @@
#include hw/acpi/memory_hotplug.h
#include sysemu/tpm.h
#include hw/acpi/tpm.h
+#include hw/misc/vmgenid.h
/* Supported chipsets: */
#include hw
Re: [Qemu-devel] [PATCH 0/2 V5] Virtual Machine Generation ID
On 01/10/2014 11:58, Markus Armbruster wrote: Did this get stuck? I think so. Did I miss a comment which was not handled in the last version of the patch? Gal. Gal Hammer gham...@redhat.com writes: Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one add a new ACPI directive which allow to use a 16-bytes buffer in an ACPI table. This buffer is for storing the VM's UUID. The second is the ACPI tables changes and the actual device. Your comment are welcomed. Thanks, Gal. V5: - include the pre-compiled ASL file - remove an empty line at end of files. V4: - Move device's description to SSDT table (dynamic build). V3: - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V2: - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device.
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
On 02/10/2014 15:49, Michael S. Tsirkin wrote:
On Wed, Sep 17, 2014 at 02:39:52PM +0300, Gal Hammer wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
Reviewed-By: Igor Mammedov imamm...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/Makefile.objs | 2 +-
hw/i386/acpi-build.c | 39 +++
hw/i386/ssdt-vmgenid.dsl | 63
hw/i386/ssdt-vmgenid.hex.generated | 206 +
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 84 +++
include/hw/i386/pc.h | 3 +
Patch scripts/update-acpi.sh as well please.
I understand what should be changed there. The script just copy all the
*.hex files to *.hex.generated.
9 files changed, 399 insertions(+), 1 deletion(-)
create mode 100644 hw/i386/ssdt-vmgenid.dsl
create mode 100644 hw/i386/ssdt-vmgenid.hex.generated
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 9d419ad..cd1beb3 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,7 +12,7 @@ hw/i386/acpi-build.o: hw/i386/acpi-build.c
hw/i386/acpi-dsdt.hex \
hw/i386/ssdt-proc.hex hw/i386/ssdt-pcihp.hex hw/i386/ssdt-misc.hex \
hw/i386/acpi-dsdt.hex hw/i386/q35-acpi-dsdt.hex \
hw/i386/q35-acpi-dsdt.hex hw/i386/ssdt-mem.hex \
- hw/i386/ssdt-tpm.hex
+ hw/i386/ssdt-tpm.hex hw/i386/ssdt-vmgenid.hex
iasl-option=$(shell if test -z `$(1) $(2) 21 /dev/null` \
; then echo $(2); else echo $(3); fi ;)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a313321..72d5a88 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -96,6 +96,8 @@ typedef struct AcpiMiscInfo {
const unsigned char *dsdt_code;
unsigned dsdt_size;
uint16_t pvpanic_port;
+bool vm_generation_id_set;
+uint8_t vm_generation_id[16];
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -216,6 +218,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-has_hpet = hpet_find();
info-has_tpm = tpm_find();
info-pvpanic_port = pvpanic_port();
+info-vm_generation_id_set = vm_generation_id(info-vm_generation_id);
}
static void acpi_get_pci_info(PcPciInfo *info)
@@ -710,6 +713,7 @@ static inline char acpi_get_hex(uint32_t val)
#include hw/i386/ssdt-misc.hex
#include hw/i386/ssdt-pcihp.hex
#include hw/i386/ssdt-tpm.hex
+#include hw/i386/ssdt-vmgenid.hex
static void
build_append_notify_method(GArray *device, const char *name,
@@ -1246,6 +1250,37 @@ build_tpm_ssdt(GArray *table_data, GArray *linker)
memcpy(tpm_ptr, ssdt_tpm_aml, sizeof(ssdt_tpm_aml));
}
+static void
+build_vmgenid_ssdt(GArray *table_data, GArray *linker, AcpiMiscInfo *info)
+{
+int vgid_start = table_data-len;
+void *vgid_ptr;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
+
+vgid_ptr = acpi_data_push(table_data, sizeof(ssdt_vmgenid_aml));
+memcpy(vgid_ptr, ssdt_vmgenid_aml, sizeof(ssdt_vmgenid_aml));
+
+vm_gid_ptr = acpi_data_get_ptr(vgid_ptr, sizeof(ssdt_vmgenid_aml),
+ *ssdt_acpi_vm_gid,
+ sizeof(info-vm_generation_id));
+memcpy(vm_gid_ptr, info-vm_generation_id,
+ sizeof(info-vm_generation_id));
+
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ vgid_ptr + *ssdt_acpi_vm_gid_addr,
+ sizeof(uint32_t));
+
+vm_gid_physical_address = vgid_start + *ssdt_acpi_vm_gid;
+ACPI_BUILD_SET_LE(vgid_ptr, sizeof(ssdt_vmgenid_aml),
+ *ssdt_acpi_vm_gid_addr, 32, vm_gid_physical_address);
+
+build_header(linker, table_data, vgid_ptr, SSDT,
+ sizeof(ssdt_vmgenid_aml), 1);
+}
+
typedef enum {
MEM_AFFINITY_NOFLAGS = 0,
MEM_AFFINITY_ENABLED = (1 0),
@@ -1617,6 +1652,10 @@ void acpi_build
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Hi Igor,
- Original Message -
From: Igor Mammedov imamm...@redhat.com
To: Gal Hammer gham...@redhat.com
Cc: pbonz...@redhat.com, qemu-devel@nongnu.org
Sent: Tuesday, September 16, 2014 5:54:28 PM
Subject: Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation
ID device.
On Tue, 16 Sep 2014 16:04:10 +0300
Gal Hammer gham...@redhat.com wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/Makefile.objs | 2 +-
hw/i386/acpi-build.c | 39 +
hw/i386/ssdt-vmgenid.dsl | 64
We also need corresponding ssdt-vmgenid.hex file for IASLless hosts,
so that build there won't fail.
Isn't that file is created during the build process?
For example:
$ git blame ./x86_64-softmmu/hw/i386/ssdt-tpm.hex
fatal: no such path 'x86_64-softmmu/hw/i386/ssdt-tpm.hex' in HEAD
With this and below notes fixed
Reviewed-By: Igor Mammedov imamm...@redhat.com
Thanks. Although I do like that empty line at the end of a file :-).
Gal.
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 85
++
include/hw/i386/pc.h | 3 ++
8 files changed, 195 insertions(+), 1 deletion(-)
create mode 100644 hw/i386/ssdt-vmgenid.dsl
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak
b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 9d419ad..cd1beb3 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,7 +12,7 @@ hw/i386/acpi-build.o: hw/i386/acpi-build.c
hw/i386/acpi-dsdt.hex \
hw/i386/ssdt-proc.hex hw/i386/ssdt-pcihp.hex hw/i386/ssdt-misc.hex \
hw/i386/acpi-dsdt.hex hw/i386/q35-acpi-dsdt.hex \
hw/i386/q35-acpi-dsdt.hex hw/i386/ssdt-mem.hex \
- hw/i386/ssdt-tpm.hex
+ hw/i386/ssdt-tpm.hex hw/i386/ssdt-vmgenid.hex
iasl-option=$(shell if test -z `$(1) $(2) 21 /dev/null` \
; then echo $(2); else echo $(3); fi ;)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a313321..72d5a88 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -96,6 +96,8 @@ typedef struct AcpiMiscInfo {
const unsigned char *dsdt_code;
unsigned dsdt_size;
uint16_t pvpanic_port;
+bool vm_generation_id_set;
+uint8_t vm_generation_id[16];
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -216,6 +218,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-has_hpet = hpet_find();
info-has_tpm = tpm_find();
info-pvpanic_port = pvpanic_port();
+info-vm_generation_id_set = vm_generation_id(info-vm_generation_id);
}
static void acpi_get_pci_info(PcPciInfo *info)
@@ -710,6 +713,7 @@ static inline char acpi_get_hex(uint32_t val)
#include hw/i386/ssdt-misc.hex
#include hw/i386/ssdt-pcihp.hex
#include hw/i386/ssdt-tpm.hex
+#include hw/i386/ssdt-vmgenid.hex
static void
build_append_notify_method(GArray *device, const char *name,
@@ -1246,6 +1250,37 @@ build_tpm_ssdt(GArray *table_data, GArray *linker)
memcpy(tpm_ptr, ssdt_tpm_aml, sizeof(ssdt_tpm_aml));
}
+static void
+build_vmgenid_ssdt(GArray *table_data, GArray *linker, AcpiMiscInfo *info)
+{
+int vgid_start = table_data-len;
+void *vgid_ptr;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
+
+vgid_ptr = acpi_data_push(table_data, sizeof(ssdt_vmgenid_aml));
+memcpy(vgid_ptr, ssdt_vmgenid_aml, sizeof(ssdt_vmgenid_aml));
+
+vm_gid_ptr = acpi_data_get_ptr(vgid_ptr, sizeof(ssdt_vmgenid_aml),
+ *ssdt_acpi_vm_gid,
+ sizeof(info-vm_generation_id));
+memcpy(vm_gid_ptr, info-vm_generation_id,
+ sizeof(info-vm_generation_id));
+
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE
[Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.
Add a 16-bytes buffer to allow storing a 128-bit UUID value in an ACPI table. Signed-off-by: Gal Hammer gham...@redhat.com Reviewed-by: Paolo Bonzini pbonz...@redhat.com --- scripts/acpi_extract.py | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py index 22ea468..10c1ffb 100755 --- a/scripts/acpi_extract.py +++ b/scripts/acpi_extract.py @@ -139,13 +139,16 @@ def aml_name_string(offset): offset += 1 return offset; -# Given data offset, find 8 byte buffer offset -def aml_data_buffer8(offset): -#0x08 NameOp NameString DataRef -expect = [0x11, 0x0B, 0x0A, 0x08] +# Given data offset, find variable length byte buffer offset +def aml_data_buffer(offset, length): +#0x11 PkgLength BufferSize ByteList +if (length 63): +die( Name offset 0x%x: expected a one byte PkgLength (length=63) % + (offset)); +expect = [0x11, length+3, 0x0A, length] if (aml[offset:offset+4] != expect): die( Name offset 0x%x: expected %s actual %s % - (offset, aml[offset:offset+4], expect)) + (offset, expect, aml[offset:offset+4])) return offset + len(expect) # Given data offset, find dword const offset @@ -172,9 +175,9 @@ def aml_data_byte_const(offset): (offset, aml[offset])); return offset + 1; -# Find name'd buffer8 -def aml_name_buffer8(offset): -return aml_data_buffer8(aml_name_string(offset) + 4) +# Find name'd buffer +def aml_name_buffer(offset, length): +return aml_data_buffer(aml_name_string(offset) + 4, length) # Given name offset, find dword const offset def aml_name_dword_const(offset): @@ -308,7 +311,9 @@ for i in range(len(asl)): output[array] = aml continue if (directive == ACPI_EXTRACT_NAME_BUFFER8): -offset = aml_name_buffer8(offset) +offset = aml_name_buffer(offset, 8) +elif (directive == ACPI_EXTRACT_NAME_BUFFER16): +offset = aml_name_buffer(offset, 16) elif (directive == ACPI_EXTRACT_NAME_DWORD_CONST): offset = aml_name_dword_const(offset) elif (directive == ACPI_EXTRACT_NAME_WORD_CONST): -- 1.9.3
[Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
Reviewed-By: Igor Mammedov imamm...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/Makefile.objs | 2 +-
hw/i386/acpi-build.c | 39 +++
hw/i386/ssdt-vmgenid.dsl | 63
hw/i386/ssdt-vmgenid.hex.generated | 206 +
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 84 +++
include/hw/i386/pc.h | 3 +
9 files changed, 399 insertions(+), 1 deletion(-)
create mode 100644 hw/i386/ssdt-vmgenid.dsl
create mode 100644 hw/i386/ssdt-vmgenid.hex.generated
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 9d419ad..cd1beb3 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,7 +12,7 @@ hw/i386/acpi-build.o: hw/i386/acpi-build.c
hw/i386/acpi-dsdt.hex \
hw/i386/ssdt-proc.hex hw/i386/ssdt-pcihp.hex hw/i386/ssdt-misc.hex \
hw/i386/acpi-dsdt.hex hw/i386/q35-acpi-dsdt.hex \
hw/i386/q35-acpi-dsdt.hex hw/i386/ssdt-mem.hex \
- hw/i386/ssdt-tpm.hex
+ hw/i386/ssdt-tpm.hex hw/i386/ssdt-vmgenid.hex
iasl-option=$(shell if test -z `$(1) $(2) 21 /dev/null` \
; then echo $(2); else echo $(3); fi ;)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a313321..72d5a88 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -96,6 +96,8 @@ typedef struct AcpiMiscInfo {
const unsigned char *dsdt_code;
unsigned dsdt_size;
uint16_t pvpanic_port;
+bool vm_generation_id_set;
+uint8_t vm_generation_id[16];
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -216,6 +218,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-has_hpet = hpet_find();
info-has_tpm = tpm_find();
info-pvpanic_port = pvpanic_port();
+info-vm_generation_id_set = vm_generation_id(info-vm_generation_id);
}
static void acpi_get_pci_info(PcPciInfo *info)
@@ -710,6 +713,7 @@ static inline char acpi_get_hex(uint32_t val)
#include hw/i386/ssdt-misc.hex
#include hw/i386/ssdt-pcihp.hex
#include hw/i386/ssdt-tpm.hex
+#include hw/i386/ssdt-vmgenid.hex
static void
build_append_notify_method(GArray *device, const char *name,
@@ -1246,6 +1250,37 @@ build_tpm_ssdt(GArray *table_data, GArray *linker)
memcpy(tpm_ptr, ssdt_tpm_aml, sizeof(ssdt_tpm_aml));
}
+static void
+build_vmgenid_ssdt(GArray *table_data, GArray *linker, AcpiMiscInfo *info)
+{
+int vgid_start = table_data-len;
+void *vgid_ptr;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
+
+vgid_ptr = acpi_data_push(table_data, sizeof(ssdt_vmgenid_aml));
+memcpy(vgid_ptr, ssdt_vmgenid_aml, sizeof(ssdt_vmgenid_aml));
+
+vm_gid_ptr = acpi_data_get_ptr(vgid_ptr, sizeof(ssdt_vmgenid_aml),
+ *ssdt_acpi_vm_gid,
+ sizeof(info-vm_generation_id));
+memcpy(vm_gid_ptr, info-vm_generation_id,
+ sizeof(info-vm_generation_id));
+
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ vgid_ptr + *ssdt_acpi_vm_gid_addr,
+ sizeof(uint32_t));
+
+vm_gid_physical_address = vgid_start + *ssdt_acpi_vm_gid;
+ACPI_BUILD_SET_LE(vgid_ptr, sizeof(ssdt_vmgenid_aml),
+ *ssdt_acpi_vm_gid_addr, 32, vm_gid_physical_address);
+
+build_header(linker, table_data, vgid_ptr, SSDT,
+ sizeof(ssdt_vmgenid_aml), 1);
+}
+
typedef enum {
MEM_AFFINITY_NOFLAGS = 0,
MEM_AFFINITY_ENABLED = (1 0),
@@ -1617,6 +1652,10 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables
*tables)
acpi_add_table(table_offsets, tables-table_data);
build_tpm_ssdt(tables-table_data, tables-linker);
}
+if (misc.vm_generation_id_set) {
+acpi_add_table(table_offsets, tables-table_data);
+build_vmgenid_ssdt
[Qemu-devel] [PATCH 0/2 V5] Virtual Machine Generation ID
Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one add a new ACPI directive which allow to use a 16-bytes buffer in an ACPI table. This buffer is for storing the VM's UUID. The second is the ACPI tables changes and the actual device. Your comment are welcomed. Thanks, Gal. V5: - include the pre-compiled ASL file - remove an empty line at end of files. V4: - Move device's description to SSDT table (dynamic build). V3: - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V2: - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (2): i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive. i386: Add a Virtual Machine Generation ID device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/i386/Makefile.objs | 2 +- hw/i386/acpi-build.c | 39 +++ hw/i386/ssdt-vmgenid.dsl | 63 hw/i386/ssdt-vmgenid.hex.generated | 206 + hw/misc/Makefile.objs | 1 + hw/misc/vmgenid.c | 84 +++ include/hw/i386/pc.h | 3 + scripts/acpi_extract.py| 23 +++-- 10 files changed, 413 insertions(+), 10 deletions(-) create mode 100644 hw/i386/ssdt-vmgenid.dsl create mode 100644 hw/i386/ssdt-vmgenid.hex.generated create mode 100644 hw/misc/vmgenid.c -- 1.9.3
[Qemu-devel] [PATCH 0/2 V4] Virtual Machine Generation ID
Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one add a new ACPI directive which allow to use a 16-bytes buffer in an ACPI table. This buffer is for storing the VM's UUID. The second is the ACPI tables changes and the actual device. Your comment are welcomed. Thanks, Gal. V4: - Move device's description to SSDT table (dynamic build). V3: - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V2: - Remove -uuid command line parameter. - Move device's description from SSDT to DSDT table. - Add new vmgenid sysbus device. Gal Hammer (2): i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive. i386: Add a Virtual Machine Generation ID device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/i386/Makefile.objs | 2 +- hw/i386/acpi-build.c | 39 + hw/i386/ssdt-vmgenid.dsl | 64 hw/misc/Makefile.objs | 1 + hw/misc/vmgenid.c | 85 ++ include/hw/i386/pc.h | 3 ++ scripts/acpi_extract.py| 23 +++ 9 files changed, 209 insertions(+), 10 deletions(-) create mode 100644 hw/i386/ssdt-vmgenid.dsl create mode 100644 hw/misc/vmgenid.c -- 1.9.3
[Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.
Add a 16-bytes buffer to allow storing a 128-bit UUID value in an ACPI table. Signed-off-by: Gal Hammer gham...@redhat.com --- scripts/acpi_extract.py | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py index 22ea468..10c1ffb 100755 --- a/scripts/acpi_extract.py +++ b/scripts/acpi_extract.py @@ -139,13 +139,16 @@ def aml_name_string(offset): offset += 1 return offset; -# Given data offset, find 8 byte buffer offset -def aml_data_buffer8(offset): -#0x08 NameOp NameString DataRef -expect = [0x11, 0x0B, 0x0A, 0x08] +# Given data offset, find variable length byte buffer offset +def aml_data_buffer(offset, length): +#0x11 PkgLength BufferSize ByteList +if (length 63): +die( Name offset 0x%x: expected a one byte PkgLength (length=63) % + (offset)); +expect = [0x11, length+3, 0x0A, length] if (aml[offset:offset+4] != expect): die( Name offset 0x%x: expected %s actual %s % - (offset, aml[offset:offset+4], expect)) + (offset, expect, aml[offset:offset+4])) return offset + len(expect) # Given data offset, find dword const offset @@ -172,9 +175,9 @@ def aml_data_byte_const(offset): (offset, aml[offset])); return offset + 1; -# Find name'd buffer8 -def aml_name_buffer8(offset): -return aml_data_buffer8(aml_name_string(offset) + 4) +# Find name'd buffer +def aml_name_buffer(offset, length): +return aml_data_buffer(aml_name_string(offset) + 4, length) # Given name offset, find dword const offset def aml_name_dword_const(offset): @@ -308,7 +311,9 @@ for i in range(len(asl)): output[array] = aml continue if (directive == ACPI_EXTRACT_NAME_BUFFER8): -offset = aml_name_buffer8(offset) +offset = aml_name_buffer(offset, 8) +elif (directive == ACPI_EXTRACT_NAME_BUFFER16): +offset = aml_name_buffer(offset, 16) elif (directive == ACPI_EXTRACT_NAME_DWORD_CONST): offset = aml_name_dword_const(offset) elif (directive == ACPI_EXTRACT_NAME_WORD_CONST): -- 1.9.3
[Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/Makefile.objs | 2 +-
hw/i386/acpi-build.c | 39 +
hw/i386/ssdt-vmgenid.dsl | 64
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 85 ++
include/hw/i386/pc.h | 3 ++
8 files changed, 195 insertions(+), 1 deletion(-)
create mode 100644 hw/i386/ssdt-vmgenid.dsl
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 9d419ad..cd1beb3 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -12,7 +12,7 @@ hw/i386/acpi-build.o: hw/i386/acpi-build.c
hw/i386/acpi-dsdt.hex \
hw/i386/ssdt-proc.hex hw/i386/ssdt-pcihp.hex hw/i386/ssdt-misc.hex \
hw/i386/acpi-dsdt.hex hw/i386/q35-acpi-dsdt.hex \
hw/i386/q35-acpi-dsdt.hex hw/i386/ssdt-mem.hex \
- hw/i386/ssdt-tpm.hex
+ hw/i386/ssdt-tpm.hex hw/i386/ssdt-vmgenid.hex
iasl-option=$(shell if test -z `$(1) $(2) 21 /dev/null` \
; then echo $(2); else echo $(3); fi ;)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a313321..72d5a88 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -96,6 +96,8 @@ typedef struct AcpiMiscInfo {
const unsigned char *dsdt_code;
unsigned dsdt_size;
uint16_t pvpanic_port;
+bool vm_generation_id_set;
+uint8_t vm_generation_id[16];
} AcpiMiscInfo;
typedef struct AcpiBuildPciBusHotplugState {
@@ -216,6 +218,7 @@ static void acpi_get_misc_info(AcpiMiscInfo *info)
info-has_hpet = hpet_find();
info-has_tpm = tpm_find();
info-pvpanic_port = pvpanic_port();
+info-vm_generation_id_set = vm_generation_id(info-vm_generation_id);
}
static void acpi_get_pci_info(PcPciInfo *info)
@@ -710,6 +713,7 @@ static inline char acpi_get_hex(uint32_t val)
#include hw/i386/ssdt-misc.hex
#include hw/i386/ssdt-pcihp.hex
#include hw/i386/ssdt-tpm.hex
+#include hw/i386/ssdt-vmgenid.hex
static void
build_append_notify_method(GArray *device, const char *name,
@@ -1246,6 +1250,37 @@ build_tpm_ssdt(GArray *table_data, GArray *linker)
memcpy(tpm_ptr, ssdt_tpm_aml, sizeof(ssdt_tpm_aml));
}
+static void
+build_vmgenid_ssdt(GArray *table_data, GArray *linker, AcpiMiscInfo *info)
+{
+int vgid_start = table_data-len;
+void *vgid_ptr;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
+
+vgid_ptr = acpi_data_push(table_data, sizeof(ssdt_vmgenid_aml));
+memcpy(vgid_ptr, ssdt_vmgenid_aml, sizeof(ssdt_vmgenid_aml));
+
+vm_gid_ptr = acpi_data_get_ptr(vgid_ptr, sizeof(ssdt_vmgenid_aml),
+ *ssdt_acpi_vm_gid,
+ sizeof(info-vm_generation_id));
+memcpy(vm_gid_ptr, info-vm_generation_id,
+ sizeof(info-vm_generation_id));
+
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ vgid_ptr + *ssdt_acpi_vm_gid_addr,
+ sizeof(uint32_t));
+
+vm_gid_physical_address = vgid_start + *ssdt_acpi_vm_gid;
+ACPI_BUILD_SET_LE(vgid_ptr, sizeof(ssdt_vmgenid_aml),
+ *ssdt_acpi_vm_gid_addr, 32, vm_gid_physical_address);
+
+build_header(linker, table_data, vgid_ptr, SSDT,
+ sizeof(ssdt_vmgenid_aml), 1);
+}
+
typedef enum {
MEM_AFFINITY_NOFLAGS = 0,
MEM_AFFINITY_ENABLED = (1 0),
@@ -1617,6 +1652,10 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables
*tables)
acpi_add_table(table_offsets, tables-table_data);
build_tpm_ssdt(tables-table_data, tables-linker);
}
+if (misc.vm_generation_id_set) {
+acpi_add_table(table_offsets, tables-table_data);
+build_vmgenid_ssdt(tables-table_data, tables-linker, misc);
+}
if (guest_info-numa_nodes) {
acpi_add_table(table_offsets, tables-table_data
[Qemu-devel] [PATCH 0/2 V3] Virtual Machine Generation ID
Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one add a new ACPI directive which allow to use a 16-bytes buffer in an ACPI table. This buffer is for storing the VM's UUID. The second is the ACPI tables changes and the actual device. Your comment are welcomed. Thanks, Gal. V3: - Fix a typo in error message string. - Move device's description from DSDT back to SSDT table. V2: - Remove -uuid command line parameter. - Move device's description from SSDT to DDST table. - Add new vmgenid sysbus device. Gal Hammer (2): i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive. i386: Add a Virtual Machine Generation ID device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/i386/acpi-build.c | 18 hw/i386/ssdt-misc.dsl | 36 hw/misc/Makefile.objs | 1 + hw/misc/vmgenid.c | 85 ++ include/hw/i386/pc.h | 3 ++ scripts/acpi_extract.py| 23 +++ 8 files changed, 159 insertions(+), 9 deletions(-) create mode 100644 hw/misc/vmgenid.c -- 1.9.3
[Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.
Add a 16-bytes buffer to allow storing a 128-bit UUID value in an ACPI table. Signed-off-by: Gal Hammer gham...@redhat.com --- scripts/acpi_extract.py | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py index 22ea468..10c1ffb 100755 --- a/scripts/acpi_extract.py +++ b/scripts/acpi_extract.py @@ -139,13 +139,16 @@ def aml_name_string(offset): offset += 1 return offset; -# Given data offset, find 8 byte buffer offset -def aml_data_buffer8(offset): -#0x08 NameOp NameString DataRef -expect = [0x11, 0x0B, 0x0A, 0x08] +# Given data offset, find variable length byte buffer offset +def aml_data_buffer(offset, length): +#0x11 PkgLength BufferSize ByteList +if (length 63): +die( Name offset 0x%x: expected a one byte PkgLength (length=63) % + (offset)); +expect = [0x11, length+3, 0x0A, length] if (aml[offset:offset+4] != expect): die( Name offset 0x%x: expected %s actual %s % - (offset, aml[offset:offset+4], expect)) + (offset, expect, aml[offset:offset+4])) return offset + len(expect) # Given data offset, find dword const offset @@ -172,9 +175,9 @@ def aml_data_byte_const(offset): (offset, aml[offset])); return offset + 1; -# Find name'd buffer8 -def aml_name_buffer8(offset): -return aml_data_buffer8(aml_name_string(offset) + 4) +# Find name'd buffer +def aml_name_buffer(offset, length): +return aml_data_buffer(aml_name_string(offset) + 4, length) # Given name offset, find dword const offset def aml_name_dword_const(offset): @@ -308,7 +311,9 @@ for i in range(len(asl)): output[array] = aml continue if (directive == ACPI_EXTRACT_NAME_BUFFER8): -offset = aml_name_buffer8(offset) +offset = aml_name_buffer(offset, 8) +elif (directive == ACPI_EXTRACT_NAME_BUFFER16): +offset = aml_name_buffer(offset, 16) elif (directive == ACPI_EXTRACT_NAME_DWORD_CONST): offset = aml_name_dword_const(offset) elif (directive == ACPI_EXTRACT_NAME_WORD_CONST): -- 1.9.3
[Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the DSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/acpi-build.c | 18
hw/i386/ssdt-misc.dsl | 36
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 85 ++
include/hw/i386/pc.h | 3 ++
7 files changed, 145 insertions(+)
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a313321..613ecfc 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1063,6 +1063,8 @@ build_ssdt(GArray *table_data, GArray *linker,
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
int i;
/* The current AML generator can cover the APIC ID range [0..255],
@@ -1088,6 +1090,22 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_isa_pest[0], 16, misc-pvpanic_port);
+vm_gid_ptr = acpi_data_get_ptr(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid[0], 16);
+if (vm_generation_id(vm_gid_ptr)) {
+vm_gid_physical_address = ssdt_start + ssdt_acpi_vm_gid[0];
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ ssdt_ptr + ssdt_acpi_vm_gid_addr[0],
+ sizeof(uint32_t));
+} else {
+vm_gid_physical_address = 0;
+}
+
+ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid_addr[0], 32, vm_gid_physical_address);
+
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_mctrl_nr_slots[0], 32, nr_mem);
diff --git a/hw/i386/ssdt-misc.dsl b/hw/i386/ssdt-misc.dsl
index 0fd4480..630cd35 100644
--- a/hw/i386/ssdt-misc.dsl
+++ b/hw/i386/ssdt-misc.dsl
@@ -118,6 +118,42 @@ DefinitionBlock (ssdt-misc.aml, SSDT, 0x01, BXPC,
BXSSDTSUSP, 0x1)
}
}
+/
+ * Virtual Machine Generation ID Device
+ /
+Scope(\_SB) {
+
+Device(VMGI) {
+Name(_HID, QEMU0002)
+Name(_CID, VM_Gen_Counter)
+Name(_DDN, VM_Gen_Counter)
+
+ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
+Name(VGIA, 0x12345678)
+
+ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
+Name(VGID, Buffer(16) {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+Method(_STA, 0, NotSerialized) {
+Store(VGIA, Local0)
+If (LEqual(Local0, Zero)) {
+Return (0x00)
+} Else {
+Return (0x0F)
+}
+}
+
+Method(ADDR, 0, Serialized) {
+Store(Package(2) { }, Local0)
+Store(VGIA, Index(Local0, 0))
+Store(0x, Index(Local0, 1))
+return (Local0)
+}
+}
+}
+
External(MEMORY_SLOT_NOTIFY_METHOD, MethodObj)
Scope(\_SB.PCI0) {
Device(MEMORY_HOTPLUG_DEVICE) {
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 979e532..c18b800 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -41,3 +41,4 @@ obj-$(CONFIG_SLAVIO) += slavio_misc.o
obj-$(CONFIG_ZYNQ) += zynq_slcr.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-$(CONFIG_VMGENID) += vmgenid.o
diff --git a/hw/misc/vmgenid.c b/hw/misc/vmgenid.c
new file mode 100644
index 000..76956d1
--- /dev/null
+++ b/hw/misc/vmgenid.c
@@ -0,0 +1,85 @@
+/*
+ * Virtual Machine Generation ID Device
+ *
+ * Copyright (C) 2014 Red Hat Inc.
+ *
+ * Authors: Gal Hammer gham...@redhat.com
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Got it. I'll start to work on V4 then...
Gal.
- Original Message -
From: Igor Mammedov imamm...@redhat.com
To: Gal Hammer gham...@redhat.com
Cc: pbonz...@redhat.com, qemu-devel@nongnu.org
Sent: Monday, September 15, 2014 11:46:41 AM
Subject: Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID
device.
On Mon, 15 Sep 2014 10:27:08 +0300
Gal Hammer gham...@redhat.com wrote:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the DSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/acpi-build.c | 18
hw/i386/ssdt-misc.dsl | 36
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 85
++
include/hw/i386/pc.h | 3 ++
7 files changed, 145 insertions(+)
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak
b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a313321..613ecfc 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1063,6 +1063,8 @@ build_ssdt(GArray *table_data, GArray *linker,
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
int i;
/* The current AML generator can cover the APIC ID range [0..255],
@@ -1088,6 +1090,22 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_isa_pest[0], 16, misc-pvpanic_port);
+vm_gid_ptr = acpi_data_get_ptr(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid[0], 16);
+if (vm_generation_id(vm_gid_ptr)) {
+vm_gid_physical_address = ssdt_start + ssdt_acpi_vm_gid[0];
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ ssdt_ptr + ssdt_acpi_vm_gid_addr[0],
+ sizeof(uint32_t));
+} else {
+vm_gid_physical_address = 0;
+}
+
+ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid_addr[0], 32, vm_gid_physical_address);
+
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_mctrl_nr_slots[0], 32, nr_mem);
diff --git a/hw/i386/ssdt-misc.dsl b/hw/i386/ssdt-misc.dsl
index 0fd4480..630cd35 100644
--- a/hw/i386/ssdt-misc.dsl
+++ b/hw/i386/ssdt-misc.dsl
@@ -118,6 +118,42 @@ DefinitionBlock (ssdt-misc.aml, SSDT, 0x01, BXPC,
BXSSDTSUSP, 0x1)
}
}
+/
+ * Virtual Machine Generation ID Device
+ /
+Scope(\_SB) {
+
+Device(VMGI) {
+Name(_HID, QEMU0002)
+Name(_CID, VM_Gen_Counter)
+Name(_DDN, VM_Gen_Counter)
+
+ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
+Name(VGIA, 0x12345678)
+
+ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
+Name(VGID, Buffer(16) {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+Method(_STA, 0, NotSerialized) {
+Store(VGIA, Local0)
+If (LEqual(Local0, Zero)) {
+Return (0x00)
+} Else {
+Return (0x0F)
+}
+}
+
+Method(ADDR, 0, Serialized) {
+Store(Package(2) { }, Local0)
+Store(VGIA, Index(Local0, 0))
+Store(0x, Index(Local0, 1))
+return (Local0)
+}
+}
+}
It's not exactly what Paolo've meant under dynamic inclusion wrt migration
issues.
Sine ssdt-misc is always included in SSDT, so ACPI table size will change
regardless
whether
[Qemu-devel] [PATCH RESEND 0/2 V2] Virtual Machine Generation ID
Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one add a new ACPI directive which allow to use a 16-bytes buffer in an ACPI table. This buffer is for storing the VM's UUID. The second is the ACPI tables changes and the actual device. Your comment are welcomed. Thanks, Gal. V2: - Remove -uuid command line parameter. - Move device's description from SSDT to DDST table. - Add new vmgenid sysbus device. Gal Hammer (2): i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive. i386: Add a Virtual Machine Generation ID device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/i386/acpi-build.c | 23 ++- hw/i386/acpi-dsdt.dsl | 37 + hw/misc/Makefile.objs | 1 + hw/misc/vmgenid.c | 85 ++ include/hw/i386/pc.h | 3 ++ scripts/acpi_extract.py| 23 +++ 8 files changed, 163 insertions(+), 11 deletions(-) create mode 100644 hw/misc/vmgenid.c -- 1.9.3
[Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the DSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/acpi-build.c | 23 ++-
hw/i386/acpi-dsdt.dsl | 37 +
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 85 ++
include/hw/i386/pc.h | 3 ++
7 files changed, 149 insertions(+), 2 deletions(-)
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 85e5834..153dadc 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1390,15 +1390,34 @@ build_mcfg_q35(GArray *table_data, GArray *linker,
AcpiMcfgInfo *info)
static void
build_dsdt(GArray *table_data, GArray *linker, AcpiMiscInfo *misc)
{
-AcpiTableHeader *dsdt;
+int dsdt_start = table_data-len;
+uint8_t *dsdt;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
assert(misc-dsdt_code misc-dsdt_size);
dsdt = acpi_data_push(table_data, misc-dsdt_size);
memcpy(dsdt, misc-dsdt_code, misc-dsdt_size);
+vm_gid_ptr = acpi_data_get_ptr(dsdt, misc-dsdt_size,
+ *dsdt_acpi_vm_gid, 16);
+if (vm_generation_id(vm_gid_ptr)) {
+vm_gid_physical_address = dsdt_start + *dsdt_acpi_vm_gid;
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ dsdt + *dsdt_acpi_vm_gid_addr,
+ sizeof(uint32_t));
+} else {
+vm_gid_physical_address = 0;
+}
+
+ACPI_BUILD_SET_LE(dsdt, misc-dsdt_size,
+ *dsdt_acpi_vm_gid_addr, 32, vm_gid_physical_address);
+
memset(dsdt, 0, sizeof *dsdt);
-build_header(linker, table_data, dsdt, DSDT,
+build_header(linker, table_data, (AcpiTableHeader *)dsdt, DSDT,
misc-dsdt_size, 1);
}
diff --git a/hw/i386/acpi-dsdt.dsl b/hw/i386/acpi-dsdt.dsl
index 559f4b6..9015881 100644
--- a/hw/i386/acpi-dsdt.dsl
+++ b/hw/i386/acpi-dsdt.dsl
@@ -294,6 +294,43 @@ DefinitionBlock (
}
}
+/
+ * Virtual Machine Generation ID Device
+ /
+Scope(\_SB) {
+
+Device(VMGI) {
+Name(_HID, QEMU0002)
+Name(_CID, VM_Gen_Counter)
+Name(_DDN, VM_Gen_Counter)
+
+ACPI_EXTRACT_NAME_DWORD_CONST dsdt_acpi_vm_gid_addr
+Name(VGIA, 0x12345678)
+
+ACPI_EXTRACT_NAME_BUFFER16 dsdt_acpi_vm_gid
+Name(VGID, Buffer(16) {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+Method(_STA, 0, NotSerialized) {
+Store(VGIA, Local0)
+If (LEqual(Local0, Zero)) {
+Return (0x00)
+} Else {
+Return (0x0F)
+}
+}
+
+Method(ADDR, 0, Serialized) {
+Store(Package(2) { }, Local0)
+Store(VGIA, Index(Local0, 0))
+Store(0x, Index(Local0, 1))
+return (Local0)
+}
+}
+}
+
+
#include hw/acpi/pc-hotplug.h
#define CPU_STATUS_BASE PIIX4_CPU_HOTPLUG_IO_BASE
#include acpi-dsdt-cpu-hotplug.dsl
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 979e532..c18b800 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -41,3 +41,4 @@ obj-$(CONFIG_SLAVIO) += slavio_misc.o
obj-$(CONFIG_ZYNQ) += zynq_slcr.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-$(CONFIG_VMGENID) += vmgenid.o
diff --git a/hw/misc/vmgenid.c b/hw/misc/vmgenid.c
new file mode 100644
index 000..76956d1
--- /dev/null
+++ b/hw/misc/vmgenid.c
@@ -0,0 +1,85 @@
+/*
+ * Virtual Machine Generation ID Device
+ *
+ * Copyright (C) 2014 Red Hat Inc.
+ *
+ * Authors: Gal Hammer gham...@redhat.com
+ *
+ * This work
[Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.
Add a 16-bytes buffer to allow storing a 128-bit UUID value in an ACPI table. Signed-off-by: Gal Hammer gham...@redhat.com --- scripts/acpi_extract.py | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py index 22ea468..88314fc 100755 --- a/scripts/acpi_extract.py +++ b/scripts/acpi_extract.py @@ -139,13 +139,16 @@ def aml_name_string(offset): offset += 1 return offset; -# Given data offset, find 8 byte buffer offset -def aml_data_buffer8(offset): -#0x08 NameOp NameString DataRef -expect = [0x11, 0x0B, 0x0A, 0x08] +# Given data offset, find variable length byte buffer offset +def aml_data_buffer(offset, length): +#0x11 PkgLength BufferSize ByteList +if (length 63): +die( Name offset 0x%x: expected an one byte PkgLength (length=63) % + (offset)); +expect = [0x11, length+3, 0x0A, length] if (aml[offset:offset+4] != expect): die( Name offset 0x%x: expected %s actual %s % - (offset, aml[offset:offset+4], expect)) + (offset, expect, aml[offset:offset+4])) return offset + len(expect) # Given data offset, find dword const offset @@ -172,9 +175,9 @@ def aml_data_byte_const(offset): (offset, aml[offset])); return offset + 1; -# Find name'd buffer8 -def aml_name_buffer8(offset): -return aml_data_buffer8(aml_name_string(offset) + 4) +# Find name'd buffer +def aml_name_buffer(offset, length): +return aml_data_buffer(aml_name_string(offset) + 4, length) # Given name offset, find dword const offset def aml_name_dword_const(offset): @@ -308,7 +311,9 @@ for i in range(len(asl)): output[array] = aml continue if (directive == ACPI_EXTRACT_NAME_BUFFER8): -offset = aml_name_buffer8(offset) +offset = aml_name_buffer(offset, 8) +elif (directive == ACPI_EXTRACT_NAME_BUFFER16): +offset = aml_name_buffer(offset, 16) elif (directive == ACPI_EXTRACT_NAME_DWORD_CONST): offset = aml_name_dword_const(offset) elif (directive == ACPI_EXTRACT_NAME_WORD_CONST): -- 1.9.3
[Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.
Add a 16-bytes buffer to allow storing a 128-bit UUID value in an ACPI table. Signed-off-by: Gal Hammer gham...@redhat.com --- scripts/acpi_extract.py | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py index 22ea468..88314fc 100755 --- a/scripts/acpi_extract.py +++ b/scripts/acpi_extract.py @@ -139,13 +139,16 @@ def aml_name_string(offset): offset += 1 return offset; -# Given data offset, find 8 byte buffer offset -def aml_data_buffer8(offset): -#0x08 NameOp NameString DataRef -expect = [0x11, 0x0B, 0x0A, 0x08] +# Given data offset, find variable length byte buffer offset +def aml_data_buffer(offset, length): +#0x11 PkgLength BufferSize ByteList +if (length 63): +die( Name offset 0x%x: expected an one byte PkgLength (length=63) % + (offset)); +expect = [0x11, length+3, 0x0A, length] if (aml[offset:offset+4] != expect): die( Name offset 0x%x: expected %s actual %s % - (offset, aml[offset:offset+4], expect)) + (offset, expect, aml[offset:offset+4])) return offset + len(expect) # Given data offset, find dword const offset @@ -172,9 +175,9 @@ def aml_data_byte_const(offset): (offset, aml[offset])); return offset + 1; -# Find name'd buffer8 -def aml_name_buffer8(offset): -return aml_data_buffer8(aml_name_string(offset) + 4) +# Find name'd buffer +def aml_name_buffer(offset, length): +return aml_data_buffer(aml_name_string(offset) + 4, length) # Given name offset, find dword const offset def aml_name_dword_const(offset): @@ -308,7 +311,9 @@ for i in range(len(asl)): output[array] = aml continue if (directive == ACPI_EXTRACT_NAME_BUFFER8): -offset = aml_name_buffer8(offset) +offset = aml_name_buffer(offset, 8) +elif (directive == ACPI_EXTRACT_NAME_BUFFER16): +offset = aml_name_buffer(offset, 16) elif (directive == ACPI_EXTRACT_NAME_DWORD_CONST): offset = aml_name_dword_const(offset) elif (directive == ACPI_EXTRACT_NAME_WORD_CONST): -- 1.9.3
[Qemu-devel] [PATCH 0/2 V2] Virtual Machine Generation ID
Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one add a new ACPI directive which allow to use a 16-bytes buffer in an ACPI table. This buffer is for storing the VM's UUID. The second is the ACPI tables changes and the actual device. Your comment are welcomed. Thanks, Gal. V2: - Remove -uuid command line parameter. - Move device's description from SSDT to DDST table. - Add new vmgenid sysbus device. Gal Hammer (2): i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive. i386: Add a Virtual Machine Generation ID device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + hw/i386/acpi-build.c | 23 ++- hw/i386/acpi-dsdt.dsl | 37 + hw/misc/Makefile.objs | 1 + hw/misc/vmgenid.c | 85 ++ include/hw/i386/pc.h | 3 ++ scripts/acpi_extract.py| 23 +++ 8 files changed, 163 insertions(+), 11 deletions(-) create mode 100644 hw/misc/vmgenid.c -- 1.9.3
[Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the DSDT ACPI table.
The GUID is set using a new vmgenid device.
Signed-off-by: Gal Hammer gham...@redhat.com
---
default-configs/i386-softmmu.mak | 1 +
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/acpi-build.c | 23 ++-
hw/i386/acpi-dsdt.dsl | 37 +
hw/misc/Makefile.objs | 1 +
hw/misc/vmgenid.c | 85 ++
include/hw/i386/pc.h | 3 ++
7 files changed, 149 insertions(+), 2 deletions(-)
create mode 100644 hw/misc/vmgenid.c
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 8e08841..bd33c75 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 66557ac..006fc7c 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -45,3 +45,4 @@ CONFIG_IOAPIC=y
CONFIG_ICC_BUS=y
CONFIG_PVPANIC=y
CONFIG_MEM_HOTPLUG=y
+CONFIG_VMGENID=y
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 85e5834..153dadc 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1390,15 +1390,34 @@ build_mcfg_q35(GArray *table_data, GArray *linker,
AcpiMcfgInfo *info)
static void
build_dsdt(GArray *table_data, GArray *linker, AcpiMiscInfo *misc)
{
-AcpiTableHeader *dsdt;
+int dsdt_start = table_data-len;
+uint8_t *dsdt;
+uint8_t *vm_gid_ptr;
+uint32_t vm_gid_physical_address;
assert(misc-dsdt_code misc-dsdt_size);
dsdt = acpi_data_push(table_data, misc-dsdt_size);
memcpy(dsdt, misc-dsdt_code, misc-dsdt_size);
+vm_gid_ptr = acpi_data_get_ptr(dsdt, misc-dsdt_size,
+ *dsdt_acpi_vm_gid, 16);
+if (vm_generation_id(vm_gid_ptr)) {
+vm_gid_physical_address = dsdt_start + *dsdt_acpi_vm_gid;
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data,
+ dsdt + *dsdt_acpi_vm_gid_addr,
+ sizeof(uint32_t));
+} else {
+vm_gid_physical_address = 0;
+}
+
+ACPI_BUILD_SET_LE(dsdt, misc-dsdt_size,
+ *dsdt_acpi_vm_gid_addr, 32, vm_gid_physical_address);
+
memset(dsdt, 0, sizeof *dsdt);
-build_header(linker, table_data, dsdt, DSDT,
+build_header(linker, table_data, (AcpiTableHeader *)dsdt, DSDT,
misc-dsdt_size, 1);
}
diff --git a/hw/i386/acpi-dsdt.dsl b/hw/i386/acpi-dsdt.dsl
index 559f4b6..9015881 100644
--- a/hw/i386/acpi-dsdt.dsl
+++ b/hw/i386/acpi-dsdt.dsl
@@ -294,6 +294,43 @@ DefinitionBlock (
}
}
+/
+ * Virtual Machine Generation ID Device
+ /
+Scope(\_SB) {
+
+Device(VMGI) {
+Name(_HID, QEMU0002)
+Name(_CID, VM_Gen_Counter)
+Name(_DDN, VM_Gen_Counter)
+
+ACPI_EXTRACT_NAME_DWORD_CONST dsdt_acpi_vm_gid_addr
+Name(VGIA, 0x12345678)
+
+ACPI_EXTRACT_NAME_BUFFER16 dsdt_acpi_vm_gid
+Name(VGID, Buffer(16) {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+Method(_STA, 0, NotSerialized) {
+Store(VGIA, Local0)
+If (LEqual(Local0, Zero)) {
+Return (0x00)
+} Else {
+Return (0x0F)
+}
+}
+
+Method(ADDR, 0, Serialized) {
+Store(Package(2) { }, Local0)
+Store(VGIA, Index(Local0, 0))
+Store(0x, Index(Local0, 1))
+return (Local0)
+}
+}
+}
+
+
#include hw/acpi/pc-hotplug.h
#define CPU_STATUS_BASE PIIX4_CPU_HOTPLUG_IO_BASE
#include acpi-dsdt-cpu-hotplug.dsl
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 979e532..c18b800 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -41,3 +41,4 @@ obj-$(CONFIG_SLAVIO) += slavio_misc.o
obj-$(CONFIG_ZYNQ) += zynq_slcr.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-$(CONFIG_VMGENID) += vmgenid.o
diff --git a/hw/misc/vmgenid.c b/hw/misc/vmgenid.c
new file mode 100644
index 000..76956d1
--- /dev/null
+++ b/hw/misc/vmgenid.c
@@ -0,0 +1,85 @@
+/*
+ * Virtual Machine Generation ID Device
+ *
+ * Copyright (C) 2014 Red Hat Inc.
+ *
+ * Authors: Gal Hammer gham...@redhat.com
+ *
+ * This work
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
On 01/09/2014 11:57, Paolo Bonzini wrote: Il 01/09/2014 09:20, Gal Hammer ha scritto: We are still in the process of defining which devices/methods go in the DSDT and which go in the SSDT. We had bad experiences with ACPI table migration in 2.1, and one plan to fix them is the following: * the DSDT should always be the same size no matter what command line options are there * the SSDT should have the exact same content (byte-for-byte) for different versions of QEMU, with the same command line options (including the machine type). Right now your code obeys the first rule, not the second rule, so it should add the device to the DSDT. Are you sure about selecting the DSDT? I don't see anyone else is using the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my guest, but ignore it for now ;-)). There is one user: acpi-dsdt-isa.dsl:ACPI_EXTRACT_NAME_BYTE_CONST DSDT_APPLESMC_STA Found it after I've stopped looking only at the acpi-dsdt.dsl file. BTW, which events would cause the ID to change? How should live cloning (or revert to a disk+RAM snapshot) be implemented by layers above QEMU for the VM gen ID to be patched? Can you add something to docs/ about it? The VGID is expected to change when executing a VM with the -snapshot option, when a VM is restored from a backup or when it is imported, copied or cloned. So I would say it is a management's call. Ok, got it. So to support migration (which includes reverting to an earlier disk+RAM snapshot) you just need to ensure the VGID is patched accordingly. Whether VGID _will_ be different or not, that's management's call. I think that the Microsoft's document describes the requirements better than me :-). Also, how does this ID compare to the UUID in the DMI info (-uuid)? The -uuid is not expected to change after the VM was created. Unlike the -vmgenid that is designed to give the guest OS a notification that a change has occurred. Microsoft, as an example, writes that is can be use for a safer cryptographic software. I would say that cloning should change the UUID (and the VMGID). Again, that's a management call as well. One might choose not to change the BIOS UUID when cloning the machine in order to prevent Windows from trying to re-activate itself (or any other licensed software for that matter). Paolo A V2 of the patch was send to the list. Gal.
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
On 17/08/2014 12:49, Paolo Bonzini wrote:
Il 12/08/2014 10:02, Gal Hammer ha scritto:
Hi,
On 10/08/2014 20:22, Paolo Bonzini wrote:
Il 10/08/2014 13:32, Gal Hammer ha scritto:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.
The GUID is set using a new -vmgenid command line parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
hw/i386/acpi-build.c | 23 +++
hw/i386/ssdt-misc.dsl | 33 +
qemu-options.hx | 9 +
vl.c | 11 +++
4 files changed, 76 insertions(+)
Please make this a new device (like pvpanic), instead of adding a new
command-line option.
There is a problem with this request. I don't want to use ISA because it
is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET)
device doesn't effect the command line options.
Did I miss something in SYSBUS and that's was the reason it didn't
appear in the -device ? list?
For a sysbus device, you can override the
cannot_instantiate_with_device_add_yet field of DeviceClass in your
class_init function.
+Scope(\_SB) {
+
+Device(VMGI) {
+Name(_HID, QEMU0002)
+Name(_CID, VM_Gen_Counter)
+Name(_DDN, VM_Gen_Counter)
+
+ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
+Name(VGIA, 0x12345678)
+
+ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
+Name(VGID, Buffer(16) {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+Method(_STA, 0, NotSerialized) {
+Store(VGIA, Local0)
+If (LEqual(Local0, Zero)) {
+Return (0x00)
+} Else {
+Return (0x0F)
+}
+}
+
+Method(ADDR, 0, Serialized) {
+Store(Package(2) { }, Local0)
+Store(VGIA, Index(Local0, 0))
+Store(0x, Index(Local0, 1))
+return (Local0)
+}
+}
+}
+
Please either put this in the DSDT, or omit the Device altogether if you
put it in the SSDT and there is no VMGID device.
I'm not sure I understand this comment. I've put the new device in the
SSDT table (like pvpanic) and add a _STA method which disable the device
if no GUID's address is set (VGIA). The device doesn't show in the
Device Manager if it was not added using the command line.
We are still in the process of defining which devices/methods go in the
DSDT and which go in the SSDT. We had bad experiences with ACPI table
migration in 2.1, and one plan to fix them is the following:
* the DSDT should always be the same size no matter what command line
options are there
* the SSDT should have the exact same content (byte-for-byte) for
different versions of QEMU, with the same command line options
(including the machine type).
Right now your code obeys the first rule, not the second rule, so it
should add the device to the DSDT.
Are you sure about selecting the DSDT? I don't see anyone else is using
the ACPI_EXTRACT_NAME_* macros in the DSDT table (and I keep crashing my
guest, but ignore it for now ;-)).
BTW, which events would cause the ID to change? How should live cloning
(or revert to a disk+RAM snapshot) be implemented by layers above QEMU
for the VM gen ID to be patched? Can you add something to docs/ about it?
The VGID is expected to change when executing a VM with the -snapshot
option, when a VM is restored from a backup or when it is imported,
copied or cloned. So I would say it is a management's call.
I think that the Microsoft's document describes the requirements better
than me :-).
Also, how does this ID compare to the UUID in the DMI info (-uuid)?
The -uuid is not expected to change after the VM was created. Unlike the
-vmgenid that is designed to give the guest OS a notification that a
change has occurred. Microsoft, as an example, writes that is can be use
for a safer cryptographic software.
Paolo
Gal.
Re: [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Hi,
On 10/08/2014 20:22, Paolo Bonzini wrote:
Il 10/08/2014 13:32, Gal Hammer ha scritto:
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.
The GUID is set using a new -vmgenid command line parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
hw/i386/acpi-build.c | 23 +++
hw/i386/ssdt-misc.dsl | 33 +
qemu-options.hx | 9 +
vl.c | 11 +++
4 files changed, 76 insertions(+)
Please make this a new device (like pvpanic), instead of adding a new
command-line option.
There is a problem with this request. I don't want to use ISA because it
is obsolete, PCI is overkill for such a device and a SYSBUS (like HPET)
device doesn't effect the command line options.
Did I miss something in SYSBUS and that's was the reason it didn't
appear in the -device ? list?
+Scope(\_SB) {
+
+Device(VMGI) {
+Name(_HID, QEMU0002)
+Name(_CID, VM_Gen_Counter)
+Name(_DDN, VM_Gen_Counter)
+
+ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
+Name(VGIA, 0x12345678)
+
+ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
+Name(VGID, Buffer(16) {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+Method(_STA, 0, NotSerialized) {
+Store(VGIA, Local0)
+If (LEqual(Local0, Zero)) {
+Return (0x00)
+} Else {
+Return (0x0F)
+}
+}
+
+Method(ADDR, 0, Serialized) {
+Store(Package(2) { }, Local0)
+Store(VGIA, Index(Local0, 0))
+Store(0x, Index(Local0, 1))
+return (Local0)
+}
+}
+}
+
Please either put this in the DSDT, or omit the Device altogether if you
put it in the SSDT and there is no VMGID device.
I'm not sure I understand this comment. I've put the new device in the
SSDT table (like pvpanic) and add a _STA method which disable the device
if no GUID's address is set (VGIA). The device doesn't show in the
Device Manager if it was not added using the command line.
Gal.
Thanks,
Paolo
[Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device.
Based on Microsoft's sepecifications (paper can be dowloaded from
http://go.microsoft.com/fwlink/?LinkId=260709), add a device
description to the SSDT ACPI table.
The GUID is set using a new -vmgenid command line parameter.
Signed-off-by: Gal Hammer gham...@redhat.com
---
hw/i386/acpi-build.c | 23 +++
hw/i386/ssdt-misc.dsl | 33 +
qemu-options.hx | 9 +
vl.c | 11 +++
4 files changed, 76 insertions(+)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 816c6d9..838c72c 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -54,6 +54,9 @@
#include qapi/qmp/qint.h
#include qom/qom-qobject.h
+extern uint8_t vm_generation_id[16];
+extern bool vm_generation_id_set;
+
/* These are used to size the ACPI tables for -M pc-i440fx-1.7 and
* -M pc-i440fx-2.0. Even if the actual amount of AML generated grows
* a little bit, there should be plenty of free space since the DSDT
@@ -1051,6 +1054,7 @@ build_ssdt(GArray *table_data, GArray *linker,
unsigned acpi_cpus = guest_info-apic_id_limit;
int ssdt_start = table_data-len;
uint8_t *ssdt_ptr;
+uint32_t vm_gid_physical_address;
int i;
/* The current AML generator can cover the APIC ID range [0..255],
@@ -1076,6 +1080,25 @@ build_ssdt(GArray *table_data, GArray *linker,
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_isa_pest[0], 16, misc-pvpanic_port);
+if (vm_generation_id_set) {
+uint8_t *vm_gid_ptr;
+
+vm_gid_physical_address = ssdt_start + ssdt_acpi_vm_gid[0];
+vm_gid_ptr = acpi_data_get_ptr(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid[0], 16);
+memcpy(vm_gid_ptr, vm_generation_id, sizeof(vm_generation_id));
+
+bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
+ ACPI_BUILD_TABLE_FILE,
+ table_data, ssdt_ptr +
ssdt_acpi_vm_gid_addr[0],
+ sizeof(uint32_t));
+} else {
+vm_gid_physical_address = 0;
+}
+
+ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
+ ssdt_acpi_vm_gid_addr[0], 32, vm_gid_physical_address);
+
ACPI_BUILD_SET_LE(ssdt_ptr, sizeof(ssdp_misc_aml),
ssdt_mctrl_nr_slots[0], 32, nr_mem);
diff --git a/hw/i386/ssdt-misc.dsl b/hw/i386/ssdt-misc.dsl
index d329b8b..8a001a7 100644
--- a/hw/i386/ssdt-misc.dsl
+++ b/hw/i386/ssdt-misc.dsl
@@ -118,6 +118,39 @@ DefinitionBlock (ssdt-misc.aml, SSDT, 0x01, BXPC,
BXSSDTSUSP, 0x1)
}
}
+Scope(\_SB) {
+
+Device(VMGI) {
+Name(_HID, QEMU0002)
+Name(_CID, VM_Gen_Counter)
+Name(_DDN, VM_Gen_Counter)
+
+ACPI_EXTRACT_NAME_DWORD_CONST ssdt_acpi_vm_gid_addr
+Name(VGIA, 0x12345678)
+
+ACPI_EXTRACT_NAME_BUFFER16 ssdt_acpi_vm_gid
+Name(VGID, Buffer(16) {
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 })
+
+Method(_STA, 0, NotSerialized) {
+Store(VGIA, Local0)
+If (LEqual(Local0, Zero)) {
+Return (0x00)
+} Else {
+Return (0x0F)
+}
+}
+
+Method(ADDR, 0, Serialized) {
+Store(Package(2) { }, Local0)
+Store(VGIA, Index(Local0, 0))
+Store(0x, Index(Local0, 1))
+return (Local0)
+}
+}
+}
+
External(MEMORY_SLOT_NOTIFY_METHOD, MethodObj)
Scope(\_SB.PCI0) {
Device(MEMORY_HOPTLUG_DEVICE) {
diff --git a/qemu-options.hx b/qemu-options.hx
index 96516c1..a6d475c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -369,6 +369,15 @@ STEXI
Set system UUID.
ETEXI
+DEF(vmgenid, HAS_ARG, QEMU_OPTION_vmgenid,
+-vmgenid %08x-%04x-%04x-%04x-%012x\n
+specify the virtual machine generation ID\n,
QEMU_ARCH_I386)
+STEXI
+@item -uuid @var{uuid}
+@findex -uuid
+Set the virtual machine generation ID.
+ETEXI
+
STEXI
@end table
ETEXI
diff --git a/vl.c b/vl.c
index a8029d5..a5ef0d5 100644
--- a/vl.c
+++ b/vl.c
@@ -203,6 +203,9 @@ NodeInfo numa_info[MAX_NODES];
uint8_t qemu_uuid[16];
bool qemu_uuid_set;
+uint8_t vm_generation_id[16];
+bool vm_generation_id_set;
+
static QEMUBootSetHandler *boot_set_handler;
static void *boot_set_opaque;
@@ -3784,6 +3787,14 @@ int main(int argc, char **argv, char **envp)
}
qemu_uuid_set = true;
break;
+ case QEMU_OPTION_vmgenid:
+ if(qemu_uuid_parse(optarg, vm_generation_id) 0) {
+ fprintf(stderr, Fail to parse UUID string.
+Wrong format.\n);
+ exit
[Qemu-devel] [PATCH 0/2] Virtual Machine Generation ID
Hi, A two parts patch to add a QEmu support for Microsoft's Virtual Machine Generation ID device. The first one add a new ACPI directive which allow to use a 16-bytes buffer in an ACPI table. This buffer is for storing the VM's UUID. The second is the ACPI tables changes and the required command line parameter. Your comment are welcomed. Thanks, Gal. Gal Hammer (2): i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive. i386: Add a Virtual Machine Generation ID device. hw/i386/acpi-build.c| 23 +++ hw/i386/ssdt-misc.dsl | 33 + qemu-options.hx | 9 + scripts/acpi_extract.py | 23 ++- vl.c| 11 +++ 5 files changed, 90 insertions(+), 9 deletions(-) -- 1.9.3
[Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive.
Add a 16-bytes buffer to allow storing a 128-bit UUID value in an ACPI table. Signed-off-by: Gal Hammer gham...@redhat.com --- scripts/acpi_extract.py | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/scripts/acpi_extract.py b/scripts/acpi_extract.py index 22ea468..88314fc 100755 --- a/scripts/acpi_extract.py +++ b/scripts/acpi_extract.py @@ -139,13 +139,16 @@ def aml_name_string(offset): offset += 1 return offset; -# Given data offset, find 8 byte buffer offset -def aml_data_buffer8(offset): -#0x08 NameOp NameString DataRef -expect = [0x11, 0x0B, 0x0A, 0x08] +# Given data offset, find variable length byte buffer offset +def aml_data_buffer(offset, length): +#0x11 PkgLength BufferSize ByteList +if (length 63): +die( Name offset 0x%x: expected an one byte PkgLength (length=63) % + (offset)); +expect = [0x11, length+3, 0x0A, length] if (aml[offset:offset+4] != expect): die( Name offset 0x%x: expected %s actual %s % - (offset, aml[offset:offset+4], expect)) + (offset, expect, aml[offset:offset+4])) return offset + len(expect) # Given data offset, find dword const offset @@ -172,9 +175,9 @@ def aml_data_byte_const(offset): (offset, aml[offset])); return offset + 1; -# Find name'd buffer8 -def aml_name_buffer8(offset): -return aml_data_buffer8(aml_name_string(offset) + 4) +# Find name'd buffer +def aml_name_buffer(offset, length): +return aml_data_buffer(aml_name_string(offset) + 4, length) # Given name offset, find dword const offset def aml_name_dword_const(offset): @@ -308,7 +311,9 @@ for i in range(len(asl)): output[array] = aml continue if (directive == ACPI_EXTRACT_NAME_BUFFER8): -offset = aml_name_buffer8(offset) +offset = aml_name_buffer(offset, 8) +elif (directive == ACPI_EXTRACT_NAME_BUFFER16): +offset = aml_name_buffer(offset, 16) elif (directive == ACPI_EXTRACT_NAME_DWORD_CONST): offset = aml_name_dword_const(offset) elif (directive == ACPI_EXTRACT_NAME_WORD_CONST): -- 1.9.3
Re: [Qemu-devel] [PATCH 2/2] qtest: fix a !chr-fd_in_tag assertion error in qtest.
Hi,
After reading the code again. It make sense to leave the call to
remove_fd_in_watch() because I changed the code so the chr_update_read_handler
function is called only when the front end is opened.
Submitting a new version of the patch.
Gal.
- Original Message -
From: Gal Hammer gham...@redhat.com
To: Paolo Bonzini pbonz...@redhat.com, qemu-devel@nongnu.org
Cc: amit shah amit.s...@redhat.com, peter maydell
peter.mayd...@linaro.org, anth...@codemonkey.ws
Sent: Monday, February 24, 2014 1:44:31 PM
Subject: Re: [Qemu-devel] [PATCH 2/2] qtest: fix a !chr-fd_in_tag assertion
error in qtest.
On 24/02/2014 12:32, Paolo Bonzini wrote:
Il 24/02/2014 11:16, Gal Hammer ha scritto:
Replacement of the default chardev handlers now requires a call to
release the current handlers.
Signed-off-by: Gal Hammer gham...@redhat.com
---
monitor.c | 1 +
qtest.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/monitor.c b/monitor.c
index de90fba..db52e7f 100644
--- a/monitor.c
+++ b/monitor.c
@@ -5024,6 +5024,7 @@ void monitor_init(CharDriverState *chr, int flags)
if (monitor_ctrl_mode(mon)) {
mon-mc = g_malloc0(sizeof(MonitorControl));
/* Control mode requires special handlers */
+qemu_chr_add_handlers(chr, NULL, NULL, NULL, NULL);
qemu_chr_add_handlers(chr, monitor_can_read,
monitor_control_read,
monitor_control_event, mon);
qemu_chr_fe_set_echo(chr, true);
diff --git a/qtest.c b/qtest.c
index ae941d6..a5682ee 100644
--- a/qtest.c
+++ b/qtest.c
@@ -519,6 +519,8 @@ void qtest_init(const char *qtest_chrdev, const
char *qtest_log, Error **errp)
return;
}
+/* Replace the default tcp's handlers with qtest's handlers. */
+qemu_chr_add_handlers(chr, NULL, NULL, NULL, NULL);
qemu_chr_add_handlers(chr, qtest_can_read, qtest_read,
qtest_event, chr);
qemu_chr_fe_set_echo(chr, true);
Why can't qemu_chr_add_handlers call remove_fd_in_watch when handlers
are replaced, before setting the new ones?
Paolo
It used to be like that (see patch 1/2 for the change). However, I
removed it after I saw that the function remove_fd_in_watch() is always
called when setting all the handlers to NULL (qemu-char.c +3872) so a
second call in every chr_update_read_handler callback seems redundant.
As far as I can tell only the qtest change the read handlers and not
using the default ones.
Gal.
[Qemu-devel] [PATCH V6] char: restore read callback on a reattached (hotplug) chardev
Fix a bug that was introduced in commit 386a5a1e. A removal of a device
set the chr handlers to NULL. However when the device is plugged back,
its read callback is not restored so data can't be transferred from the
host to the guest (e.g. via the virtio-serial port).
https://bugzilla.redhat.com/show_bug.cgi?id=1027181
Signed-off-by: Gal Hammer gham...@redhat.com
---
qemu-char.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
V6: - replace asserts with remove_fd_in_watch to allow changing
the char device read hanlders.
V5: - remove_fd_in_watch in fd_chr_update_read_handler as well.
- fix pty backend.
V4: - Same as V3, but this time done right.
V3: - fix a typo in comment.
- move the revision history after the signed-off-by tag.
V2: - do not call chr_update_read_handler on device removal.
- add asserts to verify chr_update_read_handler is not called
with an assigned fd_in_tag to prevent fd leaks.
- update fd and udp backends' chr_update_read_handler function
so it won't remove fd_in to prevent a double release.
diff --git a/qemu-char.c b/qemu-char.c
index 4d50838..54ed244 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -213,7 +213,7 @@ void qemu_chr_add_handlers(CharDriverState *s,
s-chr_read = fd_read;
s-chr_event = fd_event;
s-handler_opaque = opaque;
-if (s-chr_update_read_handler)
+if (fe_open s-chr_update_read_handler)
s-chr_update_read_handler(s);
if (!s-explicit_fe_open) {
@@ -1136,13 +1136,14 @@ static void pty_chr_state(CharDriverState *chr, int
connected)
if (!s-connected) {
s-connected = 1;
qemu_chr_be_generic_open(chr);
+}
+if (!chr-fd_in_tag) {
chr-fd_in_tag = io_add_watch_poll(s-fd, pty_chr_read_poll,
pty_chr_read, chr);
}
}
}
-
static void pty_chr_close(struct CharDriverState *chr)
{
PtyCharDriver *s = chr-opaque;
@@ -2509,6 +2510,17 @@ static void tcp_chr_connect(void *opaque)
qemu_chr_be_generic_open(chr);
}
+static void tcp_chr_update_read_handler(CharDriverState *chr)
+{
+TCPCharDriver *s = chr-opaque;
+
+remove_fd_in_watch(chr);
+if (s-chan) {
+chr-fd_in_tag = io_add_watch_poll(s-chan, tcp_chr_read_poll,
+ tcp_chr_read, chr);
+}
+}
+
#define IACSET(x,a,b,c) x[0] = a; x[1] = b; x[2] = c;
static void tcp_chr_telnet_init(int fd)
{
@@ -2664,6 +2676,7 @@ static CharDriverState *qemu_chr_open_socket_fd(int fd,
bool do_nodelay,
chr-get_msgfd = tcp_get_msgfd;
chr-chr_add_client = tcp_chr_add_client;
chr-chr_add_watch = tcp_chr_add_watch;
+chr-chr_update_read_handler = tcp_chr_update_read_handler;
/* be isn't opened until we get a connection */
chr-explicit_be_open = true;
--
1.8.5.3
