Re: [Qemu-devel] [PATCH 1/2] Add dd-style SIGUSR1 progress reporting
On 04/27/11 18:14, Markus Armbruster wrote:
>> +static void progress_simple_init(void)
>> +{
>> +state.print = progress_simple_print;
>> +state.end = progress_simple_end;
>> +}
>> +
>> +#ifdef CONFIG_POSIX
>> +static void sigusr_print(int signal)
>> +{
>> +printf("(%3.2f/100%%)\n", state.current);
>
> printf() is not async-signal-safe. I don't think you can safely call it
> in a signal handler.
G, you're absolutely right! Back to the drawing board!
If someone locates my lost marbles, would you mind returning them? I
need them urgently!
Cheers,
Jes
[Qemu-devel] [PULL] char, virtio-serial, spice
Hello, These are assorted fixes to the char code, big endian handling of virtio-serial code and addition of a guest open/close notification for spice to use from virtio-console. (The git mirror might take a while to show up these patches.) The following changes since commit a7d3970d0635ebce1412736e7aaf11d387919dc8: target-arm: Don't update base register on abort in Thumb T1 LDM (2011-04-27 20:14:34 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/virt/qemu/amit/char.git for-anthony Alexey Kardashevskiy (1): virtio-serial: Fix endianness bug in the config space Amit Shah (1): char: Detect chardev release by NULL handlers as well as NULL opaque Hans de Goede (3): chardev: Allow frontends to notify backends of guest open / close virtio-console: notify backend of guest open / close spice-chardev: listen to frontend guest open / close Kusanagi Kouichi (1): char: Allow devices to use a single multiplexed chardev. hw/qdev-properties.c |4 ++-- hw/virtio-console.c| 18 ++ hw/virtio-serial-bus.c | 23 +-- qemu-char.c| 24 ++-- qemu-char.h|6 +- spice-qemu-char.c | 14 ++ 6 files changed, 74 insertions(+), 15 deletions(-) -- 1.7.4.4
[Qemu-devel] [PATCH 3/6] spice-chardev: listen to frontend guest open / close
From: Hans de Goede
Note the vmc_register_interface() in spice_chr_write is left in place
in case someone uses spice-chardev with a frontend which does not have
guest open / close notification.
Signed-off-by: Hans de Goede
Reviewed-by: Alon Levy
Signed-off-by: Amit Shah
---
spice-qemu-char.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 517f337..fa15a71 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -131,6 +131,18 @@ static void spice_chr_close(struct CharDriverState *chr)
qemu_free(s);
}
+static void spice_chr_guest_open(struct CharDriverState *chr)
+{
+SpiceCharDriver *s = chr->opaque;
+vmc_register_interface(s);
+}
+
+static void spice_chr_guest_close(struct CharDriverState *chr)
+{
+SpiceCharDriver *s = chr->opaque;
+vmc_unregister_interface(s);
+}
+
static void print_allowed_subtypes(void)
{
const char** psubtype;
@@ -183,6 +195,8 @@ CharDriverState *qemu_chr_open_spice(QemuOpts *opts)
chr->opaque = s;
chr->chr_write = spice_chr_write;
chr->chr_close = spice_chr_close;
+chr->chr_guest_open = spice_chr_guest_open;
+chr->chr_guest_close = spice_chr_guest_close;
qemu_chr_generic_open(chr);
--
1.7.4.4
[Qemu-devel] [Bug 696530] Re: qemu-0.13.0-r2 special keys different when using -alt-grab
Thank you! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/696530 Title: qemu-0.13.0-r2 special keys different when using -alt-grab Status in QEMU: New Bug description: I use -alt-grab with qemu-0.13.0-r2 and special keys like Ctrl-Alt-f for full screen did not work for me with a windows guest. They work normally when omitting the -alt-grab startup parameter. After quite a long time, I found out that I have to add the shift key to the keys from the documentation when I use the -alt-grab option. Probably -ctrl-grab behaves similarly. It would be really nice to have this documented in the default documentation in the man page as has not been documented there yet.
[Qemu-devel] [PATCH 1/6] chardev: Allow frontends to notify backends of guest open / close
From: Hans de Goede
Some frontends know when the guest has opened the "channel" and is actively
listening to it, for example virtio-serial. This patch adds 2 new qemu-chardev
functions which can be used by frontends to signal guest open / close, and
allows interested backends to listen to this.
Signed-off-by: Hans de Goede
Reviewed-by: Alon Levy
Signed-off-by: Amit Shah
---
qemu-char.c | 17 +
qemu-char.h |4
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 03858d4..710d98f 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -480,6 +480,9 @@ static CharDriverState *qemu_chr_open_mux(CharDriverState
*drv)
chr->chr_write = mux_chr_write;
chr->chr_update_read_handler = mux_chr_update_read_handler;
chr->chr_accept_input = mux_chr_accept_input;
+/* Frontend guest-open / -close notification is not support with muxes */
+chr->chr_guest_open = NULL;
+chr->chr_guest_close = NULL;
/* Muxes are always open on creation */
qemu_chr_generic_open(chr);
@@ -2579,6 +2582,20 @@ void qemu_chr_set_echo(struct CharDriverState *chr, bool
echo)
}
}
+void qemu_chr_guest_open(struct CharDriverState *chr)
+{
+if (chr->chr_guest_open) {
+chr->chr_guest_open(chr);
+}
+}
+
+void qemu_chr_guest_close(struct CharDriverState *chr)
+{
+if (chr->chr_guest_close) {
+chr->chr_guest_close(chr);
+}
+}
+
void qemu_chr_close(CharDriverState *chr)
{
QTAILQ_REMOVE(&chardevs, chr, next);
diff --git a/qemu-char.h b/qemu-char.h
index fb96eef..2f8512e 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -65,6 +65,8 @@ struct CharDriverState {
void (*chr_close)(struct CharDriverState *chr);
void (*chr_accept_input)(struct CharDriverState *chr);
void (*chr_set_echo)(struct CharDriverState *chr, bool echo);
+void (*chr_guest_open)(struct CharDriverState *chr);
+void (*chr_guest_close)(struct CharDriverState *chr);
void *opaque;
QEMUBH *bh;
char *label;
@@ -79,6 +81,8 @@ CharDriverState *qemu_chr_open_opts(QemuOpts *opts,
void (*init)(struct CharDriverState *s));
CharDriverState *qemu_chr_open(const char *label, const char *filename, void
(*init)(struct CharDriverState *s));
void qemu_chr_set_echo(struct CharDriverState *chr, bool echo);
+void qemu_chr_guest_open(struct CharDriverState *chr);
+void qemu_chr_guest_close(struct CharDriverState *chr);
void qemu_chr_close(CharDriverState *chr);
void qemu_chr_printf(CharDriverState *s, const char *fmt, ...)
GCC_FMT_ATTR(2, 3);
--
1.7.4.4
[Qemu-devel] [PATCH 2/6] virtio-console: notify backend of guest open / close
From: Hans de Goede
Signed-off-by: Hans de Goede
Reviewed-by: Alon Levy
Signed-off-by: Amit Shah
---
hw/virtio-console.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index 6b5237b..de539c4 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -28,6 +28,22 @@ static ssize_t flush_buf(VirtIOSerialPort *port, const
uint8_t *buf, size_t len)
return qemu_chr_write(vcon->chr, buf, len);
}
+/* Callback function that's called when the guest opens the port */
+static void guest_open(VirtIOSerialPort *port)
+{
+VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
+
+qemu_chr_guest_open(vcon->chr);
+}
+
+/* Callback function that's called when the guest closes the port */
+static void guest_close(VirtIOSerialPort *port)
+{
+VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
+
+qemu_chr_guest_close(vcon->chr);
+}
+
/* Readiness of the guest to accept data on a port */
static int chr_can_read(void *opaque)
{
@@ -64,6 +80,8 @@ static int generic_port_init(VirtConsole *vcon,
VirtIOSerialPort *port)
qemu_chr_add_handlers(vcon->chr, chr_can_read, chr_read, chr_event,
vcon);
vcon->port.info->have_data = flush_buf;
+vcon->port.info->guest_open = guest_open;
+vcon->port.info->guest_close = guest_close;
}
return 0;
}
--
1.7.4.4
[Qemu-devel] [PATCH 4/6] char: Allow devices to use a single multiplexed chardev.
From: Kusanagi Kouichi
This fixes regression caused by commit
2d6c1ef40f3678ab47a4d14fb5dadaa486bfcda6
("char: Prevent multiple devices opening same chardev"):
-nodefaults -nographic -chardev stdio,id=stdio,mux=on,signal=off \
-mon stdio -device virtio-serial-pci \
-device virtconsole,chardev=stdio -device isa-serial,chardev=stdio
fails with:
qemu-system-x86_64: -device isa-serial,chardev=stdio: Property
'isa-serial.chardev' can't take value 'stdio', it's in use
Signed-off-by: Kusanagi Kouichi
Signed-off-by: Amit Shah
---
hw/qdev-properties.c |4 ++--
qemu-char.c |5 -
qemu-char.h |2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 1088a26..eff2d24 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -354,10 +354,10 @@ static int parse_chr(DeviceState *dev, Property *prop,
const char *str)
if (*ptr == NULL) {
return -ENOENT;
}
-if ((*ptr)->assigned) {
+if ((*ptr)->avail_connections < 1) {
return -EEXIST;
}
-(*ptr)->assigned = 1;
+--(*ptr)->avail_connections;
return 0;
}
diff --git a/qemu-char.c b/qemu-char.c
index 710d98f..eaf6571 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -199,7 +199,7 @@ void qemu_chr_add_handlers(CharDriverState *s,
{
if (!opaque) {
/* chr driver being released. */
-s->assigned = 0;
+++s->avail_connections;
}
s->chr_can_read = fd_can_read;
s->chr_read = fd_read;
@@ -2547,7 +2547,10 @@ CharDriverState *qemu_chr_open_opts(QemuOpts *opts,
snprintf(base->label, len, "%s-base", qemu_opts_id(opts));
chr = qemu_chr_open_mux(base);
chr->filename = base->filename;
+chr->avail_connections = MAX_MUX;
QTAILQ_INSERT_TAIL(&chardevs, chr, next);
+} else {
+chr->avail_connections = 1;
}
chr->label = qemu_strdup(qemu_opts_id(opts));
return chr;
diff --git a/qemu-char.h b/qemu-char.h
index 2f8512e..892c6da 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -72,7 +72,7 @@ struct CharDriverState {
char *label;
char *filename;
int opened;
-int assigned; /* chardev assigned to a device */
+int avail_connections;
QTAILQ_ENTRY(CharDriverState) next;
};
--
1.7.4.4
[Qemu-devel] [PATCH 5/6] char: Detect chardev release by NULL handlers as well as NULL opaque
Juan says he prefers these extra checks to ensure a user of a chardev is
releasing it.
Requested-by: Juan Quintela
Signed-off-by: Amit Shah
---
qemu-char.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index eaf6571..5e04a20 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -197,7 +197,7 @@ void qemu_chr_add_handlers(CharDriverState *s,
IOEventHandler *fd_event,
void *opaque)
{
-if (!opaque) {
+if (!opaque && !fd_can_read && !fd_read && !fd_event) {
/* chr driver being released. */
++s->avail_connections;
}
--
1.7.4.4
[Qemu-devel] [PATCH 6/6] virtio-serial: Fix endianness bug in the config space
From: Alexey Kardashevskiy
The virtio serial specification requres that the values in the config
space are encoded in native endian of the guest.
The qemu virtio-serial code did not do conversion to the guest endian
format what caused problems when host and guest use different format.
This patch corrects the qemu side, correctly doing host-native <->
guest-native conversions when accessing the config space. This won't
break any setups that aren't already broken, and fixes the case
of different host and guest endianness.
Signed-off-by: Alexey Kardashevskiy
Signed-off-by: David Gibson
Reviewed-by: Juan Quintela
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 6227379..f10d48f 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -494,7 +494,7 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
VirtIOSerial *s = opaque;
VirtIOSerialPort *port;
uint32_t nr_active_ports;
-unsigned int i;
+unsigned int i, max_nr_ports;
/* The virtio device */
virtio_save(&s->vdev, f);
@@ -506,8 +506,8 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
qemu_put_be32s(f, &s->config.max_nr_ports);
/* The ports map */
-
-for (i = 0; i < (s->config.max_nr_ports + 31) / 32; i++) {
+max_nr_ports = tswap32(s->config.max_nr_ports);
+for (i = 0; i < (max_nr_ports + 31) / 32; i++) {
qemu_put_be32s(f, &s->ports_map[i]);
}
@@ -568,7 +568,8 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
qemu_get_be16s(f, &s->config.rows);
qemu_get_be32s(f, &max_nr_ports);
-if (max_nr_ports > s->config.max_nr_ports) {
+tswap32s(&max_nr_ports);
+if (max_nr_ports > tswap32(s->config.max_nr_ports)) {
/* Source could have had more ports than us. Fail migration. */
return -EINVAL;
}
@@ -670,9 +671,10 @@ static void virtser_bus_dev_print(Monitor *mon,
DeviceState *qdev, int indent)
/* This function is only used if a port id is not provided by the user */
static uint32_t find_free_port_id(VirtIOSerial *vser)
{
-unsigned int i;
+unsigned int i, max_nr_ports;
-for (i = 0; i < (vser->config.max_nr_ports + 31) / 32; i++) {
+max_nr_ports = tswap32(vser->config.max_nr_ports);
+for (i = 0; i < (max_nr_ports + 31) / 32; i++) {
uint32_t map, bit;
map = vser->ports_map[i];
@@ -720,7 +722,7 @@ static int virtser_port_qdev_init(DeviceState *qdev,
DeviceInfo *base)
VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, qdev);
VirtIOSerialPortInfo *info = DO_UPCAST(VirtIOSerialPortInfo, qdev, base);
VirtIOSerialBus *bus = DO_UPCAST(VirtIOSerialBus, qbus, qdev->parent_bus);
-int ret;
+int ret, max_nr_ports;
bool plugging_port0;
port->vser = bus->vser;
@@ -750,9 +752,10 @@ static int virtser_port_qdev_init(DeviceState *qdev,
DeviceInfo *base)
}
}
-if (port->id >= port->vser->config.max_nr_ports) {
+max_nr_ports = tswap32(port->vser->config.max_nr_ports);
+if (port->id >= max_nr_ports) {
error_report("virtio-serial-bus: Out-of-range port id specified, max.
allowed: %u\n",
- port->vser->config.max_nr_ports - 1);
+ max_nr_ports - 1);
return -1;
}
@@ -863,7 +866,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev,
virtio_serial_conf *conf)
vser->ovqs[i] = virtio_add_queue(vdev, 128, handle_output);
}
-vser->config.max_nr_ports = conf->max_virtserial_ports;
+vser->config.max_nr_ports = tswap32(conf->max_virtserial_ports);
vser->ports_map = qemu_mallocz(((conf->max_virtserial_ports + 31) / 32)
* sizeof(vser->ports_map[0]));
/*
--
1.7.4.4
[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl
Disabling AppArmor really allows libvirt to go with no problems. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/723871 Title: qemu-kvm-0.14.0 Aborts with -vga qxl Status in QEMU: Confirmed Status in “libvirt” package in Ubuntu: Triaged Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: Host CPU is Core i7 Q820. KVM is from 2.6.35-gentoo-r5 kernel (x86_64). Host has spice-0.7.2 and spice-protocol-0.7.0. Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and vdagent 0.6.3. qemu-kvm is started like so: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio and crashes with: qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: kvm_mutex_unlock: Assertion `!cpu_single_env' failed. Aborted If I use -no-kvm, it works fine. If I use -vga std, it works fine. -enable-kvm and -vga qxl crashes.
[Qemu-devel] [PATCH] ide/atapi: fix set but unused
Signed-off-by: Alon Levy
---
hw/ide/atapi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 690a0ab..81fa01b 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -1080,12 +1080,14 @@ static const struct {
void ide_atapi_cmd(IDEState *s)
{
+#ifdef DEBUG_IDE_ATAPI
const uint8_t *packet;
+#endif
uint8_t *buf;
-packet = s->io_buffer;
buf = s->io_buffer;
#ifdef DEBUG_IDE_ATAPI
+packet = s->io_buffer;
{
int i;
printf("ATAPI limit=0x%x packet:", s->lcyl | (s->hcyl << 8));
--
1.7.4.4
[Qemu-devel] [PATCHv2 0/4] qxl: debug related fixes
These patches contain three small fixes, and one patch requiring more review that adds support for using chardevs for specific debug information: one for guest debug prints, and another for qxl command ring logging. This allows easier parsing and logging of this data for debugging. v1->v2: use qemu_get_clock_ns, replaced qemu_get_clock last patch (allow QXL_IO_LOG) fixed to use existing switch cases (and fixed the redundant parenthesis in the process). Alon Levy (4): qxl: interface_get_command: fix reported mode qxl: add mode to debugprint on destroy primary qxl: add debug_cs and cmdlog_cs qxl: allow QXL_IO_LOG also in vga hw/qxl-logger.c | 62 ++ hw/qxl.c| 35 +++--- hw/qxl.h|2 + 3 files changed, 72 insertions(+), 27 deletions(-) -- 1.7.4.4
[Qemu-devel] [PATCHv2 1/4] qxl: interface_get_command: fix reported mode
report correct mode when in undefined mode.
---
hw/qxl.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index fe4212b..63e295b 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -336,6 +336,21 @@ static void interface_get_init_info(QXLInstance *sin,
QXLDevInitInfo *info)
info->n_surfaces = NUM_SURFACES;
}
+static const char *qxl_mode_to_string(int mode)
+{
+switch (mode) {
+case QXL_MODE_COMPAT:
+return "compat";
+case QXL_MODE_NATIVE:
+return "native";
+case QXL_MODE_UNDEFINED:
+return "undefined";
+case QXL_MODE_VGA:
+return "vga";
+}
+return "unknown";
+}
+
/* called from spice server thread context only */
static int interface_get_command(QXLInstance *sin, struct QXLCommandExt *ext)
{
@@ -358,8 +373,7 @@ static int interface_get_command(QXLInstance *sin, struct
QXLCommandExt *ext)
case QXL_MODE_COMPAT:
case QXL_MODE_NATIVE:
case QXL_MODE_UNDEFINED:
-dprint(qxl, 2, "%s: %s\n", __FUNCTION__,
- qxl->cmdflags ? "compat" : "native");
+dprint(qxl, 2, "%s: %s\n", __FUNCTION__,
qxl_mode_to_string(qxl->mode));
ring = &qxl->ram->cmd_ring;
if (SPICE_RING_IS_EMPTY(ring)) {
return false;
--
1.7.4.4
[Qemu-devel] [PATCHv2 2/4] qxl: add mode to debugprint on destroy primary
--- hw/qxl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/qxl.c b/hw/qxl.c index 63e295b..ccd820c 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -1009,7 +1009,7 @@ static void ioport_write(void *opaque, uint32_t addr, uint32_t val) break; case QXL_IO_DESTROY_PRIMARY: PANIC_ON(val != 0); -dprint(d, 1, "QXL_IO_DESTROY_PRIMARY\n"); +dprint(d, 1, "QXL_IO_DESTROY_PRIMARY (%s)\n", qxl_mode_to_string(d->mode)); qxl_destroy_primary(d); break; case QXL_IO_DESTROY_SURFACE_WAIT: -- 1.7.4.4
[Qemu-devel] [PATCHv2 4/4] qxl: allow QXL_IO_LOG also in vga
The driver may change us to vga mode and still issue a QXL_IO_LOG, which we can easily support. --- hw/qxl.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/qxl.c b/hw/qxl.c index ecab001..d55f96a 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -941,6 +941,7 @@ static void ioport_write(void *opaque, uint32_t addr, uint32_t val) case QXL_IO_MEMSLOT_ADD: case QXL_IO_MEMSLOT_DEL: case QXL_IO_CREATE_PRIMARY: +case QXL_IO_LOG: break; default: if (d->mode == QXL_MODE_NATIVE || d->mode == QXL_MODE_COMPAT) -- 1.7.4.4
[Qemu-devel] [PATCHv2 3/4] qxl: add debug_cs and cmdlog_cs
With this you can output the command log and/or the guest debug (driver)
output to a chardev instead of stderr:
-global qxl-vga.cmdlog_chardev=qxl_cmdlog_chardev
-global qxl-vga.debug_chardev=qxl_debug_chardev
useful for debugging. if no chardev is specified prints to stderr like the old
code.
---
hw/qxl-logger.c | 62 ++
hw/qxl.c| 14 +++-
hw/qxl.h|2 +
3 files changed, 54 insertions(+), 24 deletions(-)
diff --git a/hw/qxl-logger.c b/hw/qxl-logger.c
index 76f43e6..df6e78b 100644
--- a/hw/qxl-logger.c
+++ b/hw/qxl-logger.c
@@ -99,6 +99,22 @@ static const char *qxl_v2n(const char *n[], size_t l, int v)
}
#define qxl_name(_list, _value) qxl_v2n(_list, ARRAY_SIZE(_list), _value)
+static void qxl_log_printf(PCIQXLDevice *qxl, const char *format, ...)
+{
+va_list ap;
+uint8_t buf[4096];
+
+va_start(ap, format);
+if (qxl->cmdlog_cs) {
+vsnprintf((char *)buf, sizeof(buf), format, ap);
+buf[sizeof(buf) - 1] = '\0';
+qemu_chr_write(qxl->cmdlog_cs, buf, strlen((char*)buf));
+} else {
+vfprintf(stderr, format, ap);
+}
+va_end(ap);
+}
+
static void qxl_log_image(PCIQXLDevice *qxl, QXLPHYSICAL addr, int group_id)
{
QXLImage *image;
@@ -106,11 +122,11 @@ static void qxl_log_image(PCIQXLDevice *qxl, QXLPHYSICAL
addr, int group_id)
image = qxl_phys2virt(qxl, addr, group_id);
desc = &image->descriptor;
-fprintf(stderr, " (id %" PRIx64 " type %d flags %d width %d height %d",
+qxl_log_printf(qxl, " (id %" PRIx64 " type %d flags %d width %d height %d",
desc->id, desc->type, desc->flags, desc->width, desc->height);
switch (desc->type) {
case SPICE_IMAGE_TYPE_BITMAP:
-fprintf(stderr, ", fmt %d flags %d x %d y %d stride %d"
+qxl_log_printf(qxl, ", fmt %d flags %d x %d y %d stride %d"
" palette %" PRIx64 " data %" PRIx64,
image->bitmap.format, image->bitmap.flags,
image->bitmap.x, image->bitmap.y,
@@ -118,12 +134,12 @@ static void qxl_log_image(PCIQXLDevice *qxl, QXLPHYSICAL
addr, int group_id)
image->bitmap.palette, image->bitmap.data);
break;
}
-fprintf(stderr, ")");
+qxl_log_printf(qxl, ")");
}
-static void qxl_log_rect(QXLRect *rect)
+static void qxl_log_rect(PCIQXLDevice *qxl, QXLRect *rect)
{
-fprintf(stderr, " %dx%d+%d+%d",
+qxl_log_printf(qxl, " %dx%d+%d+%d",
rect->right - rect->left,
rect->bottom - rect->top,
rect->left, rect->top);
@@ -131,17 +147,17 @@ static void qxl_log_rect(QXLRect *rect)
static void qxl_log_cmd_draw_copy(PCIQXLDevice *qxl, QXLCopy *copy, int
group_id)
{
-fprintf(stderr, " src %" PRIx64,
+qxl_log_printf(qxl, " src %" PRIx64,
copy->src_bitmap);
qxl_log_image(qxl, copy->src_bitmap, group_id);
-fprintf(stderr, " area");
-qxl_log_rect(©->src_area);
-fprintf(stderr, " rop %d", copy->rop_descriptor);
+qxl_log_printf(qxl, " area");
+qxl_log_rect(qxl, ©->src_area);
+qxl_log_printf(qxl, " rop %d", copy->rop_descriptor);
}
static void qxl_log_cmd_draw(PCIQXLDevice *qxl, QXLDrawable *draw, int
group_id)
{
-fprintf(stderr, ": surface_id %d type %s effect %s",
+qxl_log_printf(qxl, ": surface_id %d type %s effect %s",
draw->surface_id,
qxl_name(qxl_draw_type, draw->type),
qxl_name(qxl_draw_effect, draw->effect));
@@ -155,13 +171,13 @@ static void qxl_log_cmd_draw(PCIQXLDevice *qxl,
QXLDrawable *draw, int group_id)
static void qxl_log_cmd_draw_compat(PCIQXLDevice *qxl, QXLCompatDrawable *draw,
int group_id)
{
-fprintf(stderr, ": type %s effect %s",
+qxl_log_printf(qxl, ": type %s effect %s",
qxl_name(qxl_draw_type, draw->type),
qxl_name(qxl_draw_effect, draw->effect));
if (draw->bitmap_offset) {
-fprintf(stderr, ": bitmap %d",
+qxl_log_printf(qxl, ": bitmap %d",
draw->bitmap_offset);
-qxl_log_rect(&draw->bitmap_area);
+qxl_log_rect(qxl, &draw->bitmap_area);
}
switch (draw->type) {
case QXL_DRAW_COPY:
@@ -172,11 +188,11 @@ static void qxl_log_cmd_draw_compat(PCIQXLDevice *qxl,
QXLCompatDrawable *draw,
static void qxl_log_cmd_surface(PCIQXLDevice *qxl, QXLSurfaceCmd *cmd)
{
-fprintf(stderr, ": %s id %d",
+qxl_log_printf(qxl, ": %s id %d",
qxl_name(qxl_surface_cmd, cmd->type),
cmd->surface_id);
if (cmd->type == QXL_SURFACE_CMD_CREATE) {
-fprintf(stderr, " size %dx%d stride %d format %s (count %d, max %d)",
+qxl_log_printf(qxl, " size %dx%d stride %d format %s (count %d, max
%d)",
cmd->u.surface_create.width,
cmd->u.surface_create.height,
cmd->u.surface_create.stride,
@@ -184,7 +200,7 @@ static void qxl_log_
[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl
Just disabling libvirtd profile is enough as well :- # apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd # ln -s /etx/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/ -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/723871 Title: qemu-kvm-0.14.0 Aborts with -vga qxl Status in QEMU: Confirmed Status in “libvirt” package in Ubuntu: Triaged Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: Host CPU is Core i7 Q820. KVM is from 2.6.35-gentoo-r5 kernel (x86_64). Host has spice-0.7.2 and spice-protocol-0.7.0. Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and vdagent 0.6.3. qemu-kvm is started like so: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio and crashes with: qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: kvm_mutex_unlock: Assertion `!cpu_single_env' failed. Aborted If I use -no-kvm, it works fine. If I use -vga std, it works fine. -enable-kvm and -vga qxl crashes.
[Qemu-devel] [PATCH] qemu-progress.c: printf isn't signal safe
From: Jes Sorensen
Change the signal handling to indicate a signal is pending, rather
then printing directly from the signal handler.
In addition make the signal prints go to stderr, rather than stdout.
Signed-off-by: Jes Sorensen
---
qemu-progress.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/qemu-progress.c b/qemu-progress.c
index e1feb89..27a2310 100644
--- a/qemu-progress.c
+++ b/qemu-progress.c
@@ -32,6 +32,7 @@ struct progress_state {
float current;
float last_print;
float min_skip;
+int print_pending;
void (*print)(void);
void (*end)(void);
};
@@ -63,12 +64,16 @@ static void progress_simple_init(void)
#ifdef CONFIG_POSIX
static void sigusr_print(int signal)
{
-printf("(%3.2f/100%%)\n", state.current);
+state.print_pending = 1;
}
#endif
static void progress_dummy_print(void)
{
+if (state.print_pending) {
+fprintf(stderr, "(%3.2f/100%%)\n", state.current);
+state.print_pending = 0;
+}
}
static void progress_dummy_end(void)
--
1.7.4.4
Re: [Qemu-devel] Qemu-img convert with -B
On 28/04/11 14:36, Kevin Wolf wrote:
Am 28.04.2011 04:06, schrieb Brad Campbell:
On 27/04/11 22:02, Brad Campbell wrote:
On 27/04/11 21:56, Kevin Wolf wrote:
When you don't have a backing file, leaving an cluster unallocated means
that it's zero. When you have a backing file, it could be anything. So
if qemu-img convert wanted to save this space, it would have to read
from the backing file and leave the cluster unallocated if it reads as
zero.
This is something that qemu-img doesn't do today.
This passes cursory testing, but I'm just wondering if this is along the
right lines?
I haven't checked all details, but it looks like what I would have done.
(Though something is wrong with your indentations, I suspect that the
patch wouldn't apply)
Odd, I generated it with git diff. Must have lost something in the copy & paste
from the terminal.
I'm using tabs=spaces and a ts of 4 in vim. It seemed to fit in with the rest
of the file.
@@ -939,9 +957,16 @@ out:
free_option_parameters(create_options);
free_option_parameters(param);
qemu_free(buf);
+if (buf3) {
+qemu_free(buf3);
+}
qemu_free (and the libc free, too) work just fine with NULL, so the
check isn't needed.
I ran some more tests on it and there are some small issues I need to fix up, but it does what it
says on the tin.
Cheers for the feedback, I'll do some cleanups and prepare something for
submission.
Regards,
Brad
Re: [Qemu-devel] [PATCH] monitor: avoid moving cursor during "mouse_button" command
On 04/08/11 18:37, Luiz Capitulino wrote:
On Fri, 08 Apr 2011 16:34:21 +0200
Markus Armbruster wrote:
Brad Hards writes:
This addresses https://bugs.launchpad.net/qemu/+bug/752476 which
basically points out that using the mouse_button command causes
the mouse cursor to warp to the origin (when using absolute
pointing device).
I've tested this with a kubuntu 10.10 guest and it works fine
for me with both relative and absolute pointing devices. Note
that testing with realtive pointing device was relatively
light.
Signed-off-by: Brad Hards
---
monitor.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index f1a08dc..0ce162b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1879,6 +1879,9 @@ static void do_sendkey(Monitor *mon, const QDict *qdict)
muldiv64(get_ticks_per_sec(), hold_time, 1000));
}
+static int mouse_x;
+static int mouse_y;
+static int mouse_z;
static int mouse_button_state;
static void do_mouse_move(Monitor *mon, const QDict *qdict)
@@ -1893,13 +1896,22 @@ static void do_mouse_move(Monitor *mon, const QDict
*qdict)
if (dz_str)
dz = strtol(dz_str, NULL, 0);
kbd_mouse_event(dx, dy, dz, mouse_button_state);
+if (kbd_mouse_is_absolute()) {
+mouse_x = dx;
+mouse_y = dy;
+mouse_z = dz;
+}
}
static void do_mouse_button(Monitor *mon, const QDict *qdict)
{
int button_state = qdict_get_int(qdict, "button_state");
mouse_button_state = button_state;
-kbd_mouse_event(0, 0, 0, mouse_button_state);
+if (kbd_mouse_is_absolute()) {
+kbd_mouse_event(mouse_x, mouse_y, mouse_z, mouse_button_state);
+} else {
+kbd_mouse_event(0, 0, 0, mouse_button_state);
+}
}
static void do_ioport_read(Monitor *mon, const QDict *qdict)
There's one instance of state: position (if absolute) + buttons for any
number of mice. Funny things can happen when you have more than one
mouse and switch between them.
Even if there's just one mouse: the state is updated only for monitor
mouse action. Funny things can happen when something other than monitor
commands uses the mouse.
Shouldn't the state be kept per-mouse? Monitor could ask for current
coordinates + button state then.
Note buttons are already funny. The patch just extends the funniness to
position. Could be a valid excuse for committing it as is.
I need Gerd's input here, or anyone who has a better idea of the trade offs
involved and how this code should evolve.
I think it would be much better to keep track of the mouse position (and
button state while being at it) in input.c instead of monitor.c.
Once this is in place it should be easy to add kbd_mouse_* functions
which update position or buttons only, which the monitor code can use
then to avoid the unwanted pointer warp.
cheers,
Gerd
[Qemu-devel] [Bug 772275] Re: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging
Forget to say: i'm using a quad-amd opteron 6172 (12cores) server, 256gb ram. kvm guest launch command: /usr/bin/kvm -monitor unix:/var/run/qemu-server/124.mon,server,nowait -vnc unix:/var/run/qemu-server/124.vnc,password -pidfile /var/run/qemu- server/124.pid -daemonize -usbdevice tablet -name testmachine -smp sockets=1,cores=12 -nodefaults -boot menu=on -tdf -localtime -rtc-td- hack -k fr -vga std -device lsi,id=scsi0,bus=pci.0,addr=0x5 -device lsi,id=scsi1,bus=pci.0,addr=0x6 -drive file=/dev/cdrom,if=none,id=drive- ide2,media=cdrom -device ide-drive,bus=ide.1,unit=0,drive=drive-ide2,id =disk-ide2 -drive file=/dev/disk/by-id/scsi- 3600144f0f62f0e004d64fcaf000f,if=none,id=drive- virtio0,cache=none,boot=on -device virtio-blk-pci,drive=drive-virtio0,id =disk-virtio0,bus=pci.0,addr=0x7 -drive file=/dev/disk/by-id/scsi- 3600144f0f62f0e004d6614f00012,if=none,id=drive-virtio1,cache=none -device virtio-blk-pci,drive=drive-virtio1,id=disk- virtio1,bus=pci.0,addr=0x8 -m 4000 -netdev type=tap,id=netdev2,ifname=tap124i101d2,script=/var/lib/qemu-server /bridge-vlan,vhost=on -device virtio-net- pci,mac=76:33:01:8E:91:B8,netdev=netdev2,id=nic2,bus=pci.0,addr=0x18 -netdev type=tap,id=netdev1,ifname=tap124i31d1,script=/var/lib/qemu- server/bridge-vlan,vhost=on -device virtio-net- pci,mac=02:A5:80:68:5E:EA,netdev=netdev1,id=nic1,bus=pci.0,addr=0x17 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/772275 Title: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging Status in QEMU: New Bug description: Hi, I'm a proxmox distrib user, I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. e1000 driver working fine. revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 i'm not the only proxmox user ,more users reports here : http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio- drivers-for-Windows-and-latest-PVE-1.8 i've also see that a slackware user with winxp guest has the same problem http://www.spinics.net/lists/kvm/msg51089.html I can help to debug if it's possible to have logs somewhere .
[Qemu-devel] [Bug 772275] [NEW] qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging
Public bug reported: Hi, I'm a proxmox distrib user, I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. e1000 driver working fine. revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 i'm not the only proxmox user ,more users reports here : http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio- drivers-for-Windows-and-latest-PVE-1.8 i've also see that a slackware user with winxp guest has the same problem http://www.spinics.net/lists/kvm/msg51089.html I can help to debug if it's possible to have logs somewhere . ** 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/772275 Title: qemu-kvm-0.14.0 + kernel 2.6.35 : win2008r2 virtio nic hanging Status in QEMU: New Bug description: Hi, I'm a proxmox distrib user, I have network error with virtio nic cards in win2008r2sp1 server, only with qemu 0.14 and 2.6.35 kernel combination. after some network transferts (can be 2mb or 500mb), nic doesn't respond anymore. only way is to reboot. e1000 driver working fine. revert back to qemu 0.13+ 2.6.35 kernel works fine or qemu 0.14 + 2.6.32 kernel is working fine too. i'm using virtio nic drivers 1.1.16 from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ i had also tried the virtio-win-prewhql-0.1-7-nic.tar.gz from https://bugzilla.redhat.com/show_bug.cgi?id=630830#c26 i'm not the only proxmox user ,more users reports here : http://forum.proxmox.com/threads/6194-Troubles-with-latest-virtio- drivers-for-Windows-and-latest-PVE-1.8 i've also see that a slackware user with winxp guest has the same problem http://www.spinics.net/lists/kvm/msg51089.html I can help to debug if it's possible to have logs somewhere .
Re: [Qemu-devel] [PATCH] Fix bug with virtio-9p rename
Malahal Naineni's patch "Stop renaming files with similar name!" (posted
since this one) also fixes this bug.
I don't mind which one gets merged, as long as the bug gets fixed ;)
Sassan
On 27 April 2011 19:30, Sassan Panahinejad wrote:
> After renaming a file, any existing references to the file are updated.
> However, in addition to this, it would update any files whos names began
> with that of the file being moved.
> Therefore when renaming somefile.txt to somefile.txt-old, any references to
> somefile.txt-new became somefile.txt-old-new.
> This breaks debconf and probably many other applications.
> This patch fixes the problem. Now only files exactly matching, or files
> which are a subdirectory of a directory being moved are affected.
>
> Signed-off-by: Sassan Panahinejad
> ---
> hw/virtio-9p.c |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
> index 2530f6d..a2f096d 100644
> --- a/hw/virtio-9p.c
> +++ b/hw/virtio-9p.c
> @@ -2810,8 +2810,15 @@ static int v9fs_complete_rename(V9fsState *s,
> V9fsRenameState *vs)
> */
> continue;
> }
> +/*
> +* Fix the name if
> +* A: The file is the one we're moving
> +* Or B: The file is a subdirectory of one we're moving
> +*/
> if (!strncmp(vs->fidp->path.data, fidp->path.data,
> -strlen(vs->fidp->path.data))) {
> +strlen(vs->fidp->path.data)) &&
> +(strlen(vs->fidp->path.data) ==
> strlen(fidp->path.data) ||
> +fidp->path.data[strlen(vs->fidp->path.data)] == '/'))
> {
> /* replace the name */
> v9fs_fix_path(&fidp->path, &vs->name,
> strlen(vs->fidp->path.data));
> --
> 1.7.0.4
>
>
Re: [Qemu-devel] [PATCH] qemu-progress.c: printf isn't signal safe
jes.soren...@redhat.com writes:
> From: Jes Sorensen
>
> Change the signal handling to indicate a signal is pending, rather
> then printing directly from the signal handler.
>
> In addition make the signal prints go to stderr, rather than stdout.
>
> Signed-off-by: Jes Sorensen
> ---
> qemu-progress.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/qemu-progress.c b/qemu-progress.c
> index e1feb89..27a2310 100644
> --- a/qemu-progress.c
> +++ b/qemu-progress.c
> @@ -32,6 +32,7 @@ struct progress_state {
> float current;
> float last_print;
> float min_skip;
> +int print_pending;
To be pedantically correct: volatile sig_atomic_t print_pending
> void (*print)(void);
> void (*end)(void);
> };
I don't care for wrapping a file's static global variables in a struct,
but I guess that's water under the bridge now.
> @@ -63,12 +64,16 @@ static void progress_simple_init(void)
> #ifdef CONFIG_POSIX
> static void sigusr_print(int signal)
> {
> -printf("(%3.2f/100%%)\n", state.current);
> +state.print_pending = 1;
> }
> #endif
>
> static void progress_dummy_print(void)
> {
> +if (state.print_pending) {
> +fprintf(stderr, "(%3.2f/100%%)\n", state.current);
> +state.print_pending = 0;
> +}
> }
>
> static void progress_dummy_end(void)
Re: [Qemu-devel] [PATCH] target-arm: Move VLD/VST multiple into helper functions
Ping? The two UNDEF patches have both been applied, so this patch applies cleanly to master now. -- PMM On 20 April 2011 15:52, Peter Maydell wrote: > Move VLD/VST multiple into helper functions, as some cases can > generate more TCG ops than the maximum per-instruction limit > and certainly more than the recommended 20. > > Signed-off-by: Peter Maydell > --- > This patch is inspired by one from the meego tree: > http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=commitdiff;h=a5b2a79c7929726bac5157783de81d22793efd12 > but I've reworked it to do the decoding at translate time rather > than in the helper function. > > It is intended to apply on top of the neon load/store UNDEF fixes: > http://patchwork.ozlabs.org/patch/91824/ > http://patchwork.ozlabs.org/patch/91825/ > > but I thought it would be better to push it out now for review > rather than waiting for those to be committed. > > I hope you all like macros :-) > > target-arm/helper.h | 40 + > target-arm/neon_helper.c | 127 + > target-arm/translate.c | 140 > +++--- > 3 files changed, 199 insertions(+), 108 deletions(-)
[Qemu-devel] [PATCH v2] qemu-progress.c: printf isn't signal safe
From: Jes Sorensen
Change the signal handling to indicate a signal is pending, rather
then printing directly from the signal handler.
In addition make the signal prints go to stderr, rather than stdout.
Signed-off-by: Jes Sorensen
---
qemu-progress.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/qemu-progress.c b/qemu-progress.c
index e1feb89..a4894c0 100644
--- a/qemu-progress.c
+++ b/qemu-progress.c
@@ -37,6 +37,7 @@ struct progress_state {
};
static struct progress_state state;
+static volatile sig_atomic_t print_pending;
/*
* Simple progress print function.
@@ -63,12 +64,16 @@ static void progress_simple_init(void)
#ifdef CONFIG_POSIX
static void sigusr_print(int signal)
{
-printf("(%3.2f/100%%)\n", state.current);
+print_pending = 1;
}
#endif
static void progress_dummy_print(void)
{
+if (print_pending) {
+fprintf(stderr, "(%3.2f/100%%)\n", state.current);
+print_pending = 0;
+}
}
static void progress_dummy_end(void)
--
1.7.4.4
[Qemu-devel] [PATCHv2 1/3] virtio-serial-bus: use bh for unthrottling
Instead of calling flush_queued_data when unthrottling, schedule
a bh. That way we can return immediately to the caller, and the
flush uses the same call path as a have_data for callbackee.
---
hw/virtio-serial-bus.c | 11 +--
hw/virtio-serial.h |5 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 6227379..8556e08 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -285,6 +285,13 @@ size_t virtio_serial_guest_ready(VirtIOSerialPort *port)
return 0;
}
+static void bh_virtio_serial_flush_queued_data(void *opaque)
+{
+VirtIOSerialPort *port = opaque;
+
+flush_queued_data(port);
+}
+
void virtio_serial_throttle_port(VirtIOSerialPort *port, bool throttle)
{
if (!port) {
@@ -295,8 +302,7 @@ void virtio_serial_throttle_port(VirtIOSerialPort *port,
bool throttle)
if (throttle) {
return;
}
-
-flush_queued_data(port);
+qemu_bh_schedule(port->bh);
}
/* Guest wants to notify us of some event */
@@ -724,6 +730,7 @@ static int virtser_port_qdev_init(DeviceState *qdev,
DeviceInfo *base)
bool plugging_port0;
port->vser = bus->vser;
+port->bh = qemu_bh_new(bh_virtio_serial_flush_queued_data, port);
/*
* Is the first console port we're seeing? If so, put it up at
diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
index 5eb948e..0fa03d1 100644
--- a/hw/virtio-serial.h
+++ b/hw/virtio-serial.h
@@ -119,6 +119,11 @@ struct VirtIOSerialPort {
uint32_t iov_idx;
uint64_t iov_offset;
+/*
+ * When unthrottling we use a buttomhalf to call flush_queued_data.
+ */
+QEMUBH *bh;
+
/* Identify if this is a port that binds with hvc in the guest */
uint8_t is_console;
--
1.7.4.4
[Qemu-devel] [PATCHv2 2/3] bh: add qemu_bh_is_scheduled
---
async.c |4
qemu-common.h |1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/async.c b/async.c
index 57ac3a8..204716e 100644
--- a/async.c
+++ b/async.c
@@ -214,3 +214,7 @@ void qemu_bh_update_timeout(int *timeout)
}
}
+int qemu_bh_is_scheduled(QEMUBH *bh)
+{
+return bh->scheduled;
+}
diff --git a/qemu-common.h b/qemu-common.h
index f9f705d..a107468 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -151,6 +151,7 @@ void qemu_bh_cancel(QEMUBH *bh);
void qemu_bh_delete(QEMUBH *bh);
int qemu_bh_poll(void);
void qemu_bh_update_timeout(int *timeout);
+int qemu_bh_is_scheduled(QEMUBH *bh);
void qemu_get_timedate(struct tm *tm, int offset);
int qemu_timedate_diff(struct tm *tm);
--
1.7.4.4
[Qemu-devel] [PATCHv2 3/3] virtio-serial-bus: on migration send status of pending ports bh
migration protocol bumped to 4, adding a single byte per port which is 1 if
there is a bh scheduled, 0 otherwise.
---
hw/virtio-serial-bus.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 8556e08..7fb8ade 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -536,7 +536,7 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
qemu_put_byte(f, port->guest_connected);
qemu_put_byte(f, port->host_connected);
- elem_popped = 0;
+elem_popped = 0;
if (port->elem.out_num) {
elem_popped = 1;
}
@@ -548,6 +548,8 @@ static void virtio_serial_save(QEMUFile *f, void *opaque)
qemu_put_buffer(f, (unsigned char *)&port->elem,
sizeof(port->elem));
}
+/* Pending bh */
+qemu_put_byte(f, !!qemu_bh_is_scheduled(port->bh));
}
}
@@ -558,7 +560,7 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
uint32_t max_nr_ports, nr_active_ports, ports_map;
unsigned int i;
-if (version_id > 3) {
+if (version_id > 4) {
return -EINVAL;
}
@@ -637,7 +639,13 @@ static int virtio_serial_load(QEMUFile *f, void *opaque,
int version_id)
virtio_serial_throttle_port(port, false);
}
}
+if (version_id > 3) {
+if (qemu_get_byte(f)) {
+qemu_bh_schedule(port->bh);
+}
+}
}
+
return 0;
}
@@ -889,7 +897,7 @@ VirtIODevice *virtio_serial_init(DeviceState *dev,
virtio_serial_conf *conf)
* Register for the savevm section with the virtio-console name
* to preserve backward compat
*/
-register_savevm(dev, "virtio-console", -1, 3, virtio_serial_save,
+register_savevm(dev, "virtio-console", -1, 4, virtio_serial_save,
virtio_serial_load, vser);
return vdev;
--
1.7.4.4
[Qemu-devel] [PATCHv2 0/3] virtio-serial-bus: use a bh for flush_queued_data
This replaces the direct call of flush_queued_data with a bottom half, making the callpath for the chardev identical in a normal write and a write resulting from unthrottling. It includes a patch to add an accessor to QEMUBH to get scheduled status, to keep the bh scheduled across migration. Migration only trivially tested - just that it didn't break. Alon Levy (3): virtio-serial-bus: use bh for unthrottling bh: add qemu_bh_is_scheduled virtio-serial-bus: on migration send status of pending ports bh async.c|4 hw/virtio-serial-bus.c | 25 - hw/virtio-serial.h |5 + qemu-common.h |1 + 4 files changed, 30 insertions(+), 5 deletions(-) -- 1.7.4.4
Re: [Qemu-devel] [PATCH 1/2] Add dd-style SIGUSR1 progress reporting
On 04/28/2011 09:18 AM, Jes Sorensen wrote:
On 04/27/11 18:14, Markus Armbruster wrote:
+static void progress_simple_init(void)
+{
+state.print = progress_simple_print;
+state.end = progress_simple_end;
+}
+
+#ifdef CONFIG_POSIX
+static void sigusr_print(int signal)
+{
+printf("(%3.2f/100%%)\n", state.current);
printf() is not async-signal-safe. I don't think you can safely call it
in a signal handler.
G, you're absolutely right! Back to the drawing board!
Let's add our own version of strtol to QEMU. :)
Paolo
Re: [Qemu-devel] [PATCH] ide/atapi: fix set but unused
On 04/28/2011 10:07 AM, Alon Levy wrote:
Signed-off-by: Alon Levy
---
hw/ide/atapi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 690a0ab..81fa01b 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -1080,12 +1080,14 @@ static const struct {
void ide_atapi_cmd(IDEState *s)
{
+#ifdef DEBUG_IDE_ATAPI
const uint8_t *packet;
+#endif
uint8_t *buf;
-packet = s->io_buffer;
buf = s->io_buffer;
#ifdef DEBUG_IDE_ATAPI
+packet = s->io_buffer;
{
int i;
printf("ATAPI limit=0x%x packet:", s->lcyl | (s->hcyl<< 8));
ACK
... but why don't we allow interspersing declarations and statements?
There are already so many C99 and GCC extensions in use in QEMU.
Paolo
Re: [Qemu-devel] [PATCH] ide/atapi: fix set but unused
Am 28.04.2011 14:07, schrieb Paolo Bonzini:
On 04/28/2011 10:07 AM, Alon Levy wrote:
Signed-off-by: Alon Levy
---
hw/ide/atapi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 690a0ab..81fa01b 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -1080,12 +1080,14 @@ static const struct {
void ide_atapi_cmd(IDEState *s)
{
+#ifdef DEBUG_IDE_ATAPI
const uint8_t *packet;
+#endif
uint8_t *buf;
-packet = s->io_buffer;
buf = s->io_buffer;
#ifdef DEBUG_IDE_ATAPI
+packet = s->io_buffer;
{
int i;
printf("ATAPI limit=0x%x packet:", s->lcyl | (s->hcyl<< 8));
ACK
... but why don't we allow interspersing declarations and statements?
There are already so many C99 and GCC extensions in use in QEMU.
Paolo
What about using buf instead of packet (no need for extensions, reduces
code by 4 lines)?
Stefan W.
Re: [Qemu-devel] [PULL] qemu-timer: Add and use new function qemu_timer_expired_ns and other patches
Am 20.04.2011 16:26, schrieb Stefan Weil: Hello, the four qemu-timer related patches which I sent to qemu-devel can now be pulled. Maybe this makes the commit to git master easier. There was no feedback for the first three patches. The fourth patch changes windows code only and is needed for native windows. Cheers, Stefan Weil The following changes since commit ec52b8753a372de30b22d9b4765a799db612: target-arm: Set Invalid flag for NaN in float-to-int conversions (2011-04-20 13:01:05 +0200) are available in the git repository at: git://qemu.weilnetz.de/git/qemu.git/ patches Stefan Weil (4): qemu-timer: Add and use new function qemu_timer_expired_ns qemu-timer: Remove unneeded include statement (w32) qemu-timer: Avoid type casts qemu-timer: Fix timers for w32 qemu-timer.c | 155 -- qemu-timer.h |1 - 2 files changed, 128 insertions(+), 28 deletions(-) Ping? Is there anything missing? The patches were sent to qemu-devel on 2011-04-10. The second one is trivial. The last one is essential for w32 hosts (it only changes w32 code). The other two patches try to improve code quality a little bit.
Re: [Qemu-devel] [PATCH] ide/atapi: fix set but unused
On 04/28/2011 02:16 PM, Stefan Weil wrote: What about using buf instead of packet (no need for extensions, reduces code by 4 lines)? Uh, you're right!... I was assuming some side effect later, but after the refactoring this is indeed the only place where packet is used in the function, and it could use buf. Paolo
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/27/11 17:05, Jes Sorensen wrote:
> On 04/27/11 17:05, Luiz Capitulino wrote:
>> On Mon, 18 Apr 2011 16:27:01 +0200
>> jes.soren...@redhat.com wrote:
>>
>>> From: Jes Sorensen
>>>
>>> This is quivalent to snapshot_blkdev in the human monitor, with _sync
>>> added to the command name to make it explicit that the command is
>>> synchronous and leave space for a future async version.
>>
>> I'm not sure appending "_sync" is such a good convention, most commands
>> are sync today and they don't have it. I'd prefer to call it snapshot_blkdev
>> and note in the documentation how it works.
>>
>> On the other hand, I'm not sure how Anthony is going to model async
>> commands, so maybe he has a better suggestion.
>
> The _sync prefix is on purpose to leave space for a possible async
> implementation of the snapshot command in the future. This isn't related
> to it being a sync vs async qmp command though.
If people are more comfortable with the QMP command being
"blockdev-snapshot" and then using {-,_}async for the async comment in
the monitor and QMP later, that is fine with me.
I'd just like to move on this and get it upstream.
Cheers,
Jes
Re: [Qemu-devel] [PATCH v2] qemu-progress.c: printf isn't signal safe
jes.soren...@redhat.com writes: > From: Jes Sorensen > > Change the signal handling to indicate a signal is pending, rather > then printing directly from the signal handler. > > In addition make the signal prints go to stderr, rather than stdout. Looks good now.
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/27/11 17:05, Luiz Capitulino wrote: >> > +Synchronous snapshot of block device, using snapshot file as target >> > +if provided. > It's not optional in HMP: > > (qemu) snapshot_blkdev ide0-hd0 > Parameter 'snapshot_file' is missing > (qemu) > The parameter is optional in HMP, however it will fail if there is no snapshot filename or there is no flag for internal snapshots (which is currently unsupported). Jes
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/27/11 17:05, Luiz Capitulino wrote: >> +If a new image file is specified, the new image file will become the >> > +new root image. If format is specified, the snapshot file will be >> > +created in that format. Otherwise the snapshot will be internal! >> > +(currently unsupported). > Sorry for the stupid question, but what's a "new root image"? Also, all > these assumptions seem human features to me, as it can save some typing > and I can poke around to see where the snapshots are stored. > > All arguments should be mandatory in QMP, IMO. Sorry, but there is absolutely no reason to make all arguments mandatory. Sure it can be done, but the only result is a separate handling function for it, so we got more almost identical, but still different code to maintain. > Finally, what's the expect behavior when -snapshot is used? I'm getting > this: > > (qemu) snapshot_blkdev ide0-hd0 snap-test > Could not open '/tmp/vl.6w8YXA' > (qemu) What type of file system is your /tmp? You need to provide full path to the snapshot file if you don't want it created next to where your qemu binary is being executed. > At first, I don't see why we shouldn't generate the live snapshot, but anyway, > any special behavior like this should be noted in the section called Notes > in the command's documentation. > I don't follow this at all, please elaborate. Jes
[Qemu-devel] [Bug 772358] [NEW] VNC working depends on command line options order
Public bug reported: OS: Ubuntu 10.04.2, amd64 Pkg version: 0.12.3+noroms-0ubuntu9.5 if -nographic option is specified before -vnc, vnc works, if vice-versa, it does not. I have been told (thanks, mjt), that -nographic is supposed to disable any graphic output, including vnc, so possibly it's a documentation bug: - kvm man page talks about -nographic disabling SDL , not VNC. While it might be the same to you, it was not to me and my colleagues - if -vnc and -nographic are conflicting, perhaps kvm should error out or at least warn - monitor console's message on "change vnc 127.0.0.1:1" command: "Could not start server on 127.0.0.1:1" is not helpful either - order of the options should not matter Example: (VNC works) /usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm-ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -nographic -daemonize -vnc 127.0.0.1:1 -pidfile /var/run/kvm/1 Example: (VNC does not work, also confuses terminal): /usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm-ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -vnc 127.0.0.1:1 -nographic -daemonize -pidfile /var/run/kvm/1 ** 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/772358 Title: VNC working depends on command line options order Status in QEMU: New Bug description: OS: Ubuntu 10.04.2, amd64 Pkg version: 0.12.3+noroms-0ubuntu9.5 if -nographic option is specified before -vnc, vnc works, if vice- versa, it does not. I have been told (thanks, mjt), that -nographic is supposed to disable any graphic output, including vnc, so possibly it's a documentation bug: - kvm man page talks about -nographic disabling SDL , not VNC. While it might be the same to you, it was not to me and my colleagues - if -vnc and -nographic are conflicting, perhaps kvm should error out or at least warn - monitor console's message on "change vnc 127.0.0.1:1" command: "Could not start server on 127.0.0.1:1" is not helpful either - order of the options should not matter Example: (VNC works) /usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm- ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -nographic -daemonize -vnc 127.0.0.1:1 -pidfile /var/run/kvm/1 Example: (VNC does not work, also confuses terminal): /usr/bin/kvm -name ubuntu.example.com -m 3076 -smp 2 -drive if=virtio,file=/dev/vg0/kvm- ubuntu,boot=on,media=disk,cache=none,index=0 -net nic,vlan=0,model=virtio,macaddr=00:03:03:03:03:01 -net tap,ifname=kvm_ubuntu,vlan=0,script=no,downscript=no -balloon virtio -vnc 127.0.0.1:1 -nographic -daemonize -pidfile /var/run/kvm/1
[Qemu-devel] [PATCHv2] ide/atapi: fix set but unused
Signed-off-by: Alon Levy
---
hw/ide/atapi.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 690a0ab..0073c8d 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -1080,17 +1080,15 @@ static const struct {
void ide_atapi_cmd(IDEState *s)
{
-const uint8_t *packet;
uint8_t *buf;
-packet = s->io_buffer;
buf = s->io_buffer;
#ifdef DEBUG_IDE_ATAPI
{
int i;
printf("ATAPI limit=0x%x packet:", s->lcyl | (s->hcyl << 8));
for(i = 0; i < ATAPI_PACKET_SIZE; i++) {
-printf(" %02x", packet[i]);
+printf(" %02x", buf[i]);
}
printf("\n");
}
--
1.7.4.4
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
Am 28.04.2011 15:21, schrieb Jes Sorensen: > On 04/27/11 17:05, Luiz Capitulino wrote: >>> +If a new image file is specified, the new image file will become the +new root image. If format is specified, the snapshot file will be +created in that format. Otherwise the snapshot will be internal! +(currently unsupported). >> Sorry for the stupid question, but what's a "new root image"? Also, all >> these assumptions seem human features to me, as it can save some typing >> and I can poke around to see where the snapshots are stored. >> >> All arguments should be mandatory in QMP, IMO. > > Sorry, but there is absolutely no reason to make all arguments > mandatory. Sure it can be done, but the only result is a separate > handling function for it, so we got more almost identical, but still > different code to maintain. > >> Finally, what's the expect behavior when -snapshot is used? I'm getting >> this: >> >> (qemu) snapshot_blkdev ide0-hd0 snap-test >> Could not open '/tmp/vl.6w8YXA' >> (qemu) > > What type of file system is your /tmp? You need to provide full path to > the snapshot file if you don't want it created next to where your qemu > binary is being executed. I think the problem is that this is a temporary file, i.e. unlinked directly after it has been opened. Trying to reopen a deleted file is a bad idea. Kevin
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/11 15:41, Kevin Wolf wrote: >>> Finally, what's the expect behavior when -snapshot is used? I'm getting >>> >> this: >>> >> >>> >> (qemu) snapshot_blkdev ide0-hd0 snap-test >>> >> Could not open '/tmp/vl.6w8YXA' >>> >> (qemu) >> > >> > What type of file system is your /tmp? You need to provide full path to >> > the snapshot file if you don't want it created next to where your qemu >> > binary is being executed. > I think the problem is that this is a temporary file, i.e. unlinked > directly after it has been opened. Trying to reopen a deleted file is a > bad idea. True, but if /tmp is tmpfs, it isn't possible to open things O_DIRECT, which could also be the source of the problem here. Jes
[Qemu-devel] [PATCH] Fix bug with virtio-9p xattr functions return values
Several functions in virtio-9p-xattr.c are passing the return value of the
associated host system call back to the client instead of errno.
Since this value is -1 for any error (which, when received in the guest app as
errno, indicates "operation not permitted") it is causing guest applications to
fail in cases where the operation is not supported by the host.
This causes a number of problems with dpkg and with install.
This patch fixes the bug and returns the correct value, which means that guest
applications are able to handle the error correctly.
Signed-off-by: Sassan Panahinejad
---
hw/virtio-9p-xattr.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/hw/virtio-9p-xattr.c b/hw/virtio-9p-xattr.c
index 1aab081..fd6d892 100644
--- a/hw/virtio-9p-xattr.c
+++ b/hw/virtio-9p-xattr.c
@@ -32,9 +32,14 @@ static XattrOperations *get_xattr_operations(XattrOperations
**h,
ssize_t v9fs_get_xattr(FsContext *ctx, const char *path,
const char *name, void *value, size_t size)
{
+int ret;
XattrOperations *xops = get_xattr_operations(ctx->xops, name);
if (xops) {
-return xops->getxattr(ctx, path, name, value, size);
+ret = xops->getxattr(ctx, path, name, value, size);
+if (ret < 0) {
+return -errno;
+}
+return ret;
}
errno = -EOPNOTSUPP;
return -1;
@@ -117,9 +122,14 @@ err_out:
int v9fs_set_xattr(FsContext *ctx, const char *path, const char *name,
void *value, size_t size, int flags)
{
+int ret;
XattrOperations *xops = get_xattr_operations(ctx->xops, name);
if (xops) {
-return xops->setxattr(ctx, path, name, value, size, flags);
+ret = xops->setxattr(ctx, path, name, value, size, flags);
+if (ret < 0) {
+return -errno;
+}
+return ret;
}
errno = -EOPNOTSUPP;
return -1;
@@ -129,9 +139,14 @@ int v9fs_set_xattr(FsContext *ctx, const char *path, const
char *name,
int v9fs_remove_xattr(FsContext *ctx,
const char *path, const char *name)
{
+int ret;
XattrOperations *xops = get_xattr_operations(ctx->xops, name);
if (xops) {
-return xops->removexattr(ctx, path, name);
+ret = xops->removexattr(ctx, path, name);
+if (ret < 0) {
+return -errno;
+}
+return ret;
}
errno = -EOPNOTSUPP;
return -1;
--
1.7.0.4
[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl
Boris, you should not disable the profile but instead update it. See https://wiki.ubuntu.com/DebuggingApparmor and /usr/share/doc/libvirt- bin/README.Debian for details. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/723871 Title: qemu-kvm-0.14.0 Aborts with -vga qxl Status in QEMU: Confirmed Status in “libvirt” package in Ubuntu: Triaged Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: Host CPU is Core i7 Q820. KVM is from 2.6.35-gentoo-r5 kernel (x86_64). Host has spice-0.7.2 and spice-protocol-0.7.0. Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and vdagent 0.6.3. qemu-kvm is started like so: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio and crashes with: qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: kvm_mutex_unlock: Assertion `!cpu_single_env' failed. Aborted If I use -no-kvm, it works fine. If I use -vga std, it works fine. -enable-kvm and -vga qxl crashes.
Re: [Qemu-devel] [PULL] Request for Pull
On 04/27/2011 11:16 AM, Venkateswararao Jujjuri wrote:
The following changes since commit
661bfc80e876d32da8befe53ba0234d87fc0bcc2:
Jan Kiszka (1):
pflash: Restore & fix lazy ROMD switching
are available in the git repository at:
git://repo.or.cz/qemu/aliguori/jvrao.git for-anthony
Pulled. Thanks.
Regards,
Anthony Liguori
Aneesh Kumar K.V (3):
virtio-9p: move 9p files around
virtio-9p: Print the pdu details on return
virtio-9p: removexattr on default acl should return 0
Harsh Prateek Bora (2):
hw/virtio-9p-local.c: Remove unnecessary null char in symlink file
v9fs_walk: As per 9p2000 RFC, MAXWELEM >= nwnames >= 0.
M. Mohan Kumar (1):
virtio-9p: Bugfix to send correct iounit
Stefan Hajnoczi (1):
vl.c: Replace -virtfs string manipulation with QemuOpts
Makefile.objs | 10 --
Makefile.target | 6 ++-
configure | 2 +
{hw => fsdev}/file-op-9p.h | 0
fsdev/qemu-fsdev.h | 2 +-
hw/{ => 9pfs}/virtio-9p-debug.c | 0
hw/{ => 9pfs}/virtio-9p-debug.h | 0
hw/{ => 9pfs}/virtio-9p-local.c | 2 +-
hw/{ => 9pfs}/virtio-9p-posix-acl.c | 17 --
hw/{ => 9pfs}/virtio-9p-xattr-user.c | 2 +-
hw/{ => 9pfs}/virtio-9p-xattr.c | 2 +-
hw/{ => 9pfs}/virtio-9p-xattr.h | 0
hw/{ => 9pfs}/virtio-9p.c | 14 ++--
hw/{ => 9pfs}/virtio-9p.h | 4 +-
vl.c | 56 +++--
15 files changed, 62 insertions(+), 55 deletions(-)
rename {hw => fsdev}/file-op-9p.h (100%)
rename hw/{ => 9pfs}/virtio-9p-debug.c (100%)
rename hw/{ => 9pfs}/virtio-9p-debug.h (100%)
rename hw/{ => 9pfs}/virtio-9p-local.c (99%)
rename hw/{ => 9pfs}/virtio-9p-posix-acl.c (88%)
rename hw/{ => 9pfs}/virtio-9p-xattr-user.c (98%)
rename hw/{ => 9pfs}/virtio-9p-xattr.c (99%)
rename hw/{ => 9pfs}/virtio-9p-xattr.h (100%)
rename hw/{ => 9pfs}/virtio-9p.c (99%)
rename hw/{ => 9pfs}/virtio-9p.h (99%)
Re: [Qemu-devel] [PULL] char, virtio-serial, spice
On 04/28/2011 02:30 AM, Amit Shah wrote: Hello, These are assorted fixes to the char code, big endian handling of virtio-serial code and addition of a guest open/close notification for spice to use from virtio-console. (The git mirror might take a while to show up these patches.) Pulled. Thanks. Regards, Anthony Liguori The following changes since commit a7d3970d0635ebce1412736e7aaf11d387919dc8: target-arm: Don't update base register on abort in Thumb T1 LDM (2011-04-27 20:14:34 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/virt/qemu/amit/char.git for-anthony Alexey Kardashevskiy (1): virtio-serial: Fix endianness bug in the config space Amit Shah (1): char: Detect chardev release by NULL handlers as well as NULL opaque Hans de Goede (3): chardev: Allow frontends to notify backends of guest open / close virtio-console: notify backend of guest open / close spice-chardev: listen to frontend guest open / close Kusanagi Kouichi (1): char: Allow devices to use a single multiplexed chardev. hw/qdev-properties.c |4 ++-- hw/virtio-console.c| 18 ++ hw/virtio-serial-bus.c | 23 +-- qemu-char.c| 24 ++-- qemu-char.h|6 +- spice-qemu-char.c | 14 ++ 6 files changed, 74 insertions(+), 15 deletions(-)
[Qemu-devel] [Bug 739785] Re: qemu-i386 user mode on ARMv5 host fails (bash: fork: Invalid argument)
> Do you think it will ever get fixed in a reasonable amount of time (or ever) Well, it's on my list of things to look at, but generally my focus is the current (ARMv7) architecture, and fixing ARMv5 only bugs is lower priority. But there's a pretty good chance I'll get to it somewhere in the next few months. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/739785 Title: qemu-i386 user mode on ARMv5 host fails (bash: fork: Invalid argument) Status in QEMU: New Bug description: Good time of day everybody, I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work. 1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ 2. I comiled qemu-i386 static and put it into /i386/usr/bin/ ./configure --static --disable-blobs --disable-system --target-list=i386-linux-user make 3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. uname -a Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux 4. Added the following options into /etc/rc.local /sbin/modprobe binfmt_misc /bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register 5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld- linux.so.3 is a link to that file) from /lib/ to /i386/lib/ 6.Now i chroot into /i386 and I get this: [root@Plugbox i386]# chroot . [II aI hnve ao n@P /]# pacman -Suy bash: fork: Invalid argument 7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: [root@Plugbox linux-user-test-0.3]# make ./qemu-linux-user.sh [qemu-i386] ../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! make: *** [test] Error 127
[Qemu-devel] [PATCH] multiboot: set boot_device to first partition
The multiboot info struct's 'boot_device' field has 'part1' set to 0x01, which
maps to the second primary partition. To specify the first primary partition,
'part1' should be set to 0x00, since partition numbers start from zero
according to the multiboot spec.
Signed-off-by: Arun Thomas
---
hw/multiboot.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/multiboot.c b/hw/multiboot.c
index 394ed01..6e6cfb9 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -307,7 +307,7 @@ int load_multiboot(void *fw_cfg,
| MULTIBOOT_FLAGS_MMAP);
stl_p(bootinfo + MBI_MEM_LOWER, 640);
stl_p(bootinfo + MBI_MEM_UPPER, (ram_size / 1024) - 1024);
-stl_p(bootinfo + MBI_BOOT_DEVICE, 0x8001); /* XXX: use the -boot
switch? */
+stl_p(bootinfo + MBI_BOOT_DEVICE, 0x8000); /* XXX: use the -boot
switch? */
stl_p(bootinfo + MBI_MMAP_ADDR, ADDR_E820_MAP);
mb_debug("multiboot: mh_entry_addr = %#x\n", mh_entry_addr);
--
tg: (d16e0f0..) bootdev (depends on: master)
[Qemu-devel] [PATCH v3] QMP: add snapshot_blkdev command
From: Jes Sorensen
Add QMP bits for snapshot_blkdev command. This is the same as
snapshot_blkdev in the human monitor. The command is synchronous. In
the future async commands may be added with the name _async/-async.
Signed-off-by: Jes Sorensen
---
qmp-commands.hx | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index fbd98ee..24e9c3e 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -667,6 +667,44 @@ Example:
EQMP
{
+.name = "blockdev-snapshot",
+.args_type = "device:B,snapshot_file:s?,format:s?",
+.params = "device [new-image-file] [format]",
+.help = "initiates a live snapshot\n\t\t\t"
+ "of device. If a new image file is specified,
the\n\t\t\t"
+ "new image file will become the new root image.\n\t\t\t"
+ "If format is specified, the snapshot file will\n\t\t\t"
+ "be created in that format. Otherwise the\n\t\t\t"
+ "snapshot will be internal! (currently unsupported)",
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_snapshot_blkdev,
+},
+
+SQMP
+blockdev-snapshot-sync
+--
+
+Synchronous snapshot of block device, using snapshot file as target,
+if provided.
+
+Arguments:
+
+- "device": device name to snapshot (json-string)
+- "snapshot_file": name of new image file (json-string)
+- "format": format of now image (json-string)
+
+Example:
+
+-> { "execute": "blockdev-snapshot", "arguments": { "device": "ide-hd0",
+"snapshot_file":
+"/some/place/my-image",
+ "format": "qcow2"
+ } }
+<- { "return": {} }
+
+EQMP
+
+{
.name = "balloon",
.args_type = "value:M",
.params = "target",
--
1.7.4.4
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On Thu, 28 Apr 2011 15:21:41 +0200 Jes Sorensen wrote: > On 04/27/11 17:05, Luiz Capitulino wrote: > >> +If a new image file is specified, the new image file will become the > >> > +new root image. If format is specified, the snapshot file will be > >> > +created in that format. Otherwise the snapshot will be internal! > >> > +(currently unsupported). > > Sorry for the stupid question, but what's a "new root image"? Also, all > > these assumptions seem human features to me, as it can save some typing > > and I can poke around to see where the snapshots are stored. > > > > All arguments should be mandatory in QMP, IMO. > > Sorry, but there is absolutely no reason to make all arguments > mandatory. Sure it can be done, but the only result is a separate > handling function for it, so we got more almost identical, but still > different code to maintain. We shouldn't compromise our external interface quality because of implementation details. What I'm really asking here is whether this is a good command for our management tools. For example, I've just realized that the new root image is going to be automatically created after the first call to this command, and subsequent calls w/o the snapshot file name will re-use that file. Is that correct? Also note the optional format usage, the command (randomly) picks qcow2 if the format is not given. What happens if I pass a raw image and don't specify the format? Will it work as it works for qcow2? I'm not exactly asking for mandatory arguments. For the format argument for example, we could try to auto-detect the format (is it possible)? And then we could fail with a meaningful error message. And, I also would like to hear from Anthony, as he's picking up QMP maintenance. > > Finally, what's the expect behavior when -snapshot is used? I'm getting > > this: > > > > (qemu) snapshot_blkdev ide0-hd0 snap-test > > Could not open '/tmp/vl.6w8YXA' > > (qemu) > > What type of file system is your /tmp? ext4 > You need to provide full path to > the snapshot file if you don't want it created next to where your qemu > binary is being executed. I'm not running in /tmp. > > At first, I don't see why we shouldn't generate the live snapshot, but > > anyway, > > any special behavior like this should be noted in the section called Notes > > in the command's documentation. > > > > I don't follow this at all, please elaborate. Any kind of limitation should be noted in the documentation.
[Qemu-devel] [Bug 723871] Re: qemu-kvm-0.14.0 Aborts with -vga qxl
Thanks for advice. My primary target was to make sure , that it's not libvirt 8.8.1 on Ubuntu 11.04 issue. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/723871 Title: qemu-kvm-0.14.0 Aborts with -vga qxl Status in QEMU: Confirmed Status in “libvirt” package in Ubuntu: Triaged Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: Host CPU is Core i7 Q820. KVM is from 2.6.35-gentoo-r5 kernel (x86_64). Host has spice-0.7.2 and spice-protocol-0.7.0. Guest is Windows XP SP3 with qxl driver 0.6.1, virtio-serial 1.1.6 and vdagent 0.6.3. qemu-kvm is started like so: qemu-system-x86_64 -cpu host -enable-kvm -pidfile /home/rick/qemu/hds/wxp.pid -drive file=/home/rick/qemu/hds/wxp.raw,if=virtio,media=disk,aio=native,snapshot=on -m 768 -name WinXP -net nic,model=virtio -net user -localtime -usb -vga qxl -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -spice port=1234,disable-ticketing -monitor stdio and crashes with: qemu-system-x86_64: /home/rick/qemu/src/qemu-kvm-0.14.0/qemu-kvm.c:1724: kvm_mutex_unlock: Assertion `!cpu_single_env' failed. Aborted If I use -no-kvm, it works fine. If I use -vga std, it works fine. -enable-kvm and -vga qxl crashes.
[Qemu-devel] [PATCH v3 0/5] hpet 'driftfix': alleviate time drift with HPET periodic timers
Hi, This is version 3 of a series of patches that I originally posted in: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01989.html http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01992.html http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01991.html http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01990.html http://article.gmane.org/gmane.comp.emulators.kvm.devel/69325 http://article.gmane.org/gmane.comp.emulators.kvm.devel/69326 http://article.gmane.org/gmane.comp.emulators.kvm.devel/69327 http://article.gmane.org/gmane.comp.emulators.kvm.devel/69328 Changes since version 2: - The vmstate related to 'driftfix' is now in a separate subsection that can be migrated conditionally. - The new fields of the HPETTimer structure are no longer initialized in hpet_init(). This is now done in hpet_reset() only. - Compensation of lost timer interrupts is now based on a backlog of unaccounted HPET clock periods instead of 'irqs_to_inject'. This eliminates the need to scale 'irqs_to_inject' when a guest o/s modifies the comparator register value. Please review and please comment. Regards, Uli Ulrich Obergfell (5): hpet 'driftfix': add hooks required to detect coalesced interrupts (x86 apic only) hpet 'driftfix': add driftfix property to HPETState and DeviceInfo hpet 'driftfix': add fields to HPETTimer and VMStateDescription hpet 'driftfix': add code in update_irq() to detect coalesced interrupts (x86 apic only) hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts hw/apic.c |4 ++ hw/hpet.c | 114 ++-- sysemu.h |3 ++ vl.c |3 ++ 4 files changed, 120 insertions(+), 4 deletions(-)
[Qemu-devel] [PATCH v3 1/5] hpet 'driftfix': add hooks required to detect coalesced interrupts (x86 apic only)
'target_get_irq_delivered' and 'target_reset_irq_delivered' contain
entry addresses of functions that are utilized by update_irq() to
detect coalesced interrupts. apic code loads these pointers during
initialization.
This change can be replaced if a generic feedback infrastructure to
track coalesced IRQs for periodic, clock providing devices becomes
available.
Signed-off-by: Ulrich Obergfell
---
hw/apic.c |4
sysemu.h |3 +++
vl.c |3 +++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index a45b57f..eb0f6d9 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -24,6 +24,7 @@
#include "sysbus.h"
#include "trace.h"
#include "kvm.h"
+#include "sysemu.h"
/* APIC Local Vector Table */
#define APIC_LVT_TIMER 0
@@ -1143,6 +1144,9 @@ static SysBusDeviceInfo apic_info = {
static void apic_register_devices(void)
{
+target_get_irq_delivered = apic_get_irq_delivered;
+target_reset_irq_delivered = apic_reset_irq_delivered;
+
sysbus_register_withprop(&apic_info);
}
diff --git a/sysemu.h b/sysemu.h
index 07d85cd..75b0139 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -98,6 +98,9 @@ int qemu_savevm_state_complete(Monitor *mon, QEMUFile *f);
void qemu_savevm_state_cancel(Monitor *mon, QEMUFile *f);
int qemu_loadvm_state(QEMUFile *f);
+extern int (*target_get_irq_delivered)(void);
+extern void (*target_reset_irq_delivered)(void);
+
/* SLIRP */
void do_info_slirp(Monitor *mon);
diff --git a/vl.c b/vl.c
index 0c24e07..7bab315 100644
--- a/vl.c
+++ b/vl.c
@@ -233,6 +233,9 @@ const char *prom_envs[MAX_PROM_ENVS];
const char *nvram = NULL;
int boot_menu;
+int (*target_get_irq_delivered)(void) = 0;
+void (*target_reset_irq_delivered)(void) = 0;
+
typedef struct FWBootEntry FWBootEntry;
struct FWBootEntry {
--
1.6.2.5
[Qemu-devel] [PATCH v3 3/5] hpet 'driftfix': add fields to HPETTimer and VMStateDescription
The new fields in HPETTimer are covered by a separate VMStateDescription
which is a subsection of 'vmstate_hpet_timer'. They are only migrated if
-global hpet.driftfix=on
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 7513065..7ab6e62 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -55,6 +55,10 @@ typedef struct HPETTimer { /* timers */
uint8_t wrap_flag; /* timer pop will indicate wrap for one-shot 32-bit
* mode. Next pop will be actual timer expiration.
*/
+uint64_t prev_period;
+uint64_t ticks_not_accounted;
+uint32_t irq_rate;
+uint32_t divisor;
} HPETTimer;
typedef struct HPETState {
@@ -246,6 +250,27 @@ static int hpet_post_load(void *opaque, int version_id)
return 0;
}
+static bool hpet_timer_driftfix_vmstate_needed(void *opaque)
+{
+HPETTimer *t = opaque;
+
+return (t->state->driftfix != 0);
+}
+
+static const VMStateDescription vmstate_hpet_timer_driftfix = {
+.name = "hpet_timer_driftfix",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField []) {
+VMSTATE_UINT64(prev_period, HPETTimer),
+VMSTATE_UINT64(ticks_not_accounted, HPETTimer),
+VMSTATE_UINT32(irq_rate, HPETTimer),
+VMSTATE_UINT32(divisor, HPETTimer),
+VMSTATE_END_OF_LIST()
+}
+};
+
static const VMStateDescription vmstate_hpet_timer = {
.name = "hpet_timer",
.version_id = 1,
@@ -260,6 +285,14 @@ static const VMStateDescription vmstate_hpet_timer = {
VMSTATE_UINT8(wrap_flag, HPETTimer),
VMSTATE_TIMER(qemu_timer, HPETTimer),
VMSTATE_END_OF_LIST()
+},
+.subsections = (VMStateSubsection []) {
+{
+.vmsd = &vmstate_hpet_timer_driftfix,
+.needed = hpet_timer_driftfix_vmstate_needed,
+}, {
+/* empty */
+}
}
};
--
1.6.2.5
[Qemu-devel] [PATCH v3 4/5] hpet 'driftfix': add code in update_irq() to detect coalesced interrupts (x86 apic only)
update_irq() uses a similar method as in 'rtc_td_hack' to detect
coalesced interrupts. The function entry addresses are retrieved
from 'target_get_irq_delivered' and 'target_reset_irq_delivered'.
This change can be replaced if a generic feedback infrastructure to
track coalesced IRQs for periodic, clock providing devices becomes
available.
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 7ab6e62..35466ae 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -31,6 +31,7 @@
#include "hpet_emul.h"
#include "sysbus.h"
#include "mc146818rtc.h"
+#include "sysemu.h"
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -175,11 +176,12 @@ static inline uint64_t hpet_calculate_diff(HPETTimer *t,
uint64_t current)
}
}
-static void update_irq(struct HPETTimer *timer, int set)
+static int update_irq(struct HPETTimer *timer, int set)
{
uint64_t mask;
HPETState *s;
int route;
+int irq_delivered = 1;
if (timer->tn <= 1 && hpet_in_legacy_mode(timer->state)) {
/* if LegacyReplacementRoute bit is set, HPET specification requires
@@ -204,8 +206,17 @@ static void update_irq(struct HPETTimer *timer, int set)
qemu_irq_raise(s->irqs[route]);
} else {
s->isr &= ~mask;
-qemu_irq_pulse(s->irqs[route]);
+if (s->driftfix && target_get_irq_delivered
+&& target_reset_irq_delivered) {
+target_reset_irq_delivered();
+qemu_irq_raise(s->irqs[route]);
+irq_delivered = target_get_irq_delivered();
+qemu_irq_lower(s->irqs[route]);
+} else {
+qemu_irq_pulse(s->irqs[route]);
+}
}
+return irq_delivered;
}
static void hpet_pre_save(void *opaque)
--
1.6.2.5
[Qemu-devel] [PATCH v3 2/5] hpet 'driftfix': add driftfix property to HPETState and DeviceInfo
driftfix is a 'bit type' property. Compensation of delayed callbacks
and coalesced interrupts can be enabled with the command line option
-global hpet.driftfix=on
driftfix is 'off' (disabled) by default.
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 6ce07bc..7513065 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -72,6 +72,8 @@ typedef struct HPETState {
uint64_t isr; /* interrupt status reg */
uint64_t hpet_counter; /* main counter */
uint8_t hpet_id; /* instance id */
+
+uint32_t driftfix;
} HPETState;
static uint32_t hpet_in_legacy_mode(HPETState *s)
@@ -738,6 +740,7 @@ static SysBusDeviceInfo hpet_device_info = {
.qdev.props = (Property[]) {
DEFINE_PROP_UINT8("timers", HPETState, num_timers, HPET_MIN_TIMERS),
DEFINE_PROP_BIT("msi", HPETState, flags, HPET_MSI_SUPPORT, false),
+DEFINE_PROP_BIT("driftfix", HPETState, driftfix, 0, false),
DEFINE_PROP_END_OF_LIST(),
},
};
--
1.6.2.5
[Qemu-devel] [PATCH v3 5/5] hpet 'driftfix': add code in hpet_timer() to compensate delayed callbacks and coalesced interrupts
Loss of periodic timer interrupts caused by delayed callbacks and by
interrupt coalescing is compensated by gradually injecting additional
interrupts during subsequent timer intervals, starting at a rate of
one additional interrupt per interval. The injection of additional
interrupts is based on a backlog of unaccounted HPET clock periods
(new HPETTimer field 'ticks_not_accounted'). The backlog increases
due to delayed callbacks and coalesced interrupts, and it decreases
if an interrupt was injected successfully. If the backlog increases
while compensation is still in progress, the rate at which additional
interrupts are injected is increased too. A limit is imposed on the
backlog and on the rate.
Injecting additional timer interrupts to compensate lost interrupts
can alleviate long term time drift. However, on a short time scale,
this method can have the side effect of making virtual machine time
intermittently pass slower and faster than real time (depending on
the guest's time keeping algorithm). Compensation is disabled by
default and can be enabled for guests where this behaviour may be
acceptable.
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 63 +++-
1 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 35466ae..92d5f58 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -32,6 +32,7 @@
#include "sysbus.h"
#include "mc146818rtc.h"
#include "sysemu.h"
+#include
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -42,6 +43,9 @@
#define HPET_MSI_SUPPORT0
+#define MAX_TICKS_NOT_ACCOUNTED (uint64_t)5 /* 5 sec */
+#define MAX_IRQ_RATE(uint32_t)10
+
struct HPETState;
typedef struct HPETTimer { /* timers */
uint8_t tn; /*timer number*/
@@ -326,28 +330,63 @@ static const VMStateDescription vmstate_hpet = {
}
};
+static bool hpet_timer_has_tick_backlog(HPETTimer *t)
+{
+uint64_t backlog = t->ticks_not_accounted - (t->period + t->prev_period);
+return (backlog >= t->period);
+}
+
/*
* timer expiration callback
*/
static void hpet_timer(void *opaque)
{
HPETTimer *t = opaque;
+HPETState *s = t->state;
uint64_t diff;
-
+int irq_delivered = 0;
+uint32_t irq_count = 0;
uint64_t period = t->period;
uint64_t cur_tick = hpet_get_ticks(t->state);
+if (s->driftfix && !t->ticks_not_accounted) {
+t->ticks_not_accounted = t->prev_period = t->period;
+}
if (timer_is_periodic(t) && period != 0) {
if (t->config & HPET_TN_32BIT) {
while (hpet_time_after(cur_tick, t->cmp)) {
t->cmp = (uint32_t)(t->cmp + t->period);
+t->ticks_not_accounted += t->period;
+irq_count++;
}
} else {
while (hpet_time_after64(cur_tick, t->cmp)) {
t->cmp += period;
+t->ticks_not_accounted += period;
+irq_count++;
}
}
diff = hpet_calculate_diff(t, cur_tick);
+if (s->driftfix) {
+if (t->ticks_not_accounted > MAX_TICKS_NOT_ACCOUNTED) {
+t->ticks_not_accounted = t->period + t->prev_period;
+}
+if (hpet_timer_has_tick_backlog(t)) {
+if (t->irq_rate == 1 || irq_count > 1) {
+t->irq_rate++;
+t->irq_rate = MIN(t->irq_rate, MAX_IRQ_RATE);
+}
+if (t->divisor == 0) {
+assert(irq_count);
+}
+if (irq_count) {
+t->divisor = t->irq_rate;
+}
+diff /= t->divisor--;
+} else {
+t->irq_rate = 1;
+}
+}
qemu_mod_timer(t->qemu_timer,
qemu_get_clock_ns(vm_clock) +
(int64_t)ticks_to_ns(diff));
} else if (t->config & HPET_TN_32BIT && !timer_is_periodic(t)) {
@@ -358,7 +397,22 @@ static void hpet_timer(void *opaque)
t->wrap_flag = 0;
}
}
-update_irq(t, 1);
+if (s->driftfix && timer_is_periodic(t) && period != 0) {
+if (t->ticks_not_accounted >= t->period + t->prev_period) {
+irq_delivered = update_irq(t, 1);
+if (irq_delivered) {
+t->ticks_not_accounted -= t->prev_period;
+t->prev_period = t->period;
+} else {
+if (irq_count) {
+t->irq_rate++;
+t->irq_rate = MIN(t->irq_rate, MAX_IRQ_RATE);
+}
+}
+}
+} else {
+update_irq(t, 1);
+}
}
static void hpet_set_timer(HPETTimer *t)
@@ -697,6 +751,11 @@ static void hpet_reset(DeviceState *d)
timer->config |= 0x0004ULL << 32;
timer->period = 0ULL;
timer->wrap_flag = 0;
+
+timer->prev_period = 0;
+timer->ticks_not_accounted = 0;
+
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/11 16:21, Luiz Capitulino wrote: > On Thu, 28 Apr 2011 15:21:41 +0200 > Jes Sorensen wrote: > >> On 04/27/11 17:05, Luiz Capitulino wrote: >>> All arguments should be mandatory in QMP, IMO. >> >> Sorry, but there is absolutely no reason to make all arguments >> mandatory. Sure it can be done, but the only result is a separate >> handling function for it, so we got more almost identical, but still >> different code to maintain. > > We shouldn't compromise our external interface quality because of > implementation details. What I'm really asking here is whether this is > a good command for our management tools. It has been discussed repeatedly for months, so yes I will argue it is. > For example, I've just realized that the new root image is going to be > automatically created after the first call to this command, and subsequent > calls w/o the snapshot file name will re-use that file. Is that correct? No of course not. Every call to snapshot-blockdev will create a new snapshot. If you don't specify a filename, the new snapshot will be internal, except you will get an error as we don't currently support that. snapshots can be chained, so you can end up with a snapshot pointing to the previous snapshot, which points to the previous snapshot, which points to the original image . > Also note the optional format usage, the command (randomly) picks qcow2 if > the format is not given. What happens if I pass a raw image and don't specify > the format? Will it work as it works for qcow2? The command doesn't pick randomly, it picks the default cow format for qemu. You cannot pass a raw image as it is not cow compatible. > I'm not exactly asking for mandatory arguments. For the format argument for > example, we could try to auto-detect the format (is it possible)? And then > we could fail with a meaningful error message. The code is in there now, and there hasn't been requests for this in the past. The introduction of the qmp wrapper is not the place to discuss this. > And, I also would like to hear from Anthony, as he's picking up QMP > maintenance. Anthony already stated to me that he was fairly happy with it. However you are the QMP maintainer, so it needs to go in via the QMP tree. >>> Finally, what's the expect behavior when -snapshot is used? I'm getting >>> this: >>> >>> (qemu) snapshot_blkdev ide0-hd0 snap-test >>> Could not open '/tmp/vl.6w8YXA' >>> (qemu) >> >> What type of file system is your /tmp? > > ext4 > >> You need to provide full path to >> the snapshot file if you don't want it created next to where your qemu >> binary is being executed. > > I'm not running in /tmp. Well something is funny with your /tmp then, as the above isn't normal behavior. >>> At first, I don't see why we shouldn't generate the live snapshot, but >>> anyway, >>> any special behavior like this should be noted in the section called Notes >>> in the command's documentation. >>> >> >> I don't follow this at all, please elaborate. > > Any kind of limitation should be noted in the documentation. We cannot document a users choice of /tmp, when /tmp isn't part of what the command does. Jes
[Qemu-devel] [PATCH 1/2] atapi: Move comment to proper place
Move misplaced comment for media_is_dvd()
Signed-off-by: Amit Shah
---
hw/ide/atapi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 690a0ab..86b18d8 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -71,12 +71,12 @@ static void lba_to_msf(uint8_t *buf, int lba)
buf[2] = lba % 75;
}
-/* XXX: DVDs that could fit on a CD will be reported as a CD */
static inline int media_present(IDEState *s)
{
return (s->nb_sectors > 0);
}
+/* XXX: DVDs that could fit on a CD will be reported as a CD */
static inline int media_is_dvd(IDEState *s)
{
return (media_present(s) && s->nb_sectors > CD_MAX_SECTORS);
--
1.7.4.4
[Qemu-devel] [PATCH 2/2] atapi: Explain why we need a 'media not present' state
After the re-org of the atapi code, it might not be intuitive for a
reader of the code to understand why we're inserting a 'media not
present' state between cd changes.
Signed-off-by: Amit Shah
---
hw/ide/atapi.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 86b18d8..58febc0 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -1106,7 +1106,13 @@ void ide_atapi_cmd(IDEState *s)
ide_atapi_cmd_check_status(s);
return;
}
-
+/*
+ * When a CD gets changed, we have to report an ejected state and
+ * then a loaded state to guests so that they detect tray
+ * open/close and media change events. Guests that do not use
+ * GET_EVENT_STATUS_NOTIFICATION to detect such tray open/close
+ * states rely on this behavior.
+ */
if (bdrv_is_inserted(s->bs) && s->cdrom_changed) {
ide_atapi_cmd_error(s, SENSE_NOT_READY, ASC_MEDIUM_NOT_PRESENT);
--
1.7.4.4
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/27/2011 10:05 AM, Luiz Capitulino wrote:
On Mon, 18 Apr 2011 16:27:01 +0200
jes.soren...@redhat.com wrote:
From: Jes Sorensen
This is quivalent to snapshot_blkdev in the human monitor, with _sync
added to the command name to make it explicit that the command is
synchronous and leave space for a future async version.
I'm not sure appending "_sync" is such a good convention, most commands
are sync today and they don't have it. I'd prefer to call it snapshot_blkdev
and note in the documentation how it works.
It probably should be called snapshot_blkdev_broken because that's what
it really is.
The '_sync' is there to indicate that this command doesn't properly
implement asynchronous logic and can break a guest.
I'd actually prefer that we not expose this command through QMP at all
and instead implement a proper snapshot command.
Regards,
Anthony Liguori
On the other hand, I'm not sure how Anthony is going to model async
commands, so maybe he has a better suggestion.
Signed-off-by: Jes Sorensen
---
qmp-commands.hx | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index fbd98ee..b8f537c 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -667,6 +667,32 @@ Example:
EQMP
{
+.name = "blockdev-snapshot-sync",
+.args_type = "device:B,snapshot_file:s?,format:s?",
+.params = "device [new-image-file] [format]",
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_snapshot_blkdev,
+},
+
+SQMP
This doesn't follow QMP doc convention, which is:
command name
(Explain how the command works, like you do below)
Arguments
Example
+Synchronous snapshot of block device, using snapshot file as target
+if provided.
It's not optional in HMP:
(qemu) snapshot_blkdev ide0-hd0
Parameter 'snapshot_file' is missing
(qemu)
And the command argument is called "snapshot_file" not "new-image-file"
as written in the HMP help text.
+
+If a new image file is specified, the new image file will become the
+new root image. If format is specified, the snapshot file will be
+created in that format. Otherwise the snapshot will be internal!
+(currently unsupported).
Sorry for the stupid question, but what's a "new root image"? Also, all
these assumptions seem human features to me, as it can save some typing
and I can poke around to see where the snapshots are stored.
All arguments should be mandatory in QMP, IMO.
Finally, what's the expect behavior when -snapshot is used? I'm getting
this:
(qemu) snapshot_blkdev ide0-hd0 snap-test
Could not open '/tmp/vl.6w8YXA'
(qemu)
At first, I don't see why we shouldn't generate the live snapshot, but anyway,
any special behavior like this should be noted in the section called Notes
in the command's documentation.
+
+Errors:
+If creating the new snapshot image fails, QEMU will continue running
+on the original image. If switching to the newly created image fails,
+it will be attempted to fall back to the original image and return
+QERR_OPEN_FILE_FAILED with the snapshot filename. If re-opening
+the original image fails, QERR_OPEN_FILE_FAILED will be returned with
+the original image filename.
+EQMP
+
+{
.name = "balloon",
.args_type = "value:M",
.params = "target",
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/2011 09:21 AM, Luiz Capitulino wrote: On Thu, 28 Apr 2011 15:21:41 +0200 Jes Sorensen wrote: On 04/27/11 17:05, Luiz Capitulino wrote: +If a new image file is specified, the new image file will become the +new root image. If format is specified, the snapshot file will be +created in that format. Otherwise the snapshot will be internal! +(currently unsupported). Sorry for the stupid question, but what's a "new root image"? Also, all these assumptions seem human features to me, as it can save some typing and I can poke around to see where the snapshots are stored. All arguments should be mandatory in QMP, IMO. Sorry, but there is absolutely no reason to make all arguments mandatory. Sure it can be done, but the only result is a separate handling function for it, so we got more almost identical, but still different code to maintain. We shouldn't compromise our external interface quality because of implementation details. What I'm really asking here is whether this is a good command for our management tools. For example, I've just realized that the new root image is going to be automatically created after the first call to this command, and subsequent calls w/o the snapshot file name will re-use that file. Is that correct? Also note the optional format usage, the command (randomly) picks qcow2 if the format is not given. What happens if I pass a raw image and don't specify the format? Will it work as it works for qcow2? I'm not exactly asking for mandatory arguments. For the format argument for example, we could try to auto-detect the format (is it possible)? And then we could fail with a meaningful error message. And, I also would like to hear from Anthony, as he's picking up QMP maintenance. I've been ignoring this interface because it's fundamentally broken. Maybe we should not expose this via QMP and instead focus on making a proper interface for this operation. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/11 16:36, Anthony Liguori wrote: > On 04/27/2011 10:05 AM, Luiz Capitulino wrote: >> On Mon, 18 Apr 2011 16:27:01 +0200 >> jes.soren...@redhat.com wrote: >> >>> From: Jes Sorensen >>> >>> This is quivalent to snapshot_blkdev in the human monitor, with _sync >>> added to the command name to make it explicit that the command is >>> synchronous and leave space for a future async version. >> >> I'm not sure appending "_sync" is such a good convention, most commands >> are sync today and they don't have it. I'd prefer to call it >> snapshot_blkdev >> and note in the documentation how it works. > > It probably should be called snapshot_blkdev_broken because that's what > it really is. > > The '_sync' is there to indicate that this command doesn't properly > implement asynchronous logic and can break a guest. > > I'd actually prefer that we not expose this command through QMP at all > and instead implement a proper snapshot command. Sorry but this is utterly bogus. The snapshot support as is works fine, and the command is in the monitor. We should expose it in QMP as well. If we eventually get a different implementation, then we can rename it or replace it then. Jes
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
Am 28.04.2011 15:46, schrieb Jes Sorensen: > On 04/28/11 15:41, Kevin Wolf wrote: Finally, what's the expect behavior when -snapshot is used? I'm getting >> this: >> >> (qemu) snapshot_blkdev ide0-hd0 snap-test >> Could not open '/tmp/vl.6w8YXA' >> (qemu) What type of file system is your /tmp? You need to provide full path to the snapshot file if you don't want it created next to where your qemu binary is being executed. >> I think the problem is that this is a temporary file, i.e. unlinked >> directly after it has been opened. Trying to reopen a deleted file is a >> bad idea. > > True, but if /tmp is tmpfs, it isn't possible to open things O_DIRECT, > which could also be the source of the problem here. Not really, -snapshot is very clearly the problem here. Note that what's failing here is not opening the new snapshot but the old temporary image created by -snapshot. Kevin
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/11 16:42, Kevin Wolf wrote: > What type of file system is your /tmp? You need to provide full path to > the snapshot file if you don't want it created next to where your > qemu > binary is being executed. >>> >> I think the problem is that this is a temporary file, i.e. unlinked >>> >> directly after it has been opened. Trying to reopen a deleted file is a >>> >> bad idea. >> > >> > True, but if /tmp is tmpfs, it isn't possible to open things O_DIRECT, >> > which could also be the source of the problem here. > Not really, -snapshot is very clearly the problem here. Note that what's > failing here is not opening the new snapshot but the old temporary image > created by -snapshot. Sorry you are losing me here - why would reopening the old image fail? And if it fails, why does it have such a bizarre name in Luiz's case? Jes
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/2011 09:38 AM, Jes Sorensen wrote: Sorry but this is utterly bogus. The snapshot support as is works fine, and the command is in the monitor. We should expose it in QMP as well. It went in for the monitor because it was considered an imperfect command so we held up the QMP side because we wanted a better interface. The current command does: 1) Create new image backing to current image 2) Flush outstanding I/O to old image 3) Close current image 4) Reopen newly created image 5) Go Operations (1) and (2) are very synchronous operations. (4) can be too. We really should have a bdrv_aio_snapshot() function that implements the logic for at least (2) in an asynchronous fashion. That sort of interface is going to affect how we expose things in QMP. As from a QMP perspective, we're going to do something like: a) start snapshot b) query snapshot progress c) receive notification of snapshot completion d) flip over image And of course, this needs to be carefully thought through for race conditions. In the current command, what happens if you get a crash between (2) and (3)? There's no way for the management tools to know that we didn't finish flushing writes. How does the management tool know that (1) didn't fail mid way through resulting in a corrupted image? Regards, Anthony Liguori
Re: [Qemu-devel] [PATCHv2] ide/atapi: fix set but unused
Am 28.04.2011 15:34, schrieb Alon Levy:
Signed-off-by: Alon Levy
---
hw/ide/atapi.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index 690a0ab..0073c8d 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -1080,17 +1080,15 @@ static const struct {
void ide_atapi_cmd(IDEState *s)
{
-const uint8_t *packet;
uint8_t *buf;
-packet = s->io_buffer;
buf = s->io_buffer;
#ifdef DEBUG_IDE_ATAPI
{
int i;
printf("ATAPI limit=0x%x packet:", s->lcyl | (s->hcyl<< 8));
for(i = 0; i< ATAPI_PACKET_SIZE; i++) {
-printf(" %02x", packet[i]);
+printf(" %02x", buf[i]);
}
printf("\n");
}
Acked-by: Stefan Weil
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/11 16:46, Anthony Liguori wrote: > On 04/28/2011 09:38 AM, Jes Sorensen wrote: >> >> Sorry but this is utterly bogus. >> >> The snapshot support as is works fine, and the command is in the >> monitor. We should expose it in QMP as well. > > It went in for the monitor because it was considered an imperfect > command so we held up the QMP side because we wanted a better interface. I am not sure who is included in the 'we' here. > The current command does: > 1) Create new image backing to current image > 2) Flush outstanding I/O to old image > 3) Close current image > 4) Reopen newly created image > 5) Go > Operations (1) and (2) are very synchronous operations. (4) can be too. > We really should have a bdrv_aio_snapshot() function that implements > the logic for at least (2) in an asynchronous fashion. > > That sort of interface is going to affect how we expose things in QMP. > As from a QMP perspective, we're going to do something like: > > a) start snapshot > b) query snapshot progress > c) receive notification of snapshot completion > d) flip over image Sorry this is inherently broken. The management tool should not be keeping state in this process. I agree an async interface would be nice, but the above process is plain wrong. The async snapshot process needs to be doing the exact same as in the current implementation, the main difference is that it would be running asynchronously and that QMP would be able to query the state of it. You definitely do *not* want the management tool to launch the snapshot process, and then do the flip by the management tool later. It should all happen as part of the original command. Being able to query it while it is progressing is a different story. The one reason why this isn't all that big an issue in the first place, is that in the normal usage case, a user will run a guest agent which freezes the guest file systems during the snapshot process, so the fact that the existing command is synchronous pretty much disappears in the noise. > And of course, this needs to be carefully thought through for race > conditions. In the current command, what happens if you get a crash > between (2) and (3)? There's no way for the management tools to know > that we didn't finish flushing writes. How does the management tool > know that (1) didn't fail mid way through resulting in a corrupted image? There is no issue here, you have the exact same problem if you get a crash during d) in your example. It is the same with the existing command, the crash is only an issue if it happens right in the middle of the switch over. Until then, only the original image remains valid. Cheers, Jes
Re: [Qemu-devel] [PATCH v2 1/1] Add QMP bits for blockdev-snapshot-sync.
On 04/28/2011 09:57 AM, Jes Sorensen wrote: On 04/28/11 16:46, Anthony Liguori wrote: On 04/28/2011 09:38 AM, Jes Sorensen wrote: Sorry but this is utterly bogus. The snapshot support as is works fine, and the command is in the monitor. We should expose it in QMP as well. It went in for the monitor because it was considered an imperfect command so we held up the QMP side because we wanted a better interface. I am not sure who is included in the 'we' here. The current command does: 1) Create new image backing to current image 2) Flush outstanding I/O to old image 3) Close current image 4) Reopen newly created image 5) Go Operations (1) and (2) are very synchronous operations. (4) can be too. We really should have a bdrv_aio_snapshot() function that implements the logic for at least (2) in an asynchronous fashion. That sort of interface is going to affect how we expose things in QMP. As from a QMP perspective, we're going to do something like: a) start snapshot b) query snapshot progress c) receive notification of snapshot completion d) flip over image Sorry this is inherently broken. The management tool should not be keeping state in this process. I agree an async interface would be nice, but the above process is plain wrong. The async snapshot process needs to be doing the exact same as in the current implementation, the main difference is that it would be running asynchronously and that QMP would be able to query the state of it. No, the command does too many things and as such, makes it impossible for a management tool to gracefully recover. And of course, this needs to be carefully thought through for race conditions. In the current command, what happens if you get a crash between (2) and (3)? There's no way for the management tools to know that we didn't finish flushing writes. How does the management tool know that (1) didn't fail mid way through resulting in a corrupted image? There is no issue here, you have the exact same problem if you get a crash during d) in your example. It is the same with the existing command, the crash is only an issue if it happens right in the middle of the switch over. Until then, only the original image remains valid. But the new image is always valid once it's been created as pending writes are lost no matter what in a hard power failure. That suggests the following flow: 1) Create new image with a backing file 2) Completion ACK At this stage, the management tool should update it's internal state to point to the new image. 3) Begin switch over to new image 4) Switch over image. 5) Receive notification when it's complete If (4) is happening asynchronously, things get kind of complicated. You can either wait for things to quiesce on their own or you can queue pending requests. It's unclear to me what the right strategy is or if there's a mixed strategy that's needed. I think it makes sense to treat 3/4 as a command with (5) being an event notification. But combining 1-5 in a single interface creates a command that while convenient on the command line, is not usable for a robust management tool. Regards, Anthony Liguori Cheers, Jes
Re: [Qemu-devel] [PATCH] NBD: Convert the NBD driver to use the AIO interface.
Hi again Kevin, all,
Thanks for applying the first four patches, and apologies for taking so
long to get back to you. I've found the time to take your comments
on-board and re-do the last patch, + the string-leak patch; I'll send
them on shortly, I just wanted to make a few notes on yours, first.
> > + * If there'an unrecoverable error reading from the socket, [...]
>
> Something's missing here? ;-)
Documentation on how reconnections happen ;) - big fat TODO.
[...]
>
> > +free_aio_req(s, a);
> > +}
> > +nbd_finish_aiocb(acb);
> > +}
> > +
> > +nbd_teardown_connection(s);
>
> And now there's no way to get the disk back to life without a reboot? Do
> I understand correctly that now trying to access the disk will always
> return -EBADF?
That's right - this is the case with the current code too. I want to put
the reconnection logic into a separate patch, but haven't actually
written it yet.
> > +static void nbd_aio_read_response(void *opaque)
> > +{
> > +BDRVNBDState *s = opaque;
> > +AIOReq *aio_req = NULL;
> > +NBDAIOCB *acb;
> > +NBDReply rsp;
> > +
> > +size_t total;
> > +ssize_t ret;
> > +int rest;
> > +
> > +if (s->current_req == NULL && QTAILQ_EMPTY(&s->reqs_for_reply_head)) {
> > +return;
> > +}
> > +
> > +/* Build our nbd_reply object if we've got it */
> > +if (s->current_req && (s->nbd_rsp_offset == sizeof(NBDReply))) {
> > +nbd_buf_to_reply((uint8_t *)&s->nbd_rsp_buf, &rsp);
> > +}
> > +
> > +if (s->current_req == NULL) {
> > +/* Try to read a header */
>
> Factor this whole block out in its own function?
I wasn't sure here if you meant the preceding, or following, code - I
guessed the latter, anyway, as that made the most sense. Done in the
following patch.
> > +QEMUIOVector hdr;
> > +qemu_iovec_init(&hdr, 1);
> > +qemu_iovec_add(&hdr, ((&s->nbd_rsp_buf) + s->nbd_rsp_offset),
> > + (sizeof(NBDReply) - s->nbd_rsp_offset));
> > +ret = readv(s->sock, hdr.iov, hdr.niov);
> > +qemu_iovec_destroy(&hdr);
> > +
> > +if (ret == -1) {
> > + nbd_handle_io_err(s, aio_req, socket_error());
> > + return;
> > +}
[...]
> > +ssize_t nbd_wr_aio(int fd, QEMUIOVector *qiov, size_t len, off_t offset,
> > + bool do_read)
>
> Isn't this name misleading? The function is completely synchronous. It
> just happens not to block because it's only called when the socket is ready.
As far as I understand it, a read/write may still block (or return
EAGAIN, EWOULDBLOCK, EINTR, etc) even if select has marked the socket as
ready for reads or writes. So it's aio, because we don't loop on those
errors. Anyway, I've renamed it to nbd_qiov_wr, since that's just as
relevant.
[Qemu-devel] [PATCH 1/2] NBD: Avoid leaking a couple of strings when the NBD device is closed
From: Nick Thomas
Signed-off-by: Nick Thomas
---
block/nbd.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 1d6b225..7a52f62 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -239,6 +239,10 @@ static int nbd_write(BlockDriverState *bs, int64_t
sector_num,
static void nbd_close(BlockDriverState *bs)
{
+BDRVNBDState *s = bs->opaque;
+qemu_free(s->export_name);
+qemu_free(s->host_spec);
+
nbd_teardown_connection(bs);
}
--
1.7.0.4
[Qemu-devel] [PATCH 2/2] NBD: Convert the NBD driver to use the AIO interface.
From: Nick Thomas
This preserves the previous behaviour where the NBD server is
unavailable or goes away during guest execution, but switches the
NBD backend to present the AIO interface instead of the sync IO
interface.
We also split read & write requests into 1 MiB blocks (minus header).
This is a hard limit in various NBD servers (including qemu-nbd), but
never seemed to come up with the previous backend code.
All IO except setup and teardown is asynchronous, and we (in theory)
handle canceled requests properly too.
Automatic reconnect logic is TODO, and will be coming in a future
patch.
We register the nbd_aio_write_request callback only whilst there are
outstanding aio_reqs that haven't had an NBD request sent over the
wire for them yet. Whenever the send queue is emptied, we unregister
the callback - this avoids a tight loop in vl.c
Signed-off-by: Nick Thomas
---
block/nbd.c | 727 ++-
nbd.c | 74 +--
nbd.h | 13 +-
3 files changed, 732 insertions(+), 82 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 7a52f62..8986ccf 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -34,7 +34,12 @@
#include
#include
-#define EN_OPTSTR ":exportname="
+#define EN_OPTSTR ":exportname="
+#define SECTOR_SIZE 512
+
+/* 1MiB minus header size */
+#define NBD_MAX_READ ((1024*1024) - sizeof(NBDReply))
+#define NBD_MAX_WRITE ((1024*1024) - sizeof(NBDRequest))
/* #define DEBUG_NBD */
@@ -45,17 +50,161 @@
#define logout(fmt, ...) ((void)0)
#endif
-typedef struct BDRVNBDState {
+/*
+ * Here's how the I/O works.
+ * qemu creates a BDRVNBDState for us, which is the context for all reads
+ * and writes.
+ *
+ * nbd_open is called to connect to the NBD server and set up an on-read
+ * handler (nbd_aio_read_response)
+ *
+ * nbd_aio_readv/writev, called by qemu, create an NBDAIOCB (representing the
+ * I/O request to qemu).
+ * For read requests, read/writev creates a single AIOReq containing the NBD
+ * header. For write requests, 1 or more AIOReqs are created, containing the
+ * NBD header and the write data. These are pushed to reqs_to_send_head in the
+ * BDRVNBDState and the list in the NBDAIOCB. We then register a write request
+ * callback, which results in nbd_aio_write_request being called from the
+ * select() in vlc:main_loop_wait
+ *
+ * Each time nbd_aio_write_request is called, it gets the first AIOReq in the
+ * reqs_to_send_head and writes the data to the socket.
+ * If this results in the whole AIOReq being written to the socket, it moves
+ * the AIOReq to the reqs_for_reply_head in the BDRVNBDState. If the AIOReq
+ * isn't finished, then it's left where it is. to have more of it written
+ * next time. Before exiting, we unregister the write request handler if the
+ * reqs_to_send_head queue is empty. This avoids a tight loop around the
+ * aforementioned select (since the socket is almost always ready for writing).
+ *
+ * If there's an unrecoverable error writing to the socket, we disconnect and
+ * return the entire acb with that error.
+ *
+ * Each nbd_aio_read_response, we check the BDRVNBDState's current_req
attribute
+ * to see if we're in the middle of a read. If not, we read a header's worth of
+ * data, then try to find an AIOReq in the reqs_for_reply_head. If we don't
+ * find one, that is very odd, so we teardown the connection and return an
+ * I/O error.
+ *
+ * Once we have our AIOReq, we remove it from reqs_for_reply_head and put it
+ * in the current_req attribute, then read from the socket to the buffer (if
+ * needed). If that completes the AIOReq, we clear the current_req attribute
+ * and deallocate the AIOReq.
+ * - If the AIOReq is complete, and that's the last one for the NBDAIOCB, we
+ * call the 'done' callback' and return.
+ * - If the AIOReq isn't complete, we just return. It'll be completed in
+ * future callbacks, since it's now the current_req
+ * - If there's an unrecoverable error reading from the socket (EBADF, say).
+ * we invalidate the AIOReq and teardown the connection.
+ *
+ * Currently, there is no reconnection logic, meaning that once the connection
+ * has been broken or an error condition has occured, the only way to regain
+ * functionality is to call nbd_close() and nbd_open - disconnect & reconnect
+ * the drive, or restart the whole process. There's plenty of scope to improve
+ * upon that.
+ */
+
+typedef struct NBDAIOCB NBDAIOCB;
+typedef struct BDRVNBDState BDRVNBDState;
+
+static int nbd_establish_connection(BDRVNBDState *s);
+static void nbd_teardown_connection(BDRVNBDState *s);
+static void nbd_register_write_request_handler(BDRVNBDState *s);
+static void nbd_unregister_write_request_handler(BDRVNBDState *s);
+
+typedef struct AIOReq {
+NBDAIOCB *aiocb; /* Which QEMU operation this belongs to */
+
+/* Where on the NBDAIOCB's iov does this request start? */
+off_t iov_offset;
+
+/* The NBD request header pertaining
[Qemu-devel] [PATCH 04/18] Fix typo in comment (colum -> column)
Signed-off-by: Stefan Weil
---
hw/ssd0303.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/ssd0303.c b/hw/ssd0303.c
index 108c068..b39e259 100644
--- a/hw/ssd0303.c
+++ b/hw/ssd0303.c
@@ -93,7 +93,7 @@ static int ssd0303_send(i2c_slave *i2c, uint8_t data)
DPRINTF("cmd 0x%02x\n", data);
s->mode = SSD0303_IDLE;
switch (data) {
-case 0x00 ... 0x0f: /* Set lower colum address. */
+case 0x00 ... 0x0f: /* Set lower column address. */
s->col = (s->col & 0xf0) | (data & 0xf);
break;
case 0x10 ... 0x20: /* Set higher column address. */
--
1.7.2.5
[Qemu-devel] [PATCH 10/18] Fix typos in comments (existance -> existence)
Signed-off-by: Stefan Weil
---
libcacard/vscard_common.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libcacard/vscard_common.h b/libcacard/vscard_common.h
index bebd52d..609ae98 100644
--- a/libcacard/vscard_common.h
+++ b/libcacard/vscard_common.h
@@ -153,7 +153,7 @@ typedef struct VSCMsgCardRemove {
/*
* VSCMsgAPDU Client <-> Host
- * Main reason of existance. Transfer a single APDU in either direction.
+ * Main reason of existence. Transfer a single APDU in either direction.
*/
typedef struct VSCMsgAPDU {
uint8_tdata[0];
--
1.7.2.5
[Qemu-devel] [PATCH 11/18] Fix typos in comments (interupt -> interrupt)
Signed-off-by: Stefan Weil
---
cpu-exec.c |2 +-
hw/mst_fpga.c|2 +-
hw/pl031.c |2 +-
hw/pl061.c |4 ++--
target-mips/translate_init.c |2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 395cd8c..2cdcdc5 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -569,7 +569,7 @@ int cpu_exec(CPUState *env1)
next_tb = 0;
}
#endif
- /* Don't use the cached interupt_request value,
+ /* Don't use the cached interrupt_request value,
do_interrupt may have updated the EXITTB flag. */
if (env->interrupt_request & CPU_INTERRUPT_EXITTB) {
env->interrupt_request &= ~CPU_INTERRUPT_EXITTB;
diff --git a/hw/mst_fpga.c b/hw/mst_fpga.c
index a04355c..4e47574 100644
--- a/hw/mst_fpga.c
+++ b/hw/mst_fpga.c
@@ -154,7 +154,7 @@ mst_fpga_writeb(void *opaque, target_phys_addr_t addr,
uint32_t value)
case MST_MSCRD:
s->mscrd = value;
break;
- case MST_INTMSKENA: /* Mask interupt */
+ case MST_INTMSKENA: /* Mask interrupt */
s->intmskena = (value & 0xFEEFF);
qemu_set_irq(s->parent, s->intsetclr & s->intmskena);
break;
diff --git a/hw/pl031.c b/hw/pl031.c
index 8c2f9d0..017a313 100644
--- a/hw/pl031.c
+++ b/hw/pl031.c
@@ -161,7 +161,7 @@ static void pl031_write(void * opaque, target_phys_addr_t
offset,
pl031_update(s);
break;
case RTC_ICR:
-/* The PL031 documentation (DDI0224B) states that the interupt is
+/* The PL031 documentation (DDI0224B) states that the interrupt is
cleared when bit 0 of the written value is set. However the
arm926e documentation (DDI0287B) states that the interrupt is
cleared when any value is written. */
diff --git a/hw/pl061.c b/hw/pl061.c
index 2e181f8..372dfc2 100644
--- a/hw/pl061.c
+++ b/hw/pl061.c
@@ -98,7 +98,7 @@ static uint32_t pl061_read(void *opaque, target_phys_addr_t
offset)
return s->isense;
case 0x408: /* Interrupt both edges */
return s->ibe;
-case 0x40c: /* Interupt event */
+case 0x40c: /* Interrupt event */
return s->iev;
case 0x410: /* Interrupt mask */
return s->im;
@@ -156,7 +156,7 @@ static void pl061_write(void *opaque, target_phys_addr_t
offset,
case 0x408: /* Interrupt both edges */
s->ibe = value;
break;
-case 0x40c: /* Interupt event */
+case 0x40c: /* Interrupt event */
s->iev = value;
break;
case 0x410: /* Interrupt mask */
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index 590e092..d980216 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -38,7 +38,7 @@
((1 << CP0C2_M))
/* No config4, no DSP ASE, no large physaddr (PABITS),
- no external interrupt controller, no vectored interupts,
+ no external interrupt controller, no vectored interrupts,
no 1kb pages, no SmartMIPS ASE, no trace logic */
#define MIPS_CONFIG3 \
((0 << CP0C3_M) | (0 << CP0C3_DSPP) | (0 << CP0C3_LPA) | \
--
1.7.2.5
[Qemu-devel] [PATCH 01/18] Fix typos in comments (dependancy -> dependency)
Signed-off-by: Stefan Weil --- Changelog |2 +- Makefile.objs |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Changelog b/Changelog index 152feaa..1c41e14 100644 --- a/Changelog +++ b/Changelog @@ -525,7 +525,7 @@ version 0.1.5: - ppc64 support + personality() patch (Rusty Russell) - first Alpha CPU patches (Falk Hueffner) - - removed bfd.h dependancy + - removed bfd.h dependency - fixed shrd, shld, idivl and divl on PowerPC. - fixed buggy glibc PowerPC rint() function (test-i386 passes now on PowerPC). diff --git a/Makefile.objs b/Makefile.objs index 0cbff4d..e387ab9 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -335,7 +335,7 @@ trace-dtrace.h: trace-dtrace.dtrace $(call quiet-command,dtrace -o $@ -h -s $<, " GEN trace-dtrace.h") # Normal practice is to name DTrace probe file with a '.d' extension -# but that gets picked up by QEMU's Makefile as an external dependancy +# but that gets picked up by QEMU's Makefile as an external dependency # rule file. So we use '.dtrace' instead trace-dtrace.dtrace: trace-dtrace.dtrace-timestamp trace-dtrace.dtrace-timestamp: $(SRC_PATH)/trace-events config-host.mak -- 1.7.2.5
[Qemu-devel] [PATCH 03/18] Fix typos in comments (accessable -> accessible, priveleged -> privileged)
Signed-off-by: Stefan Weil
---
hw/sh7750_regs.h |6 +++---
target-cris/cpu.h |2 +-
tests/test-mmap.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/sh7750_regs.h b/hw/sh7750_regs.h
index 5a23a2c..6ec13ab 100644
--- a/hw/sh7750_regs.h
+++ b/hw/sh7750_regs.h
@@ -23,9 +23,9 @@
* All register has 2 addresses: in 0xff00 - 0x (P4 address) and
* in 0x1f00 - 0x1fff (area 7 address)
*/
-#define SH7750_P4_BASE 0xff00/* Accessable only in
- priveleged mode */
-#define SH7750_A7_BASE 0x1f00/* Accessable only using TLB */
+#define SH7750_P4_BASE 0xff00/* Accessible only in
+ privileged mode */
+#define SH7750_A7_BASE 0x1f00/* Accessible only using TLB */
#define SH7750_P4_REG32(ofs) (SH7750_P4_BASE + (ofs))
#define SH7750_A7_REG32(ofs) (SH7750_A7_BASE + (ofs))
diff --git a/target-cris/cpu.h b/target-cris/cpu.h
index d908775..4a9032b 100644
--- a/target-cris/cpu.h
+++ b/target-cris/cpu.h
@@ -101,7 +101,7 @@ typedef struct CPUCRISState {
/* P0 - P15 are referred to as special registers in the docs. */
uint32_t pregs[16];
- /* Pseudo register for the PC. Not directly accessable on CRIS. */
+ /* Pseudo register for the PC. Not directly accessible on CRIS. */
uint32_t pc;
/* Pseudo register for the kernel stack. */
diff --git a/tests/test-mmap.c b/tests/test-mmap.c
index c578e25..c67174a 100644
--- a/tests/test-mmap.c
+++ b/tests/test-mmap.c
@@ -322,7 +322,7 @@ void check_file_unfixed_eof_mmaps(void)
fail_unless (p1[(test_fsize & pagemask) / sizeof *p1 - 1]
== ((test_fsize - sizeof *p1) / sizeof *p1));
- /* Verify that the end of page is accessable and zeroed. */
+ /* Verify that the end of page is accessible and zeroed. */
cp = (void *) p1;
fail_unless (cp[pagesize - 4] == 0);
munmap (p1, pagesize);
@@ -365,7 +365,7 @@ void check_file_fixed_eof_mmaps(void)
fail_unless (p1[(test_fsize & pagemask) / sizeof *p1 - 1]
== ((test_fsize - sizeof *p1) / sizeof *p1));
- /* Verify that the end of page is accessable and zeroed. */
+ /* Verify that the end of page is accessible and zeroed. */
cp = (void *)p1;
fail_unless (cp[pagesize - 4] == 0);
munmap (p1, pagesize);
--
1.7.2.5
[Qemu-devel] [PATCH 12/18] Fix typos in comments (instanciation -> instantiation)
Signed-off-by: Stefan Weil
---
hw/ppc4xx_devs.c|2 +-
target-ppc/translate_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ppc4xx_devs.c b/hw/ppc4xx_devs.c
index 7f9ed17..68bdfaa 100644
--- a/hw/ppc4xx_devs.c
+++ b/hw/ppc4xx_devs.c
@@ -38,7 +38,7 @@
#endif
/*/
-/* Generic PowerPC 4xx processor instanciation */
+/* Generic PowerPC 4xx processor instantiation */
CPUState *ppc4xx_init (const char *cpu_model,
clk_setup_t *cpu_clk, clk_setup_t *tb_clk,
uint32_t sysclk)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index e2a83c5..ed291c3 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -9049,7 +9049,7 @@ static const ppc_def_t ppc_defs[] = {
};
/*/
-/* Generic CPU instanciation routine */
+/* Generic CPU instantiation routine */
static void init_ppc_proc (CPUPPCState *env, const ppc_def_t *def)
{
#if !defined(CONFIG_USER_ONLY)
--
1.7.2.5
[Qemu-devel] [PATCH 09/18] Fix typos in comments (imediately -> immediately)
Signed-off-by: Stefan Weil
---
hw/lan9118.c |2 +-
hw/syborg_serial.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/lan9118.c b/hw/lan9118.c
index 2dc8d18..4c42fe9 100644
--- a/hw/lan9118.c
+++ b/hw/lan9118.c
@@ -721,7 +721,7 @@ static void do_phy_write(lan9118_state *s, int reg,
uint32_t val)
break;
}
s->phy_control = val & 0x7980;
-/* Complete autonegotiation imediately. */
+/* Complete autonegotiation immediately. */
if (val & 0x1000) {
s->phy_status |= 0x0020;
}
diff --git a/hw/syborg_serial.c b/hw/syborg_serial.c
index df2950f..2ef7175 100644
--- a/hw/syborg_serial.c
+++ b/hw/syborg_serial.c
@@ -126,7 +126,7 @@ static void do_dma_tx(SyborgSerialState *s, uint32_t count)
s->dma_tx_ptr += count;
}
/* QEMU char backends do not have a nonblocking mode, so we transmit all
- the data imediately and the interrupt status will be unchanged. */
+ the data immediately and the interrupt status will be unchanged. */
}
/* Initiate RX DMA, and transfer data from the FIFO. */
--
1.7.2.5
[Qemu-devel] [PATCH 05/18] Fix typo in comment (auxilliary -> auxiliary)
Signed-off-by: Stefan Weil --- hw/pci_regs.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/pci_regs.h b/hw/pci_regs.h index dd0bed4..5a5ab89 100644 --- a/hw/pci_regs.h +++ b/hw/pci_regs.h @@ -223,7 +223,7 @@ #define PCI_PM_CAP_PME_CLOCK 0x0008 /* PME clock required */ #define PCI_PM_CAP_RESERVED0x0010 /* Reserved field */ #define PCI_PM_CAP_DSI0x0020 /* Device specific initialization */ -#define PCI_PM_CAP_AUX_POWER 0x01C0 /* Auxilliary power support mask */ +#define PCI_PM_CAP_AUX_POWER 0x01C0 /* Auxiliary power support mask */ #define PCI_PM_CAP_D1 0x0200 /* D1 power state support */ #define PCI_PM_CAP_D2 0x0400 /* D2 power state support */ #define PCI_PM_CAP_PME0x0800 /* PME pin supported */ -- 1.7.2.5
[Qemu-devel] [PATCH 08/18] Fix typo in comment (dieing -> dying)
Signed-off-by: Stefan Weil --- linux-user/signal.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/linux-user/signal.c b/linux-user/signal.c index ce033e9..6fe086b 100644 --- a/linux-user/signal.c +++ b/linux-user/signal.c @@ -391,7 +391,7 @@ static void QEMU_NORETURN force_sig(int target_sig) target_sig, strsignal(host_sig), "core dumped" ); } -/* The proper exit code for dieing from an uncaught signal is +/* The proper exit code for dying from an uncaught signal is * -. The kernel doesn't allow exit() or _exit() to pass * a negative value. To get the proper exit code we need to * actually die from an uncaught signal. Here the default signal -- 1.7.2.5
[Qemu-devel] [PATCH 17/18] Fix typo in comment (truely -> truly)
Signed-off-by: Stefan Weil --- linux-user/mmap.c |2 +- target-cris/translate_v10.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/linux-user/mmap.c b/linux-user/mmap.c index 0cf22f8..994c02b 100644 --- a/linux-user/mmap.c +++ b/linux-user/mmap.c @@ -354,7 +354,7 @@ abi_ulong mmap_find_vma(abi_ulong start, abi_ulong size) } wrapped = 1; /* Don't actually use 0 when wrapping, instead indicate - that we'd truely like an allocation in low memory. */ + that we'd truly like an allocation in low memory. */ addr = (mmap_min_addr > TARGET_PAGE_SIZE ? TARGET_PAGE_ALIGN(mmap_min_addr) : TARGET_PAGE_SIZE); diff --git a/target-cris/translate_v10.c b/target-cris/translate_v10.c index 41db158..5b14157 100644 --- a/target-cris/translate_v10.c +++ b/target-cris/translate_v10.c @@ -956,7 +956,7 @@ static int dec10_bdap_m(DisasContext *dc, int size) return insn_len; } #endif -/* Now the rest of the modes are truely indirect. */ +/* Now the rest of the modes are truly indirect. */ insn_len += dec10_prep_move_m(dc, 1, size, cpu_PR[PR_PREFIX]); tcg_gen_add_tl(cpu_PR[PR_PREFIX], cpu_PR[PR_PREFIX], cpu_R[rd]); cris_set_prefix(dc); -- 1.7.2.5
[Qemu-devel] [Bug 458521] Re: kvm crash when using virtio for network, hardy guest
@John, what is the status of this bug on Hardy/linux? ** Changed in: qemu Status: In Progress => Fix Released ** Changed in: linux (Ubuntu Hardy) Status: Triaged => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/458521 Title: kvm crash when using virtio for network, hardy guest Status in QEMU: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “linux” source package in Hardy: Incomplete Status in “qemu-kvm” source package in Hardy: Invalid Status in “linux” source package in Karmic: Fix Released Status in “qemu-kvm” source package in Karmic: Fix Released Bug description: Binary package hint: kvm I was running a kvm host with 5 virtual machines using jaunty. 1 running centos 5.4, 3 running karmic and 1 running hardy. I upgraded the host to karmic to test it and one of my virtual machines(the vm with hardy) crashs after some seconds of boot! I stack traced the kvm process and found a "virtio-net truncating packet" before process crash. No error in any log file. The VM just crash. I changed the model of network interface(the disk is still virtio) in VM.xml to rtl8139, redefined and started. The problem goes away. I don't know if it's a kvm bug or libvirt(regarding the bridge network) bug but definitely is a bug. All other VMs are running OK with virtio for both network and disk. === Karmic Release Notes: KVM Guest Crashes when Guest is Hardy and using Virtio Networking Ubuntu 8.04 LTS (Hardy) KVM guests using virtio networking may crash, when running on top of Ubuntu 9.10 (Karmic) hosts. As a workaround, such guests should use either e1000 or rtl839 as the networking model. A fix for the bug is currently in progress and should be addressed in an update to the qemu-kvm package in Karmic. === === SRU Justification This bug is a regression from the kvm-84 package in 9.04. Karmic users hosting 8.04 KVM guests and using virtio networking *will* crash their VM when the network connection is saturated. As the virtual machine crashes without sync buffers, there could very well be data lost in the guest filesystem or memory. I have posted the patch for review, and acked upstream: * http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg02495.html I am bundling this fix with two other minor fixes, for Bug #452323 and Bug #453441. TEST CASE: 1) Download and uncompress * http://rookery.canonical.com/~kirkland/hardy.img.bz2 2) Download a bridged networking script * http://rookery.canonical.com/~kirkland/bridge.sh 3) Start the vm with virtio and bridged networking * sudo /usr/bin/kvm -m 512 -net nic,model=virtio -net tap,script=bridge.sh -drive file=hardy.img,if=virtio,index=0,boot=on 4) The VM's username and password are both "ubuntu". 5) In the guest, have nc listen on a port * nc -lp 1234 > /dev/null 6) On your host, flood the guest with network traffic on that port * cat /dev/urandom | nc -w 3 guest_ip 1234 7) Without this fix, the guest will crash immediately, saying: * virtio-net truncating packet 8) With the fix, you will be able to send the guest with data over the virtio network ad nauseum. I get about 6MB/s throughput. ===
[Qemu-devel] [PATCH 16/18] Fix typo in comment (responsiblity -> responsibility)
Signed-off-by: Stefan Weil --- hw/pcie_aer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/pcie_aer.c b/hw/pcie_aer.c index 0c4e8a5..f08d3c7 100644 --- a/hw/pcie_aer.c +++ b/hw/pcie_aer.c @@ -612,7 +612,7 @@ static bool pcie_aer_inject_uncor_error(PCIEAERInject *inj, bool is_fatal) /* * non-Function specific error must be recorded in all functions. * It is the responsibility of the caller of this function. - * It is also caller's responsiblity to determine which function should + * It is also caller's responsibility to determine which function should * report the rerror. * * 6.2.4 Error Logging -- 1.7.2.5
[Qemu-devel] [PATCH 15/18] Fix typo in comment (relevent -> relevant)
Signed-off-by: Stefan Weil --- hppa-dis.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hppa-dis.c b/hppa-dis.c index 49f99c8..a5760a9 100644 --- a/hppa-dis.c +++ b/hppa-dis.c @@ -1645,7 +1645,7 @@ static const char *const fp_reg_names[] = typedef unsigned int CORE_ADDR; -/* Get at various relevent fields of an instruction word. */ +/* Get at various relevant fields of an instruction word. */ #define MASK_5 0x1f #define MASK_10 0x3ff -- 1.7.2.5
[Qemu-devel] [PATCH 13/18] Fix typos in comments (neccessary -> necessary)
Signed-off-by: Stefan Weil
---
bsd-user/qemu.h|2 +-
linux-user/qemu.h |2 +-
target-arm/translate.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index e343894..1ba2d08 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -323,7 +323,7 @@ abi_long copy_from_user(void *hptr, abi_ulong gaddr, size_t
len);
abi_long copy_to_user(abi_ulong gaddr, void *hptr, size_t len);
/* Functions for accessing guest memory. The tget and tput functions
- read/write single values, byteswapping as neccessary. The lock_user
+ read/write single values, byteswapping as necessary. The lock_user
gets a pointer to a contiguous area of guest memory, but does not perform
and byteswapping. lock_user may return either a pointer to the guest
memory, or a temporary buffer. */
diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index f522f5e..237386c 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -379,7 +379,7 @@ abi_long copy_from_user(void *hptr, abi_ulong gaddr, size_t
len);
abi_long copy_to_user(abi_ulong gaddr, void *hptr, size_t len);
/* Functions for accessing guest memory. The tget and tput functions
- read/write single values, byteswapping as neccessary. The lock_user
+ read/write single values, byteswapping as necessary. The lock_user
gets a pointer to a contiguous area of guest memory, but does not perform
and byteswapping. lock_user may return either a pointer to the guest
memory, or a temporary buffer. */
diff --git a/target-arm/translate.c b/target-arm/translate.c
index a1af436..3119137 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -7348,7 +7348,7 @@ static void disas_arm_insn(CPUState * env, DisasContext
*s)
} else if ((insn & 0x03e0) == 0x0060) {
tmp = load_reg(s, rm);
shift = (insn >> 10) & 3;
-/* ??? In many cases it's not neccessary to do a
+/* ??? In many cases it's not necessary to do a
rotate, a shift is sufficient. */
if (shift != 0)
tcg_gen_rotri_i32(tmp, tmp, shift * 8);
@@ -8139,7 +8139,7 @@ static int disas_thumb2_insn(CPUState *env, DisasContext
*s, uint16_t insn_hw1)
case 1: /* Sign/zero extend. */
tmp = load_reg(s, rm);
shift = (insn >> 4) & 3;
-/* ??? In many cases it's not neccessary to do a
+/* ??? In many cases it's not necessary to do a
rotate, a shift is sufficient. */
if (shift != 0)
tcg_gen_rotri_i32(tmp, tmp, shift * 8);
--
1.7.2.5
[Qemu-devel] [PATCH 14/18] Fix typos in comments and code (occured -> occurred and related)
The code changed here is an unused data type name (evt_flush_occurred).
Signed-off-by: Stefan Weil
---
block.c|2 +-
block/qcow2-refcount.c |2 +-
cpu-all.h |2 +-
cpu-exec.c |2 +-
hw/bt.h|2 +-
hw/pcie.c |2 +-
hw/pcie.h |2 +-
hw/pflash_cfi02.c |2 +-
target-arm/translate.c |6 +++---
target-m68k/helper.c |2 +-
10 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index f731c7a..e346c1e 100644
--- a/block.c
+++ b/block.c
@@ -747,7 +747,7 @@ DeviceState *bdrv_get_attached(BlockDriverState *bs)
* Run consistency checks on an image
*
* Returns 0 if the check could be completed (it doesn't mean that the image is
- * free of errors) or -errno when an internal error occured. The results of the
+ * free of errors) or -errno when an internal error occurred. The results of
the
* check are stored in res.
*/
int bdrv_check(BlockDriverState *bs, BdrvCheckResult *res)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 915d85a..d62dc1c 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -1063,7 +1063,7 @@ fail:
* Checks an image for refcount consistency.
*
* Returns 0 if no errors are found, the number of errors in case the image is
- * detected as corrupted, and -errno when an internal error occured.
+ * detected as corrupted, and -errno when an internal error occurred.
*/
int qcow2_check_refcounts(BlockDriverState *bs, BdrvCheckResult *res)
{
diff --git a/cpu-all.h b/cpu-all.h
index 0bae6df..7fd0a50 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -792,7 +792,7 @@ extern CPUState *cpu_single_env;
#define CPU_INTERRUPT_FIQ0x10 /* Fast interrupt pending. */
#define CPU_INTERRUPT_HALT 0x20 /* CPU halt wanted */
#define CPU_INTERRUPT_SMI0x40 /* (x86 only) SMI interrupt pending */
-#define CPU_INTERRUPT_DEBUG 0x80 /* Debug event occured. */
+#define CPU_INTERRUPT_DEBUG 0x80 /* Debug event occurred. */
#define CPU_INTERRUPT_VIRQ 0x100 /* virtual interrupt pending. */
#define CPU_INTERRUPT_NMI0x200 /* NMI pending. */
#define CPU_INTERRUPT_INIT 0x400 /* INIT pending. */
diff --git a/cpu-exec.c b/cpu-exec.c
index 2cdcdc5..1b20f7b 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -509,7 +509,7 @@ int cpu_exec(CPUState *env1)
jump normally, then does the exception return when the
CPU tries to execute code at the magic address.
This will cause the magic PC value to be pushed to
- the stack if an interrupt occured at the wrong time.
+ the stack if an interrupt occurred at the wrong time.
We avoid this by disabling interrupts when
pc contains a magic address. */
if (interrupt_request & CPU_INTERRUPT_HARD
diff --git a/hw/bt.h b/hw/bt.h
index 4a702ad..3797254 100644
--- a/hw/bt.h
+++ b/hw/bt.h
@@ -1441,7 +1441,7 @@ typedef struct {
#define EVT_FLUSH_OCCURRED 0x11
typedef struct {
uint16_t handle;
-} __attribute__ ((packed)) evt_flush_occured;
+} __attribute__ ((packed)) evt_flush_occurred;
#define EVT_FLUSH_OCCURRED_SIZE 2
#define EVT_ROLE_CHANGE0x12
diff --git a/hw/pcie.c b/hw/pcie.c
index 9de6149..39607bf 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -176,7 +176,7 @@ static void hotplug_event_notify(PCIDevice *dev)
}
/*
- * A PCI Express Hot-Plug Event has occured, so update slot status register
+ * A PCI Express Hot-Plug Event has occurred, so update slot status register
* and notify OS of the event if necessary.
*
* 6.7.3 PCI Express Hot-Plug Events
diff --git a/hw/pcie.h b/hw/pcie.h
index bc909e2..a213fba 100644
--- a/hw/pcie.h
+++ b/hw/pcie.h
@@ -40,7 +40,7 @@ typedef enum {
*
* Not all the bits of slot control register match with the ones of
* slot status. Not some bits of slot status register is used to
- * show status, not to report event occurence.
+ * show status, not to report event occurrence.
* So such bits must be masked out when checking the software
* notification condition.
*/
diff --git a/hw/pflash_cfi02.c b/hw/pflash_cfi02.c
index 14bbc34..8fdafe6 100644
--- a/hw/pflash_cfi02.c
+++ b/hw/pflash_cfi02.c
@@ -367,7 +367,7 @@ static void pflash_write (pflash_t *pfl, target_phys_addr_t
offset,
case 4:
switch (pfl->cmd) {
case 0xA0:
-/* Ignore writes while flash data write is occuring */
+/* Ignore writes while flash data write is occurring */
/* As we suppose write is immediate, this should never happen */
return;
case 0x80:
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 3119137..59190f6 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -1331,7 +1331,7 @@ static inline int gen_iwmmxt_shif
[Qemu-devel] [PATCH 18/18] Fix typos in comment (threshhold -> threshold, mapp -> map)
Signed-off-by: Stefan Weil
---
hw/xilinx_axidma.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xilinx_axidma.c b/hw/xilinx_axidma.c
index e32534f..571a5b0 100644
--- a/hw/xilinx_axidma.c
+++ b/hw/xilinx_axidma.c
@@ -134,10 +134,10 @@ static inline int stream_idle(struct AXIStream *s)
static void stream_reset(struct AXIStream *s)
{
s->regs[R_DMASR] = DMASR_HALTED; /* starts up halted. */
-s->regs[R_DMACR] = 1 << 16; /* Starts with one in compl threshhold. */
+s->regs[R_DMACR] = 1 << 16; /* Starts with one in compl threshold. */
}
-/* Mapp an offset addr into a channel index. */
+/* Map an offset addr into a channel index. */
static inline int streamid_from_addr(target_phys_addr_t addr)
{
int sid;
--
1.7.2.5
[Qemu-devel] [PATCH 06/18] Fix typo in comment (embeded -> embedded)
Signed-off-by: Stefan Weil
---
target-ppc/cpu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 04b1259..e438b17 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -225,7 +225,7 @@ enum {
/* 970FX specific exceptions */
POWERPC_EXCP_SOFTP= 88, /* Soft patch exception */
POWERPC_EXCP_MAINT= 89, /* Maintenance exception */
-/* Freescale embeded cores specific exceptions */
+/* Freescale embedded cores specific exceptions */
POWERPC_EXCP_MEXTBR = 90, /* Maskable external breakpoint */
POWERPC_EXCP_NMEXTBR = 91, /* Non maskable external breakpoint */
POWERPC_EXCP_ITLBE= 92, /* Instruction TLB error */
--
1.7.2.5
[Qemu-devel] [PATCH 07/18] Fix typo in comment (consistant -> consistent)
Signed-off-by: Stefan Weil --- libcacard/vcard_emul_nss.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libcacard/vcard_emul_nss.c b/libcacard/vcard_emul_nss.c index baada52..f3db657 100644 --- a/libcacard/vcard_emul_nss.c +++ b/libcacard/vcard_emul_nss.c @@ -971,7 +971,7 @@ find_blank(const char *str) /* * We really want to use some existing argument parsing library here. That - * would give us a consistant look */ + * would give us a consistent look */ static VCardEmulOptions options; #define READER_STEP 4 -- 1.7.2.5
[Qemu-devel] [PATCH 02/18] Fix typos in comments (accross -> across)
Signed-off-by: Stefan Weil
---
darwin-user/syscall.c |2 +-
target-microblaze/helper.c |2 +-
tcg/tcg.h |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/darwin-user/syscall.c b/darwin-user/syscall.c
index 060acc8..f3cc1f8 100644
--- a/darwin-user/syscall.c
+++ b/darwin-user/syscall.c
@@ -977,7 +977,7 @@ long do_unix_syscall_indirect(void *cpu_env, int num)
#elif TARGET_PPC
{
int i;
-/* XXX: not really needed those regs are volatile accross calls */
+/* XXX: not really needed those regs are volatile across calls */
uint32_t **regs = ((CPUPPCState*)cpu_env)->gpr;
for(i = 11; i > 3; i--)
*regs[i] = *regs[i-1];
diff --git a/target-microblaze/helper.c b/target-microblaze/helper.c
index 5230b52..a623c7b 100644
--- a/target-microblaze/helper.c
+++ b/target-microblaze/helper.c
@@ -117,7 +117,7 @@ void do_interrupt(CPUState *env)
{
uint32_t t;
-/* IMM flag cannot propagate accross a branch and into the dslot. */
+/* IMM flag cannot propagate across a branch and into the dslot. */
assert(!((env->iflags & D_FLAG) && (env->iflags & IMM_FLAG)));
assert(!(env->iflags & (DRTI_FLAG | DRTE_FLAG | DRTB_FLAG)));
/*assert(env->sregs[SR_MSR] & (MSR_EE)); Only for HW exceptions. */
diff --git a/tcg/tcg.h b/tcg/tcg.h
index 3fab8d6..cecef63 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -252,9 +252,9 @@ typedef struct TCGTemp {
unsigned int fixed_reg:1;
unsigned int mem_coherent:1;
unsigned int mem_allocated:1;
-unsigned int temp_local:1; /* If true, the temp is saved accross
+unsigned int temp_local:1; /* If true, the temp is saved across
basic blocks. Otherwise, it is not
- preserved accross basic blocks. */
+ preserved across basic blocks. */
unsigned int temp_allocated:1; /* never used for code gen */
/* index of next free temp of same base type, -1 if end */
int next_free_temp;
--
1.7.2.5
[Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists
It should be possible for guest applications to fstat a file for which they
have a valid file descriptor, even if the file has been removed.
Demonstrated by the code sample below (fstat reports no such file or
directory).
Strangely it seems that reading from a file in this state works fine (and
when both are run, the server receives a different fid for each).
On any other filesystem, the code runs correctly. On our 9p filesystem it
fails.
Many applications (including bash) depend on this working correctly.
I will continue investigating, but any thoughts anyone has on the subject
would be appreciated.
Thanks
Sassan
#include
#include
#include
#include
#include
int main(void)
{
int ret;
struct stat statbuf;
int fd = open("test.txt", O_RDWR | O_CREAT, 0666);
if (fd < 0) {
printf("open failed: %m\n");
return 1;
}
ret = write(fd, "test1\n", 6);
if (ret < 0) {
printf("write1 failed: %m\n");
return 1;
}
ret = unlink("test.txt");
if (ret < 0) {
printf("unlink failed: %m\n");
return 1;
}
ret = fstat(fd, &statbuf);
if (ret < 0) {
printf("fstat failed: %m\n");
return 1;
}
return 0;
}
Re: [Qemu-devel] Bug in virtio-9p when fstatting an fd referring to a file that no longer exists
This thread seems relevant:
http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg09159.html
Unless things have changed, it looks like the problem is in the client
kernel (although note that there isn't support in qemu, even if the client
did send an fid associated with an open file!).
Any thoughts on a workaround for this?
Thanks
Sassan
On 28 April 2011 17:13, Sassan Panahinejad wrote:
> It should be possible for guest applications to fstat a file for which they
> have a valid file descriptor, even if the file has been removed.
> Demonstrated by the code sample below (fstat reports no such file or
> directory).
> Strangely it seems that reading from a file in this state works fine (and
> when both are run, the server receives a different fid for each).
> On any other filesystem, the code runs correctly. On our 9p filesystem it
> fails.
> Many applications (including bash) depend on this working correctly.
> I will continue investigating, but any thoughts anyone has on the subject
> would be appreciated.
>
>
> Thanks
> Sassan
>
>
> #include
> #include
> #include
> #include
> #include
>
>
> int main(void)
> {
> int ret;
> struct stat statbuf;
> int fd = open("test.txt", O_RDWR | O_CREAT, 0666);
> if (fd < 0) {
> printf("open failed: %m\n");
> return 1;
> }
> ret = write(fd, "test1\n", 6);
> if (ret < 0) {
> printf("write1 failed: %m\n");
> return 1;
> }
> ret = unlink("test.txt");
> if (ret < 0) {
> printf("unlink failed: %m\n");
> return 1;
> }
> ret = fstat(fd, &statbuf);
> if (ret < 0) {
> printf("fstat failed: %m\n");
> return 1;
> }
> return 0;
> }
>
[Qemu-devel] [PATCH] virtio-9p: Fix compilation (wrong include statements)
From: Stefan Weil Commit 353ac78d495ef976242abd868f68d78420861c2c moved the files without fixing the include paths. Signed-off-by: Stefan Weil --- hw/9pfs/virtio-9p-debug.c |5 +++-- hw/9pfs/virtio-9p-local.c |3 ++- hw/9pfs/virtio-9p-posix-acl.c |2 +- hw/9pfs/virtio-9p-xattr-user.c |2 +- hw/9pfs/virtio-9p-xattr.c |2 +- hw/9pfs/virtio-9p.c|4 ++-- 6 files changed, 10 insertions(+), 8 deletions(-) diff --git a/hw/9pfs/virtio-9p-debug.c b/hw/9pfs/virtio-9p-debug.c index 6b18842..4636ad5 100644 --- a/hw/9pfs/virtio-9p-debug.c +++ b/hw/9pfs/virtio-9p-debug.c @@ -10,8 +10,9 @@ * the COPYING file in the top-level directory. * */ -#include "virtio.h" -#include "pc.h" + +#include "hw/virtio.h" +#include "hw/pc.h" #include "virtio-9p.h" #include "virtio-9p-debug.h" diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c index 0a015de..3effc39 100644 --- a/hw/9pfs/virtio-9p-local.c +++ b/hw/9pfs/virtio-9p-local.c @@ -10,7 +10,8 @@ * the COPYING file in the top-level directory. * */ -#include "virtio.h" + +#include "hw/virtio.h" #include "virtio-9p.h" #include "virtio-9p-xattr.h" #include diff --git a/hw/9pfs/virtio-9p-posix-acl.c b/hw/9pfs/virtio-9p-posix-acl.c index 575abe8..c0ae9d6 100644 --- a/hw/9pfs/virtio-9p-posix-acl.c +++ b/hw/9pfs/virtio-9p-posix-acl.c @@ -13,7 +13,7 @@ #include #include -#include "virtio.h" +#include "hw/virtio.h" #include "virtio-9p.h" #include "fsdev/file-op-9p.h" #include "virtio-9p-xattr.h" diff --git a/hw/9pfs/virtio-9p-xattr-user.c b/hw/9pfs/virtio-9p-xattr-user.c index bba13ce..c56039c 100644 --- a/hw/9pfs/virtio-9p-xattr-user.c +++ b/hw/9pfs/virtio-9p-xattr-user.c @@ -12,7 +12,7 @@ */ #include -#include "virtio.h" +#include "hw/virtio.h" #include "virtio-9p.h" #include "fsdev/file-op-9p.h" #include "virtio-9p-xattr.h" diff --git a/hw/9pfs/virtio-9p-xattr.c b/hw/9pfs/virtio-9p-xattr.c index 03c3d3f..f08ce6e 100644 --- a/hw/9pfs/virtio-9p-xattr.c +++ b/hw/9pfs/virtio-9p-xattr.c @@ -11,7 +11,7 @@ * */ -#include "virtio.h" +#include "hw/virtio.h" #include "virtio-9p.h" #include "fsdev/file-op-9p.h" #include "virtio-9p-xattr.h" diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c index b5fc52b..ac5a1d0 100644 --- a/hw/9pfs/virtio-9p.c +++ b/hw/9pfs/virtio-9p.c @@ -11,8 +11,8 @@ * */ -#include "virtio.h" -#include "pc.h" +#include "hw/virtio.h" +#include "hw/pc.h" #include "qemu_socket.h" #include "virtio-9p.h" #include "fsdev/qemu-fsdev.h" -- 1.5.6.5
Re: [Qemu-devel] [PULL] Request for Pull
Am 28.04.2011 15:56, schrieb Anthony Liguori: On 04/27/2011 11:16 AM, Venkateswararao Jujjuri wrote: The following changes since commit 661bfc80e876d32da8befe53ba0234d87fc0bcc2: Jan Kiszka (1): pflash: Restore & fix lazy ROMD switching are available in the git repository at: git://repo.or.cz/qemu/aliguori/jvrao.git for-anthony Pulled. Thanks. Regards, Anthony Liguori This pull breaks compilation and linkage of latest QEMU: * Compilation fails because of wrong include paths (caused by moved files). I just sent a patch to fix this issue. * The linker fails for all system emulations without virtio. Example: LINK cris-softmmu/qemu-system-cris ../fsdev/qemu-fsdev.o:(.data+0xc): undefined reference to `local_ops' I could add virtio to all these emulations, but I think a better solution is required. Regards, Stefan Weil
Re: [Qemu-devel] [PATCH] virtio-9p: Fix compilation (wrong include statements)
On 04/28/2011 12:08 PM, Stefan Weil wrote: From: Stefan Weil Commit 353ac78d495ef976242abd868f68d78420861c2c moved the files without fixing the include paths. Signed-off-by: Stefan Weil This is not correct. I think we learned in IRC that the problem is Stefan is using CFLAGS=-g which overrides the CFLAGS append added by this patch. Regards, Anthony Liguori --- hw/9pfs/virtio-9p-debug.c |5 +++-- hw/9pfs/virtio-9p-local.c |3 ++- hw/9pfs/virtio-9p-posix-acl.c |2 +- hw/9pfs/virtio-9p-xattr-user.c |2 +- hw/9pfs/virtio-9p-xattr.c |2 +- hw/9pfs/virtio-9p.c|4 ++-- 6 files changed, 10 insertions(+), 8 deletions(-) diff --git a/hw/9pfs/virtio-9p-debug.c b/hw/9pfs/virtio-9p-debug.c index 6b18842..4636ad5 100644 --- a/hw/9pfs/virtio-9p-debug.c +++ b/hw/9pfs/virtio-9p-debug.c @@ -10,8 +10,9 @@ * the COPYING file in the top-level directory. * */ -#include "virtio.h" -#include "pc.h" + +#include "hw/virtio.h" +#include "hw/pc.h" #include "virtio-9p.h" #include "virtio-9p-debug.h" diff --git a/hw/9pfs/virtio-9p-local.c b/hw/9pfs/virtio-9p-local.c index 0a015de..3effc39 100644 --- a/hw/9pfs/virtio-9p-local.c +++ b/hw/9pfs/virtio-9p-local.c @@ -10,7 +10,8 @@ * the COPYING file in the top-level directory. * */ -#include "virtio.h" + +#include "hw/virtio.h" #include "virtio-9p.h" #include "virtio-9p-xattr.h" #include diff --git a/hw/9pfs/virtio-9p-posix-acl.c b/hw/9pfs/virtio-9p-posix-acl.c index 575abe8..c0ae9d6 100644 --- a/hw/9pfs/virtio-9p-posix-acl.c +++ b/hw/9pfs/virtio-9p-posix-acl.c @@ -13,7 +13,7 @@ #include #include -#include "virtio.h" +#include "hw/virtio.h" #include "virtio-9p.h" #include "fsdev/file-op-9p.h" #include "virtio-9p-xattr.h" diff --git a/hw/9pfs/virtio-9p-xattr-user.c b/hw/9pfs/virtio-9p-xattr-user.c index bba13ce..c56039c 100644 --- a/hw/9pfs/virtio-9p-xattr-user.c +++ b/hw/9pfs/virtio-9p-xattr-user.c @@ -12,7 +12,7 @@ */ #include -#include "virtio.h" +#include "hw/virtio.h" #include "virtio-9p.h" #include "fsdev/file-op-9p.h" #include "virtio-9p-xattr.h" diff --git a/hw/9pfs/virtio-9p-xattr.c b/hw/9pfs/virtio-9p-xattr.c index 03c3d3f..f08ce6e 100644 --- a/hw/9pfs/virtio-9p-xattr.c +++ b/hw/9pfs/virtio-9p-xattr.c @@ -11,7 +11,7 @@ * */ -#include "virtio.h" +#include "hw/virtio.h" #include "virtio-9p.h" #include "fsdev/file-op-9p.h" #include "virtio-9p-xattr.h" diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c index b5fc52b..ac5a1d0 100644 --- a/hw/9pfs/virtio-9p.c +++ b/hw/9pfs/virtio-9p.c @@ -11,8 +11,8 @@ * */ -#include "virtio.h" -#include "pc.h" +#include "hw/virtio.h" +#include "hw/pc.h" #include "qemu_socket.h" #include "virtio-9p.h" #include "fsdev/qemu-fsdev.h"
Re: [Qemu-devel] [PULL] Request for Pull
On 04/28/2011 12:21 PM, Stefan Weil wrote: Am 28.04.2011 15:56, schrieb Anthony Liguori: On 04/27/2011 11:16 AM, Venkateswararao Jujjuri wrote: The following changes since commit 661bfc80e876d32da8befe53ba0234d87fc0bcc2: Jan Kiszka (1): pflash: Restore & fix lazy ROMD switching are available in the git repository at: git://repo.or.cz/qemu/aliguori/jvrao.git for-anthony Pulled. Thanks. Regards, Anthony Liguori This pull breaks compilation and linkage of latest QEMU: * Compilation fails because of wrong include paths (caused by moved files). I just sent a patch to fix this issue. * The linker fails for all system emulations without virtio. Example: LINK cris-softmmu/qemu-system-cris ../fsdev/qemu-fsdev.o:(.data+0xc): undefined reference to `local_ops' The use of CONFIG_REALLY_VIRTFS was wrong in the rename patch. I'll push a fix. Regards, Anthony Liguori I could add virtio to all these emulations, but I think a better solution is required. Regards, Stefan Weil
Re: [Qemu-devel] [PATCH] virtio-9p: Fix compilation (wrong include statements)
Am 28.04.2011 19:39, schrieb Anthony Liguori: On 04/28/2011 12:08 PM, Stefan Weil wrote: From: Stefan Weil Commit 353ac78d495ef976242abd868f68d78420861c2c moved the files without fixing the include paths. Signed-off-by: Stefan Weil This is not correct. I think we learned in IRC that the problem is Stefan is using CFLAGS=-g which overrides the CFLAGS append added by this patch. Regards, Anthony Liguori QEMU Makefiles use QEMU_CFLAGS - setting CFLAGS in Makefile* is wrong, because now users can no longer set their own CFLAGS. The special CFLAGS for virtio should be removed (with my patch applied first). The second best solution would be changing CFLAGS to QEMU_CFLAGS in Makefile.objs and Makefile.target. Regards, Stefan
Re: [Qemu-devel] [PATCH] virtio-9p: Fix compilation (wrong include statements)
On 04/28/2011 12:44 PM, Stefan Weil wrote: Am 28.04.2011 19:39, schrieb Anthony Liguori: On 04/28/2011 12:08 PM, Stefan Weil wrote: From: Stefan Weil Commit 353ac78d495ef976242abd868f68d78420861c2c moved the files without fixing the include paths. Signed-off-by: Stefan Weil This is not correct. I think we learned in IRC that the problem is Stefan is using CFLAGS=-g which overrides the CFLAGS append added by this patch. Regards, Anthony Liguori QEMU Makefiles use QEMU_CFLAGS - setting CFLAGS in Makefile* is wrong, because now users can no longer set their own CFLAGS. Use ./configure --extra-cflags="-g" Regards, Anthony Liguori The special CFLAGS for virtio should be removed (with my patch applied first). The second best solution would be changing CFLAGS to QEMU_CFLAGS in Makefile.objs and Makefile.target. Regards, Stefan
