Re: [Qemu-devel] [PATCH] qapi-types.py: Fix enum struct sizes on i686
On 08/31/2013 04:36 PM, Cole Robinson wrote:
> Unlike other list types, enum wasn't adding any padding, which caused
> a mismatch between the generated struct size and GenericList struct
> size. More details in a678e26cbe89f7a27cbce794c2c2784571ee9d21
>
> This crashed qemu if calling qmp query-tpm-types for example, which
> upsets libvirt capabilities probing. Reproducer on i686:
>
> (sleep 5; printf
> '{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') |
> ./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
>
> https://bugs.launchpad.net/qemu/+bug/1219207
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Cole Robinson
> ---
> scripts/qapi-types.py | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
Reviewed-by: Eric Blake
> -%(name)s value;
> +union {
> +%(name)s value;
> +uint64_t padding;
> +};
Am I right that anonymous unions are only a C11 feature (not C99)? But
you are just copying and pasting from the other uses in this file, so
it's not a problem.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Fwd: Max7310: confused about the method of reading output port register
Dear Zaborowski:
Firstly,I'm writing to express my thanks to you for the source
code of Max7310 which have helped me so much.
But I'm still confused about the method of reading output port register.
code:
case 0x01: /* Output port */
return s->level & ~s->direction;
break;
I found some instruction of output port register in the datasheet.
" Reads from the output port register reflect the value that is in the flip-flop
controlling the output selection, not the actual I/O value, which may differ if
the out-put is overloaded."
So,in my opinion,in the defination of MAX7310State,whether the property
of outputport_reg should be added?
And does the method of reading/writing output port should be modified as
follows.
[reading]
case 0x01: /* Output port */
return s->outputport_reg;
break;
[writing]
case 0x01: /* Output port */
for (diff = (data ^ s->level) & ~s->direction; diff;
diff &= ~(1 << line)) {
line = ffs(diff) - 1;
if (s->handler[line])
qemu_set_irq(s->handler[line], (data >> line) & 1);
}
s->level = (s->level & s->direction) | (data & ~s->direction);
s->outputport_reg = data;
break;
[Qemu-devel] [PATCH] qapi-types.py: Fix enum struct sizes on i686
Unlike other list types, enum wasn't adding any padding, which caused
a mismatch between the generated struct size and GenericList struct
size. More details in a678e26cbe89f7a27cbce794c2c2784571ee9d21
This crashed qemu if calling qmp query-tpm-types for example, which
upsets libvirt capabilities probing. Reproducer on i686:
(sleep 5; printf
'{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') |
./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
https://bugs.launchpad.net/qemu/+bug/1219207
Cc: qemu-sta...@nongnu.org
Signed-off-by: Cole Robinson
---
scripts/qapi-types.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index 5ee46ea..5d31b06 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -51,7 +51,10 @@ def generate_fwd_enum_struct(name, members):
return mcgen('''
typedef struct %(name)sList
{
-%(name)s value;
+union {
+%(name)s value;
+uint64_t padding;
+};
struct %(name)sList *next;
} %(name)sList;
''',
--
1.8.3.1
Re: [Qemu-devel] [PATCH v2 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init
Am 31.08.2013 19:22, schrieb Antony Pavlov: > Use of SysBusDevice::init is deprecated. > Use Device::realize instead of SysBusDevice::init. > Check dma/pl330.c for an example of the pattern. > > Also introduce TypeInfo::instance_init milkymist_uart_init() > as char/pl011.c does. > > Reported-by: Peter Crosthwaite > Signed-off-by: Antony Pavlov > CC: Peter Crosthwaite > CC: Michael Walle > CC: Andreas Färber > --- > hw/char/milkymist-uart.c | 24 ++-- > 1 file changed, 14 insertions(+), 10 deletions(-) Thanks, applied to qom-next (with shortened commit message): https://github.com/afaerber/qemu-cpu/commits/qom-next Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH v2 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init
Use of SysBusDevice::init is deprecated.
Use Device::realize instead of SysBusDevice::init.
Check dma/pl330.c for an example of the pattern.
Also introduce TypeInfo::instance_init milkymist_uart_init()
as char/pl011.c does.
Reported-by: Peter Crosthwaite
Signed-off-by: Antony Pavlov
CC: Peter Crosthwaite
CC: Michael Walle
CC: Andreas Färber
---
hw/char/milkymist-uart.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
index 6e4bc20..da51f82 100644
--- a/hw/char/milkymist-uart.c
+++ b/hw/char/milkymist-uart.c
@@ -195,22 +195,26 @@ static void milkymist_uart_reset(DeviceState *d)
s->regs[R_STAT] = STAT_THRE;
}
-static int milkymist_uart_init(SysBusDevice *dev)
+static void milkymist_uart_realize(DeviceState *dev, Error **errp)
{
MilkymistUartState *s = MILKYMIST_UART(dev);
-sysbus_init_irq(dev, &s->irq);
-
-memory_region_init_io(&s->regs_region, OBJECT(s), &uart_mmio_ops, s,
- "milkymist-uart", R_MAX * 4);
-sysbus_init_mmio(dev, &s->regs_region);
-
s->chr = qemu_char_get_next_serial();
if (s->chr) {
qemu_chr_add_handlers(s->chr, uart_can_rx, uart_rx, uart_event, s);
}
+}
-return 0;
+static void milkymist_uart_init(Object *obj)
+{
+SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
+MilkymistUartState *s = MILKYMIST_UART(obj);
+
+sysbus_init_irq(sbd, &s->irq);
+
+memory_region_init_io(&s->regs_region, OBJECT(s), &uart_mmio_ops, s,
+ "milkymist-uart", R_MAX * 4);
+sysbus_init_mmio(sbd, &s->regs_region);
}
static const VMStateDescription vmstate_milkymist_uart = {
@@ -227,9 +231,8 @@ static const VMStateDescription vmstate_milkymist_uart = {
static void milkymist_uart_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
-SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
-k->init = milkymist_uart_init;
+dc->realize = milkymist_uart_realize;
dc->reset = milkymist_uart_reset;
dc->vmsd = &vmstate_milkymist_uart;
}
@@ -238,6 +241,7 @@ static const TypeInfo milkymist_uart_info = {
.name = TYPE_MILKYMIST_UART,
.parent= TYPE_SYS_BUS_DEVICE,
.instance_size = sizeof(MilkymistUartState),
+.instance_init = milkymist_uart_init,
.class_init= milkymist_uart_class_init,
};
--
1.8.4.rc3
[Qemu-devel] [PATCH v2 1/2] milkymist-uart: use qemu_chr_fe_write_all() instead of qemu_chr_fe_write()
qemu_chr_fe_write() is capable of returning 0
to indicate EAGAIN (and friends) and we don't
handle this.
Just change it to qemu_chr_fe_write_all() to fix.
Reported-by: Peter Crosthwaite
Signed-off-by: Antony Pavlov
CC: Peter Crosthwaite
CC: Michael Walle
CC: Andreas Färber
---
hw/char/milkymist-uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
index 2e4b5c5..6e4bc20 100644
--- a/hw/char/milkymist-uart.c
+++ b/hw/char/milkymist-uart.c
@@ -124,7 +124,7 @@ static void uart_write(void *opaque, hwaddr addr, uint64_t
value,
switch (addr) {
case R_RXTX:
if (s->chr) {
-qemu_chr_fe_write(s->chr, &ch, 1);
+qemu_chr_fe_write_all(s->chr, &ch, 1);
}
s->regs[R_STAT] |= STAT_TX_EVT;
break;
--
1.8.4.rc3
[Qemu-devel] [PATCH v2 0/2] milkymist-uart fixes
This patch series based on DIGIC support adding comments: http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg04748.html [PATCH v2 1/2] milkymist-uart: use qemu_chr_fe_write_all() instead of qemu_chr_fe_write() [PATCH v2 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init Changes since v1: * remove xml-styled quotes from patch comments; * introduce TypeInfo::instance_init milkymist_uart_init().
[Qemu-devel] [Bug 1219234] [NEW] -device ide-hd will assign bus with with no free units
Public bug reported: Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1000118 ./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device ide-hd,drive=aa -device ide-hd,drive=bb qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus supports only 1 units qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed. qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be initialized If a bus isn't specified for -device ide-hd, it just uses the first bus it finds, not taking into account if that bus was already assigned for another device. So users are forced to do -device ide-hd,bus=ide.0 -device ide-hd,bus=ide.1, etc. This isn't specific to -device ahci, but it's worse there since there isn't any -drive if=IDE or -hda convenience option, which both seem to get the logic correct. I know -device is the 'build it yourself' approach so I understand if this is WONTFIX. This is affects qemu.git as of today (8-31-2013) ** Affects: qemu Importance: Undecided Status: New ** Description changed: Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1000118 ./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device ide-hd,drive=aa -device ide-hd,drive=bb qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus supports only 1 units qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed. qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be initialized If a bus isn't specified for -device ide-hd, it just uses the first bus it finds, not taking into account if that bus was already assigned for another device. So users are forced to do -device ide-hd,bus=ide.0 -device ide-hd,bus=ide.1, etc. This isn't specific to -device ahci, but it's worse there since there isn't any -drive if=IDE or -hda convenience option, which both seem to get the logic correct. I know -device is the 'build it yourself' approach so I understand if this is WONTFIX. + + This is affects qemu.git as of today (8-31-2013) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1219234 Title: -device ide-hd will assign bus with with no free units Status in QEMU: New Bug description: Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1000118 ./x86_64-softmmu/qemu-system-x86_64 -device ahci -drive id=aa,file=/tmp/foo,if=none -drive id=bb,file=/tmp/foo,if=none -device ide-hd,drive=aa -device ide-hd,drive=bb qemu-system-x86_64: -device ide-hd,drive=bb: Can't create IDE unit 1, bus supports only 1 units qemu-system-x86_64: -device ide-hd,drive=bb: Device initialization failed. qemu-system-x86_64: -device ide-hd,drive=bb: Device 'ide-hd' could not be initialized If a bus isn't specified for -device ide-hd, it just uses the first bus it finds, not taking into account if that bus was already assigned for another device. So users are forced to do -device ide-hd,bus=ide.0 -device ide-hd,bus=ide.1, etc. This isn't specific to -device ahci, but it's worse there since there isn't any -drive if=IDE or -hda convenience option, which both seem to get the logic correct. I know -device is the 'build it yourself' approach so I understand if this is WONTFIX. This is affects qemu.git as of today (8-31-2013) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1219234/+subscriptions
[Qemu-devel] How to emulate an i2c device on QEMU x86?
Hi there, Our team want to emulate a multi-touchscreen device controller/device based on x86 arch, and encounter some problems. We have created a virtual multi-touchscreen controller demo, and registered it on i2c bus, but it doesn't seem to work. We register the controller on i2c bus, cause: 1. We found lots of touchscreen drivers on Linux kernel are registered on i2c bus, such as egalax_ts.c driver. 2. We create the multi-touchscreen controller by referring the virtual smbus_eeprom.c device controller/device. But, it seems the virtual multi-touchsreen controller we created isn't probed by guest Linux which running on QEMU, and we have some douts: 1. Creating a multi-touchscreen controller registered on i2c bus, is that ok? 2. If that's ok, how to add an interrupt into the controller, cause the virtual smbus_eeprom.c controller we referring has not any interrupt. 3. When QEMU is star up, we can find the multi-touchscreen controller registered on i2c bus through `info qtree` command, why can't we find the controller on guest Linux `/sys/bus/i2c/devices` derictory? 4. Can the virtual controller probed by guest Linux through generating an interrupt? 5. And is there any source code we can reference? Thanks! -- Honghe
Re: [Qemu-devel] [PATCH 2/2] milkymist-uart: use Device::realize instead of SysBusDevice::init
Am 31.08.2013 07:33, schrieb Antony Pavlov:
> url="http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg04748.html";>
> Use of SysBusDevice::init is deprecated. Please use
> Device::realize instead of SysBusDevice::init.
> Check dma/pl330.c for an example of the pattern.
>
>
> Signed-off-by: Antony Pavlov
> CC: Peter Crosthwaite
> CC: Michael Walle
> ---
> hw/char/milkymist-uart.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
Thanks for looking into this! Some small issues...
Please replace the XML quote above with a proper textual description,
such as "Use of SysBusDevice::init is deprecated, use Device::realize
instead." You can add a line
Reported-by: Peter Crosthwaite
before your Sob to attribute that to him. (Subject is perfect, thanks.)
> diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
> index 6e4bc20..66fba82 100644
> --- a/hw/char/milkymist-uart.c
> +++ b/hw/char/milkymist-uart.c
> @@ -195,22 +195,20 @@ static void milkymist_uart_reset(DeviceState *d)
> s->regs[R_STAT] = STAT_THRE;
> }
>
> -static int milkymist_uart_init(SysBusDevice *dev)
> +static void milkymist_uart_realize(DeviceState *dev, Error **errp)
> {
> MilkymistUartState *s = MILKYMIST_UART(dev);
>
> -sysbus_init_irq(dev, &s->irq);
> +sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
>
> memory_region_init_io(&s->regs_region, OBJECT(s), &uart_mmio_ops, s,
>"milkymist-uart", R_MAX * 4);
> -sysbus_init_mmio(dev, &s->regs_region);
> +sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->regs_region);
Please avoid repeated casts by using a local sbd variable, ordered from
most abstract to concrete. However, since s->irq and R_MAX don't seem to
depend on user-settable properties, please move all of the above -
sysbus_init_irq(), memory_region_init_io() and sysbus_init_mmio() - into
a TypeInfo::instance_init function named milkymist_uart_init(Object
*obj) above or below ..._realize.
Otherwise patch looks good. Please CC me on v2 and I'll queue this one
on the qom-next tree.
Regards,
Andreas
>
> s->chr = qemu_char_get_next_serial();
> if (s->chr) {
> qemu_chr_add_handlers(s->chr, uart_can_rx, uart_rx, uart_event, s);
> }
> -
> -return 0;
> }
>
> static const VMStateDescription vmstate_milkymist_uart = {
> @@ -227,9 +225,8 @@ static const VMStateDescription vmstate_milkymist_uart = {
> static void milkymist_uart_class_init(ObjectClass *klass, void *data)
> {
> DeviceClass *dc = DEVICE_CLASS(klass);
> -SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
>
> -k->init = milkymist_uart_init;
> +dc->realize = milkymist_uart_realize;
> dc->reset = milkymist_uart_reset;
> dc->vmsd = &vmstate_milkymist_uart;
> }
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 1219207] [NEW] QMP (32 bit only) segfaults in query-tpm-types when compiled with --enable-tpm
Public bug reported:
NB: This bug ONLY happens on i686. When qemu is compiled for x86-64,
the bug does NOT happen.
$ ./configure --enable-tpm
$ make
$ (sleep 5; printf
'{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') |
./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 6, "major": 1}, "package":
""}, "capabilities": []}}
{"return": {}}
Segmentation fault (core dumped)
The stack trace is:
#0 output_type_enum (v=0xb9938228, obj=0x5,
strings=0xb77f0320 , kind=0xb767f1d4 "TpmType", name=0x0,
errp=0xbfec4628) at qapi/qapi-visit-core.c:306
#1 0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5,
strings=0xb77f0320 , kind=kind@entry=0xb767f1d4 "TpmType",
name=name@entry=0x0, errp=errp@entry=0xbfec4628)
at qapi/qapi-visit-core.c:114
#2 0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0,
obj=, m=0xb9938228) at qapi-visit.c:5220
#3 visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678,
name=name@entry=0xb76545a6 "unused", errp=errp@entry=0xbfec4674)
at qapi-visit.c:5206
#4 0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674,
ret_out=0xbfec46d8, ret_in=0xb993f490) at qmp-marshal.c:3795
#5 qmp_marshal_input_query_tpm_types (mon=0xb9937098, qdict=0xb99379a0,
ret=0xbfec46d8) at qmp-marshal.c:3817
#6 0xb7581d7a in qmp_call_cmd (cmd=, params=0xb99379a0,
mon=0xb9937098) at /home/rjones/d/qemu/monitor.c:4644
#7 handle_qmp_command (parser=0xb99370ec, tokens=0xb9941438)
at /home/rjones/d/qemu/monitor.c:4710
#8 0xb7631d8f in json_message_process_token (lexer=0xb99370f0,
token=0xb993f3a8, type=JSON_OPERATOR, x=29, y=1)
at qobject/json-streamer.c:87
#9 0xb764579b in json_lexer_feed_char (lexer=lexer@entry=0xb99370f0,
ch=, flush=flush@entry=false) at qobject/json-lexer.c:303
#10 0xb76458c8 in json_lexer_feed (lexer=lexer@entry=0xb99370f0,
buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267
\367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1)
at qobject/json-lexer.c:356
#11 0xb7631fab in json_message_parser_feed (parser=0xb99370ec,
buffer=buffer@entry=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267
\367b\267\315\372\223\271\065\023j\267\002", size=size@entry=1)
at qobject/json-streamer.c:110
#12 0xb75803eb in monitor_control_read (opaque=0xb9937098,
buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267
\367b\267\315\372\223\271\065\023j\267\002", size=1) at
/home/rjones/d/qemu/monitor.c:4731
#13 0xb74b191e in qemu_chr_be_write (len=,
buf=0xbfec486c "}\243\353S\351\364b\267/\327ⵀ\025}\267
\367b\267\315\372\223\271\065\023j\267\002", s=0xb9935800) at qemu-char.c:165
#14 fd_chr_read (chan=0xb9935870, cond=(G_IO_IN | G_IO_HUP), opaque=0xb9935800)
at qemu-char.c:841
#15 0xb71f6876 in g_io_unix_dispatch () from /usr/lib/libglib-2.0.so.0
#16 0xb71b0286 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#17 0xb747a13e in glib_pollfds_poll () at main-loop.c:189
#18 os_host_main_loop_wait (timeout=) at main-loop.c:234
#19 main_loop_wait (nonblocking=1) at main-loop.c:484
#20 0xb7309f11 in main_loop () at vl.c:2090
#21 main (argc=8, argv=0xbfec5c14, envp=0xbfec5c38) at vl.c:4435
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1219207
Title:
QMP (32 bit only) segfaults in query-tpm-types when compiled with
--enable-tpm
Status in QEMU:
New
Bug description:
NB: This bug ONLY happens on i686. When qemu is compiled for x86-64,
the bug does NOT happen.
$ ./configure --enable-tpm
$ make
$ (sleep 5; printf
'{"execute":"qmp_capabilities"}\n{"execute":"query-tpm-types"}\n') |
./i386-softmmu/qemu-system-i386 -S -nodefaults -nographic -M none -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 6, "major": 1},
"package": ""}, "capabilities": []}}
{"return": {}}
Segmentation fault (core dumped)
The stack trace is:
#0 output_type_enum (v=0xb9938228, obj=0x5,
strings=0xb77f0320 , kind=0xb767f1d4 "TpmType", name=0x0,
errp=0xbfec4628) at qapi/qapi-visit-core.c:306
#1 0xb762b3b5 in visit_type_enum (v=v@entry=0xb9938228, obj=0x5,
strings=0xb77f0320 , kind=kind@entry=0xb767f1d4
"TpmType",
name=name@entry=0x0, errp=errp@entry=0xbfec4628)
at qapi/qapi-visit-core.c:114
#2 0xb74a9ef4 in visit_type_TpmType (errp=0xbfec4628, name=0x0,
obj=, m=0xb9938228) at qapi-visit.c:5220
#3 visit_type_TpmTypeList (m=0xb9938228, obj=obj@entry=0xbfec4678,
name=name@entry=0xb76545a6 "unused", errp=errp@entry=0xbfec4674)
at qapi-visit.c:5206
#4 0xb74c403e in qmp_marshal_output_query_tpm_types (errp=0xbfec4674,
ret_out=0xbfec46d8, ret_in=0xb993f490) at qmp-marshal.c:3795
#5 qmp_marshal_input_query_tpm_t
Re: [Qemu-devel] vm performance degradation after kvm live migration or save-restore with EPT enabled
I tested below combos of qemu and kernel,
++-+-+
|kernel | QEMU | migration |
++-+-+
| SLES11SP2+kvm-kmod-3.6 | qemu-1.6.0|GOOD |
++-+-+
| SLES11SP2+kvm-kmod-3.6 | qemu-1.6.0* |BAD |
++-+-+
| SLES11SP2+kvm-kmod-3.6 | qemu-1.5.1|BAD |
++-+-+
| SLES11SP2+kvm-kmod-3.6*| qemu-1.5.1|GOOD |
++-+-+
| SLES11SP2+kvm-kmod-3.6 | qemu-1.5.1* |GOOD |
++-+-+
| SLES11SP2+kvm-kmod-3.6 | qemu-1.5.2|BAD |
++-+-+
| kvm-3.11-2 | qemu-1.5.1|BAD |
++-+-+
NOTE:
1. kvm-3.11-2 : the whole tag kernel downloaded from
https://git.kernel.org/pub/scm/virt/kvm/kvm.git
2. SLES11SP2+kvm-kmod-3.6 : our release kernel, replace the SLES11SP2's default
kvm-kmod with kvm-kmod-3.6, SLES11SP2's kernel version is 3.0.13-0.27
3. qemu-1.6.0* : revert the commit 211ea74022f51164a7729030b28eec90b6c99a08 on
qemu-1.6.0
4. kvm-kmod-3.6* : kvm-kmod-3.6 with EPT disabled
5. qemu-1.5.1* : apply below patch to qemu-1.5.1 to delete qemu_madvise()
statement in ram_load() function
--- qemu-1.5.1/arch_init.c 2013-06-27 05:47:29.0 +0800
+++ qemu-1.5.1_fix3/arch_init.c 2013-08-28 19:43:42.0 +0800
@@ -842,7 +842,6 @@ static int ram_load(QEMUFile *f, void *o
if (ch == 0 &&
(!kvm_enabled() || kvm_has_sync_mmu()) &&
getpagesize() <= TARGET_PAGE_SIZE) {
-qemu_madvise(host, TARGET_PAGE_SIZE, QEMU_MADV_DONTNEED);
}
#endif
} else if (flags & RAM_SAVE_FLAG_PAGE) {
If I apply above patch to qemu-1.5.1 to delete the qemu_madvise() statement,
the test result of the combos of SLES11SP2+kvm-kmod-3.6 and qemu-1.5.1 is good.
Why do we perform the qemu_madvise(QEMU_MADV_DONTNEED) for those zero pages?
Does the qemu_madvise() have sustained effect on the range of virtual address?
In other words, does qemu_madvise() have sustained effect on the VM performance?
If later frequently read/write the range of virtual address which have been
advised to DONTNEED, could performance degradation happen?
The reason why the combos of SLES11SP2+kvm-kmod-3.6 and qemu-1.6.0 is good, is
because of commit 211ea74022f51164a7729030b28eec90b6c99a08,
if I revert the commit 211ea74022f51164a7729030b28eec90b6c99a08 on qemu-1.6.0,
the test result of combos of SLES11SP2+kvm-kmod-3.6 and qemu-1.6.0 is bad,
performance degradation happened, too.
Thanks,
Zhang Haoyu
>> >>> The QEMU command line (/var/log/libvirt/qemu/[domain name].log),
>> >>> LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/
>> >>> QEMU_AUDIO_DRV=none
>> >>> /usr/local/bin/qemu-system-x86_64 -name ATS1 -S -M pc-0.12 -cpu
>> >>> qemu32 -enable-kvm -m 12288 -smp 4,sockets=4,cores=1,threads=1
>> >>> -uuid
>> >>> 0505ec91-382d-800e-2c79-e5b286eb60b5 -no-user-config -nodefaults
>> >>> -chardev
>> >>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/ATS1.monitor,serv
>> >>> er, n owait -mon chardev=charmonitor,id=monitor,mode=control -rtc
>> >>> base=localtime -no-shutdown -device
>> >>> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
>> >>> file=/opt/ne/vm/ATS1.img,if=none,id=drive-virtio-disk0,format=raw,
>> >>> cac
>> >>> h
>> >>> e=none -device
>> >>> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk
>> >>> 0,i
>> >>> d
>> >>> =virtio-disk0,bootindex=1 -netdev
>> >>> tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device
>> >>> virtio-net-pci,netdev=hostnet0,id=net0,mac=00:e0:fc:00:0f:00,bus=pci.
>> >>> 0
>> >>> ,addr=0x3,bootindex=2 -netdev
>> >>> tap,fd=22,id=hostnet1,vhost=on,vhostfd=23 -device
>> >>> virtio-net-pci,netdev=hostnet1,id=net1,mac=00:e0:fc:01:0f:00,bus=pci.
>> >>> 0
>> >>> ,addr=0x4 -netdev tap,fd=24,id=hostnet2,vhost=on,vhostfd=25
>> >>> -device
>> >>> virtio-net-pci,netdev=hostnet2,id=net2,mac=00:e0:fc:02:0f:00,bus=pci.
>> >>> 0
>> >>> ,addr=0x5 -netdev tap,fd=26,id=hostnet3,vhost=on,vhostfd=27
>> >>> -device
>> >>> virtio-net-pci,netdev=hostnet3,id=net3,mac=00:e0:fc:03:0f:00,bus=pci.
>> >>> 0
>> >>> ,addr=0x6 -netdev tap,fd=28,id=hostnet4,vhost=on,vhostfd=29
>> >>> -device
>> >>> virtio-net-pci,netdev=hostnet4,id=net4,mac=00:e0:fc:0a:0f:00,bus=pci.
>> >>> 0
>> >>> ,addr=0x7 -netdev tap,fd=30,id=hostnet5,vhost=on,vhostfd=31
>> >>> -device
>> >>> virtio-net-pci,netdev=hostnet5,id=net5,mac=00:e0:fc:0b:0f:00,bus=pci.
>> >>> 0
>> >>> ,addr=0x9 -chardev pty,id=charserial0 -device
>> >>> isa-serial,chardev=charserial0,id=serial0 -vnc *:0 -k en-us -vga
>> >>> cirrus -device i6300es
Re: [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM
On Thu, Aug 29, 2013 at 8:28 PM, Gary Ching-Pang Lin wrote: > On Fri, Aug 30, 2013 at 02:04:40AM +1000, Bruce Rogers wrote: >> I tried this out, and I get the black screen as well when ept=n, but it boots >> successfully to the efi shell when ept=y. >> >> Gary, what does 'cat /sys/module/kvm_intel/parameters/ept' report on your >> failing machine? >> > I think this is the root cause. My machine doesn't support ept. Gary, Bruce, Can one of you try this OVMF branch to see if it boots when EPT is not enabled? https://github.com/jljusten/edk2.git ovmf-vm-vtf0 Thanks for your time, -Jordan
Re: [Qemu-devel] [edk2] OVMF hung on qemu 1.6.0 with KVM
Il 30/08/2013 21:05, Jordan Justen ha scritto: > I meant your proposed update to VTF0 is not quite what is needed > within EDK II. The current ROM based tables need to stay because that > is what real firmware would need to use to enable a 64-bit PEI. Ok, understood. > OVMF will just have to do something different to work around the KVM > issue. I don't think anything special is needed, we can just document that KVM + a new QEMU requires a new kernel. Paolo > I did some work on this, but ended up going with the simpler > change of r14494 because it appeared to be enough to work around the > issue.
