[Qemu-devel] [PATCH] Re: Tracing backends : Fix for building with --prefix
This patch is a minor fix over Stefan's tracing framework, to enable compilation when the build directory is different from source. Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com --- Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index a9f79a9..ef4ae55 100644 --- a/Makefile +++ b/Makefile @@ -130,10 +130,10 @@ bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS) iov.o: iov.c iov.h -trace.h: trace-events +trace.h: $(SRC_PATH)/trace-events $(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -h $ $@, GEN $@) -trace.c: trace-events +trace.c: $(SRC_PATH)/trace-events $(call quiet-command,sh $(SRC_PATH)/tracetool --$(TRACE_BACKEND) -c $ $@, GEN $@) trace.o: trace.c -- 1.6.2.5 -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
[Qemu-devel] [PATCH 0/3] Monitor commands for 'simple' trace backend
This patchset is based on Stefan's trace framework: ( http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg02407.html ) This adds the following monitor commands for the 'simple' backend: - trace : to view current contents of the trace buffer - info tracepoints : to view all available tracepoints and their state. - tracepoint NAME on|off: to enable/disable the logging of data from tracepoint 'NAME'. -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
[Qemu-devel] [PATCH 1/3] export tdb_hash()
This exports tdb_hash() for use by tracing framework.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
qdict.c |2 +-
qdict.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/qdict.c b/qdict.c
index 175bc17..5261872 100644
--- a/qdict.c
+++ b/qdict.c
@@ -56,7 +56,7 @@ QDict *qobject_to_qdict(const QObject *obj)
* tdb_hash(): based on the hash agorithm from gdbm, via tdb
* (from module-init-tools)
*/
-static unsigned int tdb_hash(const char *name)
+unsigned int tdb_hash(const char *name)
{
unsigned value;/* Used to compute the hash value. */
unsigned i; /* Used to cycle through random values. */
diff --git a/qdict.h b/qdict.h
index 5e5902c..d221c18 100644
--- a/qdict.h
+++ b/qdict.h
@@ -59,4 +59,6 @@ int64_t qdict_get_try_int(const QDict *qdict, const char *key,
int64_t err_value);
const char *qdict_get_try_str(const QDict *qdict, const char *key);
+/* Export tdb_hash() for use by trace framework */
+unsigned int tdb_hash(const char *name);
#endif /* QDICT_H */
--
1.6.2.5
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
[Qemu-devel] [PATCH 2/3] Monitor command 'trace'
This introduces the monitor command 'trace' to read current contents of
trace buffer.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
configure |3 +++
monitor.c |3 +++
qemu-monitor.hx | 16
simpletrace.c | 15 +++
tracetool |4
5 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 675d0fc..56af8dd 100755
--- a/configure
+++ b/configure
@@ -2302,6 +2302,9 @@ bsd)
esac
echo TRACE_BACKEND=$trace_backend $config_host_mak
+if test $trace_backend = simple; then
+ echo CONFIG_SIMPLE_TRACE=y $config_host_mak
+fi
if test $trace_backend = ust; then
LIBS=-lust $LIBS
fi
diff --git a/monitor.c b/monitor.c
index ad50f12..fda29aa 100644
--- a/monitor.c
+++ b/monitor.c
@@ -55,6 +55,9 @@
#include json-streamer.h
#include json-parser.h
#include osdep.h
+#ifdef CONFIG_SIMPLE_TRACE
+#include trace.h
+#endif
//#define DEBUG
//#define DEBUG_COMPLETION
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index b6e3467..c604aec 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -221,6 +221,22 @@ STEXI
@item logfile @var{filename}
@findex logfile
Output logs to @var{filename}.
+#ifdef CONFIG_SIMPLE_TRACE
+ETEXI
+
+{
+.name = trace,
+.args_type = ,
+.params = ,
+.help = shows contents of trace buffer,
+.mhandler.cmd = do_info_trace,
+},
+
+STEXI
+...@item trace
+...@findex trace
+show contents of trace buffer
+#endif
ETEXI
{
diff --git a/simpletrace.c b/simpletrace.c
index 2fec4d3..8f33a81 100644
--- a/simpletrace.c
+++ b/simpletrace.c
@@ -62,3 +62,18 @@ void trace4(TraceEvent event, unsigned long x1, unsigned
long x2, unsigned long
void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4, unsigned long x5) {
trace(event, x1, x2, x3, x4, x5);
}
+
+void do_info_trace(Monitor *mon) {
+static unsigned int i, max_idx;
+
+if (trace_idx)
+max_idx = trace_idx;
+else
+max_idx = TRACE_BUF_LEN;
+
+for (i=0; imax_idx ;i++)
+monitor_printf(mon, Event %ld : %ld %ld %ld %ld %ld\n,
+ trace_buf[i].event, trace_buf[i].x1, trace_buf[i].x2,
+ trace_buf[i].x3, trace_buf[i].x4, trace_buf[i].x5);
+return;
+}
diff --git a/tracetool b/tracetool
index 9ea9c08..6c15154 100755
--- a/tracetool
+++ b/tracetool
@@ -130,6 +130,7 @@ void trace2(TraceEvent event, unsigned long x1, unsigned
long x2);
void trace3(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3);
void trace4(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4);
void trace5(TraceEvent event, unsigned long x1, unsigned long x2, unsigned
long x3, unsigned long x4, unsigned long x5);
+void do_info_trace(Monitor *mon);
EOF
simple_event_num=0
@@ -289,6 +290,9 @@ tracetoh()
#define TRACE_H
#include qemu-common.h
+
+extern void monitor_printf(Monitor *mon, const char *fmt, ...)
+__attribute__ ((__format__ (__printf__, 2, 3)));
EOF
convert h
echo #endif /* TRACE_H */
--
1.6.2.5
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
Re: [Qemu-devel] [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
On 06/08/10 01:51, Anthony Liguori wrote: Right now, if you set a QemuOpts option in a section twice, when you get the option you'll receive the value that was set the first time. This is less than ideal because if you're manipulating options in two places like a global config followed by the command line, you really want the later to override the former. This patch fixes this behavior. Note that this reverses the ordering for users which want multiple values (slirp forwarding for example). cheers, Gerd
[Qemu-devel] Re: KVM call agenda for June 8
Anthony Liguori anth...@codemonkey.ws wrote: On 06/07/2010 05:26 PM, Chris Wright wrote: Please send in any agenda items you are interested in covering. If we have a lack of agenda items I'll cancel the week's call. - Accelerating counters (aka moving PIT to userspace, keeping HPET in userspace) - Live migration + hotplug - migration events? any news about this or async migrate command? - migration subsections. I have some initial code that I expect to push before the call. Later, Juan.
Re: [Qemu-devel] [PATCH 05/22] machine: pass all init options as a single QemuOpts
On 06/08/10 01:51, Anthony Liguori wrote: This patch redefines the machine init signature to just take a QemuOpts. It also passes the machine as the first parameter to allow multiple boards to be defined with one init function. +typedef void QEMUMachineInitFunc(QemuOpts *opts); Hmm? Where is the machine parameter? cheers, Gerd
[Qemu-devel] [Bug 521994] Re: Windows 98 doesn't detect mouse on qemu and SeaBIOS.
I confirm also that mouse is not detected on Kubuntu 10.04 running qemu and Windows 98. -- Windows 98 doesn't detect mouse on qemu and SeaBIOS. https://bugs.launchpad.net/bugs/521994 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Confirmed Bug description: A windows 98 guest doesn't detect mouse on recent qemu. I bisected and the result is fd646122418ecefcde228d43821d07da79dd99bb is the first bad commit commit fd646122418ecefcde228d43821d07da79dd99bb Author: Anthony Liguori aligu...@us.ibm.com Date: Fri Oct 30 09:06:09 2009 -0500 Switch pc bios from pc-bios to seabios SeaBIOS is a port of pc-bios to GCC. Besides using a more modern tool chain, SeaBIOS introduces a number of new features including PMM support, better BEV and BCV support, and better PnP support. Signed-off-by: Anthony Liguori aligu...@us.ibm.com I got following messages with DEBUG_BIOS Start bios (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) Ram Size=0x0800 (0x high) CPU Mhz=2271 Found 1 cpu(s) max supported 1 cpu(s) PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xe000 region 1: 0xe200 region 6: 0xe201 MP table addr=0x000f89b0 MPC table addr=0x000f89c0 size=224 SMBIOS ptr=0x000f8990 table=0x07fffef0 ACPI tables: RSDP=0x000f8960 RSDT=0x07ffde30 Scan for VGA option rom Running option rom at c000:0003 VGABios $Id$ Turning on vga console Starting SeaBIOS (version 0.5.1-20100111_132716-squirrel.codemonkey.ws) Found 0 lpt ports Found 0 serial ports ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9) ATA controller 1 at 170/374/c008 (irq 15 dev 9) ps2 irq but no data. ata0-0: PCHS=812/16/63 translation=none LCHS=812/16/63 ata0-1: PCHS=1152/16/56 translation=none LCHS=1024/16/56 ps2_recvbyte timeout keyboard initialized Scan for option roms Returned 53248 bytes of ZoneHigh e820 map has 6 items: 0: - 0009f400 = 1 1: 0009f400 - 000a = 2 2: 000f - 0010 = 2 3: 0010 - 07ffd000 = 1 4: 07ffd000 - 0800 = 2 5: fffc - 0001 = 2 enter handle_19: NULL Booting from Hard Disk... Booting from :7c00 pnp call arg1=5 pnp call arg1=0 ps2_recvbyte timeout ps2_recvbyte timeout ps2_recvbyte timeout ps2_recvbyte timeout
Re: [Qemu-devel] Re: [PATCH] Fix regression for -drive file=
Am 08.06.2010 09:38, schrieb Markus Armbruster:
Did this fall through the cracks?
Looks like it. Rebased and applied to the block branch.
Kevin
Markus Armbruster arm...@redhat.com writes:
Empty file used to create an empty drive (no media). Since commit
9dfd7c7a, it's an error: qemu: could not open disk image : No such
file or directory. Older versions of libvirt can choke on this.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
If this goes in, I'll prepare a patch for stable as well.
vl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index 85bcc84..78ec1b2 100644
--- a/vl.c
+++ b/vl.c
@@ -1097,7 +1097,7 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
case IF_COUNT:
abort();
}
-if (!file) {
+if (!file || !*file) {
*fatal_error = 0;
return NULL;
}
Re: [Qemu-devel] [PATCH v4] savevm: Really verify if a drive supports snapshots
Am 08.06.2010 06:39, schrieb MORITA Kazutaka:
At Fri, 4 Jun 2010 16:35:59 -0300,
Miguel Di Ciurcio Filho wrote:
Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.
First issue: Their names implies different porpouses, but they do the same
thing
and have exactly the same code. Maybe copied and pasted and forgotten?
bdrv_has_snapshot() is called in various places for actually checking if
there
is snapshots or not.
Second issue: the way bdrv_can_snapshot() verifies if a block driver
supports or
not snapshots does not catch all cases. E.g.: a raw image.
So when do_savevm() is called, first thing it does is to set a global
BlockDriverState to save the VM memory state calling get_bs_snapshots().
static BlockDriverState *get_bs_snapshots(void)
{
BlockDriverState *bs;
DriveInfo *dinfo;
if (bs_snapshots)
return bs_snapshots;
QTAILQ_FOREACH(dinfo, drives, next) {
bs = dinfo-bdrv;
if (bdrv_can_snapshot(bs))
goto ok;
}
return NULL;
ok:
bs_snapshots = bs;
return bs;
}
bdrv_can_snapshot() may return a BlockDriverState that does not support
snapshots and do_savevm() goes on.
Later on in do_savevm(), we find:
QTAILQ_FOREACH(dinfo, drives, next) {
bs1 = dinfo-bdrv;
if (bdrv_has_snapshot(bs1)) {
/* Write VM state size only to the image that contains the state
*/
sn-vm_state_size = (bs == bs1 ? vm_state_size : 0);
ret = bdrv_snapshot_create(bs1, sn);
if (ret 0) {
monitor_printf(mon, Error while creating snapshot on
'%s'\n,
bdrv_get_device_name(bs1));
}
}
}
bdrv_has_snapshot(bs1) is not checking if the device does support or has
snapshots as explained above. Only in bdrv_snapshot_create() the device is
actually checked for snapshot support.
So, in cases where the first device supports snapshots, and the second does
not,
the snapshot on the first will happen anyways. I believe this is not a good
behavior. It should be an all or nothing process.
This patch addresses these issues by making bdrv_can_snapshot() actually do
what it must do and enforces better tests to avoid errors in the middle of
do_savevm(). bdrv_has_snapshot() is removed and replaced by
bdrv_can_snapshot()
where appropriate.
bdrv_can_snapshot() was moved from savevm.c to block.c. It makes more sense
to me.
The loadvm_state() function was updated too to enforce that when loading a
VM at
least all writable devices must support snapshots too.
Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
---
block.c | 11 +++
block.h |1 +
savevm.c | 58 --
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/block.c b/block.c
index cd70730..ace3cdb 100644
--- a/block.c
+++ b/block.c
@@ -1720,6 +1720,17 @@ void bdrv_debug_event(BlockDriverState *bs,
BlkDebugEvent event)
/**/
/* handling of snapshots */
+int bdrv_can_snapshot(BlockDriverState *bs)
+{
+BlockDriver *drv = bs-drv;
+if (!drv || !drv-bdrv_snapshot_create || bdrv_is_removable(bs) ||
+bdrv_is_read_only(bs)) {
+return 0;
+}
+
+return 1;
+}
+
The underlying protocol could support snapshots, so I think we should
check against bs-file too.
--- a/block.c
+++ b/block.c
@@ -1671,6 +1671,9 @@ int bdrv_can_snapshot(BlockDriverState *bs)
BlockDriver *drv = bs-drv;
if (!drv || !drv-bdrv_snapshot_create || bdrv_is_removable(bs) ||
bdrv_is_read_only(bs)) {
+if (bs-file) {
+return bdrv_can_snapshot(bs-file);
+}
return 0;
}
You're right that we need to consider protocols, but I think your fix
isn't completely correct either. We should check bs-file only if
!drv-bdrv_snapshot_create, the other options still mean that we can't
snapshot.
Miguel, looks like this needs a v5...
Kevin
Re: [Qemu-devel] [PATCH 10/22] machine: allow boards to specify default values and use it in isapc
static QEMUMachine pc_machine = {
.name = pc-0.13,
.alias = pc,
.desc = Standard PC,
-.init = pc_init_pci,
+.init = pc_init,
.max_cpus = 255,
.is_default = 1,
.opts_desc = pc_opts_desc,
+.opts_default = (QemuOptValue[]) {
+{
+.name = acpi,
+.value = on,
+},
Should be moved into a separate struct and just referenced as it is
identical for pc-0.*
cheers,
Gerd
Re: [Qemu-devel] [RFC 0/3] Tracing framework for QEMU
Hi Stefan, Interesting to see your patches, tracepoint definitions/declarations look similar to in-kernel tracepoints :). The choice of a kernel-tracepoint approach had advantages since it places no inherent limitation on maximum number of arguments that can be logged. Also, it is flexible enough to dump entire arrays if need be -- which is not as easily accomplished in the proposed approach as with kernel tracepoints. -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
Re: [Qemu-devel] [PATCH 3/3] cow: use qemu block API
On Mon, Jun 07, 2010 at 02:27:40PM +0200, Markus Armbruster wrote: Christoph Hellwig h...@lst.de writes: Use bdrv_pwrite to access the backing device instead of pread, and convert the driver to implementing the bdrv_open method which gives it an already opened BlockDriverState for the underlying device. Signed-off-by: Christoph Hellwig h...@lst.de In my (admittedly limited) understanding, we need this for sane protocol handling in -blockdev friends. Yes - not just in -blockdev but also in general.
[Qemu-devel] Re: KVM call agenda for June 8
On 06/08/2010 01:26 AM, Chris Wright wrote: Please send in any agenda items you are interested in covering. APIC wiring problems (attached slides) -- error compiling committee.c: too many arguments to function apic-wiring-mess.odp Description: application/vnd.oasis.opendocument.presentation
[Qemu-devel] Do we still need the hack to set qdev id from NICInfo.name?
In pci_nic_init():
pci_dev = pci_create(bus, devfn, pci_nic_names[i]);
dev = pci_dev-qdev;
if (nd-name)
dev-id = qemu_strdup(nd-name);
Blatant violation of the DeviceState abstraction. Which even carries a
comment advising against this:
/* This structure should not be accessed directly. We declare it here
so that it can be embedded in individual device state structures. */
struct DeviceState {
Do we still need this? Anybody wanting ID can use -device.
History: it was added in commit eb54b6dc
Author: Gerd Hoffmann kra...@redhat.com
Date: Wed Jul 15 13:43:35 2009 +0200
qdev: add id= support for pci nics.
and modified to use existing name instead of new id in commit dea7b3b9
Author: Mark McLoughlin mar...@redhat.com
Date: Thu Oct 8 19:58:22 2009 +0100
net: remove id field from NICInfo
Just use the name field instead since we now use the id paramater as
the name, if supplied. Only implication with this change is that if
id is not supplied, the value of the name paramater is used as an
id.
[Qemu-devel] Re: Do we still need the hack to set qdev id from NICInfo.name?
pci_dev = pci_create(bus, devfn, pci_nic_names[i]); dev =pci_dev-qdev; if (nd-name) dev-id = qemu_strdup(nd-name); Blatant violation of the DeviceState abstraction. Which even carries a comment advising against this: Do we still need this? Anybody wanting ID can use -device. I think it is only used for -net nic,...,name=something. I think this predates working -device for nics. So, yes, it shouldn't be needed any more ... cheers, Gerd
[Qemu-devel] Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
sorry, the subject should read 2.6.35-rc2 Peter Lieven wrote: Hi, I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 0.12.4. When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows the following error after the mem transfer has finished: kvm: unhandled exit 8022 kvm: kvm_run returned -22 cmdline: /usr/bin/qemu-kvm-0.12.4 -net none -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 'opensuse-11.2-i586' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.20:5003 -pidfile /var/run/qemu/vm-154.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' Migrating the same VM worked with 2.6.34 kvm module. Thanks, Peter
Re: [Qemu-devel] [PATCH] Fix and simplify gui timer logic.
On 06/07/10 18:12, Paul Brook wrote: Kill nographic timer. Have a global gui_timer instead. Have the gui timer enabled unconditionally. We need a timer running anyway for mmio flush, so the whole have-gui-timer-only-when-needed logic is pretty pointless. It also simplifies displaylisteners coming and going at runtime, we don't need to care about the timer then as it runs anyway. Linking mmio flushes to the gui is completely bogus. The fact that we're doing arbitrary periodic mmio flushes suggests something else is horribly broken. Was added by commit http://git.qemu.org/qemu.git/commit/?id=62a2744ca09a0b44b8406ea0c430c4c67a2c3231 Patch description makes sense to me. Of course we could have a separate timer for the mmio flushes instead of re-using the gui timer. But we would have more wakeups then ... cheers, Gerd
[Qemu-devel] Re: RFC: blockdev_add friends, brief rationale, QMP docs
Avi Kivity a...@redhat.com writes:
On 06/04/2010 05:16 PM, Markus Armbruster wrote:
- protocol: json-array of json-object
Each element object has a member name
- Possible values: file, nbd, ...
Additional members depend on the value of name.
For name = file:
- file: file name (json-string)
For name = nbd:
- domain: address family (json-string, optional)
- Possible values: inet (default), unix
- file: file name (json-string), only with domain = unix
- host: host name (json-string), only with domain = inet
- port: port (json-int), only with domain = inet
...
This loses the nesting that protocols have. I'd like to see the each
nested protocol as member of the parent protocol. Besides the lovely
} } }s in the json representation, this allows us to have more
complicated protocols, for example a mirror protocol that has two
child protocol each specifying a different backing store.
Even though we don't have such a protocol yet, not even plans to get it,
your argument tips the balance towards nesting.
Revised sketch: instead of
- file: the disk image file to use (json-string, optional)
- format: disk format (json-string, optional)
- Possible values: raw, qcow2, ...
have
- format: image format (json-string, optional)
- Possible values: raw, qcow2, [...]
- protocol: image access protocol (json-object)
- It has a member name (json-string), and depending on its value
additional members.
- For name = auto, file, [...]
- file: name of image file (json-string)
- For name = nbd:
- domain: address family (json-string, optional)
- Possible values: inet (default), unix
- file: name of socket file (json-string), only with domain =
unix
- host: host name (json-string), only with domain = inet
- port: port (json-int), only with domain = inet
- For name = blkdebug:
- config: name of config file (json-string)
- protocol: image access protocol (json-object), as above
[...]
Examples:
* Format qcow2, protocol auto with argument filename foo.img
format: qcow2,
protocol: { name: auto, file: foo.qcow2 }
* Format raw, protocol nbd with arguments domain unix, filename
/tmp/my_socket
format: raw
protocol: { name: nbd, domain: unix, file: /tmp/my_socket }
* Format not specified (system guesses one), protocol blkdebug with
argument filename /tmp/blkdebug.cfg stacked onto protocol fat with
arguments floppy true, dirname /tmp/dir
protocol: { name: blkdebug, file: /tmp/blkdebug.cfg,
protocol: { name: fat, floppy: true, dir: /tmp/dir }
}
This nesting business is easy enough for QMP, but it'll be awkward on
the command line. Ideas on how to do it cleanly with -blockdev?
Re: [Qemu-devel] Re: Qemu-KVM Livate Migration 0.12.2 - 0.12.3/4 broken?
Jan Kiszka wrote:
Juan Quintela wrote:
Jan Kiszka jan.kis...@web.de wrote:
Juan Quintela wrote:
Lack of proper subsections. IDE is something like:
const VMStateDescription vmstate_ide_drive = {
.version_id = 4,
}
static const VMStateDescription vmstate_bmdma = {
.name = ide bmdma,
.version_id = 4,
...
}
const VMStateDescription vmstate_ide_pci = {
.name = ide,
.version_id = 4,
VMSTATE_STRUCT_ARRAY(bmdma, PCIIDEState, 2, 0,
vmstate_bmdma, BMDMAState),
VMSTATE_IDE_DRIVES(bus[0].ifs, PCIIDEState),
VMSTATE_IDE_DRIVES(bus[1].ifs, PCIIDEState),
}
Notice that everything is at version 4. It used to be everything at
version 3. Now the problem is that when migrating from v3 - v4. We
put in one place v3, But we only have a version number at the toplevel,
rest of subsections don't sent a version number. There is no way to
fix it in the general case. We can hack something around for ide, but
that will just be a hack, or we can backport marcelo change and port it
as a proper subsection (that is my plan). I expect to have time at the
end of next time to work on this.
BTW, the IDE subsystem is yet lacking a proper vmstate section split-up
along qdev boundaries (ie. vmstate_ide_pci should not contain drive
structures). Do you plan to address this as well?
Not for Friday, and not for 0.12.
For sure. I missed that this was only a 0.12 issue.
That is 0.13 material, and have to get one agreement on how to go.
We can go for:
- good structure
- backward compatibility
I can't see any good way to get both at this stage :( But I am open to
sugestions.
Based on recent experiments with vmstate to enhance the hpet, I'm fairly
optimistic that we can have both (just the code complexity suffers a
bit): Split up the drive sections for new versions, but keep the legacy
fields with attached .field_exists() filters for reading of old
versions. But I may also underestimate issues of this particular case.
Later, Juan.
PD. BTW, very good work with printing the vmstate, that was one of the goals
when we added it, that was the next step after porting everything to
vmstate :)
I'm sorry for stealing you the pleasure to add it. :)
Jan
whats the status of this issue? will migration from 0.12.2 to
0.12.4.1/0.13 work again?
whats the scheduled release dates for 0.12.4.1 and 0.13 (still july 1st) ?
thanks,
peter
[Qemu-devel] Re: KVM call agenda for June 8
On 06/08/2010 11:50 AM, Avi Kivity wrote: On 06/08/2010 01:26 AM, Chris Wright wrote: Please send in any agenda items you are interested in covering. APIC wiring problems (attached slides) See also http://www.intel.com/design/pentium/datashts/242016.HTM. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/08/2010 05:12 AM, Paul Brook wrote: This series introduces a rather radical change in the way we deal with machine definitions in QEMU. I think we should aim to eliminate machine_register_core, and design appropriately. In particular I'd try and avoid adding options that become trivially redundant once you can easily change the device trees. I agree I don't like patch 13 (the parallel/virtcon/vga/floppy/cdrom QemuOpts). Maybe those QemuOpts can be marked in a way that they're not user-accessible (and though in some cases customizing max_cpus may make sense, that option could also fall in that category). Everything else is very much reasonable in Anthony's patch series, I think. I'm undecided how much parameterisation it's worth trying to support in the device tree. IMO the current code has way too much magic, because creating a new variant involves hacking and rebuilding pc.c. See patch 22/22. There is really no magic involved, even though the compat machines are not yet as config files. I'm extremely tempted by the extreme approach of punting everything to an external device tree builder. i.e. remove automagical device reation altogether. I think this should have been raised when the -readconfig/-writeconfig scheme was proposed and committed. I don't think it's reasonable to block this patch series (or something very much like it) on the grounds that a better device tree description model than QemuOpts can be designed. The problem with doing clever device tree generation/manipulation inside qemu is that for anything vaguely nonstandard you're likely to have to hack your own device tree anyway. Even ram allocation is nontrivial, e.g. the hole below 4G on the PC, and that's before you start with numa-like layouts. Again, the patch is not making anything worse. On a similar note, I don't see any point having machine_create_from_core, we can just ship appropriate config files. I think that's the obvious next step, but there's no reason not to split it at this point. Paolo
[Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
On 06/08/2010 09:51 AM, Gerd Hoffmann wrote:
On 06/08/10 01:51, Anthony Liguori wrote:
Right now, if you set a QemuOpts option in a section twice, when
you get the option you'll receive the value that was set the first
time. This is less than ideal because if you're manipulating
options in two places like a global config followed by the command
line, you really want the later to override the former.
This patch fixes this behavior.
Note that this reverses the ordering for users which want multiple
values (slirp forwarding for example).
And qemu_opt_find seems to have thought about this too:
static QemuOpt *qemu_opt_find(QemuOpts *opts, const char *name)
{
QemuOpt *opt;
QTAILQ_FOREACH_REVERSE(opt, opts-head, QemuOptHead, next) {
if (strcmp(opt-name, name) != 0)
continue;
return opt;
}
return NULL;
}
Can you show the behavior with commandline arguments only?
Paolo
[Qemu-devel] [PATCH] un-register kbd driver for USB kbd unplug
From: Jes Sorensen jes.soren...@redhat.com Hi, This is a fairly simple fix for the problem where the keyboard event handler is left in place when a keyboard is unplugged, eg. USB. The long term solution would be to use Shahar Havivi's multi-keyboard support patch[1] from March, but until Shahar's patch is ready, this one fixes the current crash problem. Cheers, Jes [1]: http://www.mail-archive.com/qemu-devel@nongnu.org/msg28589.html Jes Sorensen (1): un-register kbd driver in case of USB kbd unplug. console.h|1 + hw/usb-hid.c |3 +++ input.c |6 ++ 3 files changed, 10 insertions(+), 0 deletions(-)
[Qemu-devel] [PATCH] un-register kbd driver in case of USB kbd unplug.
From: Jes Sorensen jes.soren...@redhat.com
If a USB keyboard is unplugged, the keyboard eventhandler is never
removed, and events will continue to be passed through to the device,
causing crashes or memory corruption.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
console.h|1 +
hw/usb-hid.c |3 +++
input.c |6 ++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/console.h b/console.h
index cac959f..aafb031 100644
--- a/console.h
+++ b/console.h
@@ -42,6 +42,7 @@ typedef struct QEMUPutLEDEntry {
} QEMUPutLEDEntry;
void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque);
+void qemu_remove_kbd_event_handler(void);
QEMUPutMouseEntry *qemu_add_mouse_event_handler(QEMUPutMouseEvent *func,
void *opaque, int absolute,
const char *name);
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index 8e6c6e0..333b626 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -856,6 +856,9 @@ static void usb_hid_handle_destroy(USBDevice *dev)
if (s-kind != USB_KEYBOARD)
qemu_remove_mouse_event_handler(s-ptr.eh_entry);
+if (s-kind == USB_KEYBOARD)
+qemu_remove_kbd_event_handler();
+
/* TODO: else */
}
diff --git a/input.c b/input.c
index 651442d..ec05548 100644
--- a/input.c
+++ b/input.c
@@ -42,6 +42,12 @@ void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void
*opaque)
qemu_put_kbd_event = func;
}
+void qemu_remove_kbd_event_handler(void)
+{
+qemu_put_kbd_event_opaque = NULL;
+qemu_put_kbd_event = NULL;
+}
+
static void check_mode_change(void)
{
static int current_is_absolute, current_has_absolute;
--
1.6.5.2
[Qemu-devel] [PATCH] qdev: Revert the hack to let -net nic and pci_add set qdev ID
Setting the ID in pci_nic_init() is a blatant violation of the DeviceState abstraction. Which even carries a comment advising against this: /* This structure should not be accessed directly. We declare it here so that it can be embedded in individual device state structures. */ What's worse, it bypasses the code ensuring unique qdev IDs: -device virtio-net-pci,id=foo -net nic,id=foo -net nic,name=foo happily creates three qdevs with ID foo. That's because qdev relies on qemu_opts_create() to ensure unique IDs, but -net nic uses a different QemuOptsList, which means id is in a different namespace. And its name is not checked for uniqueness at all. -net nic and pci_add are legacy. Use -device and device_add if you want a NIC with a qdev ID. This reverts what's still left of commit eb54b6dc qdev: add id= support for pci nics. Signed-off-by: Markus Armbruster arm...@redhat.com --- hw/pci.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/hw/pci.c b/hw/pci.c index cbbd1dd..fab8c09 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -1446,8 +1446,6 @@ PCIDevice *pci_nic_init(NICInfo *nd, const char *default_model, pci_dev = pci_create(bus, devfn, pci_nic_names[i]); dev = pci_dev-qdev; -if (nd-name) -dev-id = qemu_strdup(nd-name); qdev_set_nic_properties(dev, nd); if (qdev_init(dev) 0) return NULL; -- 1.6.6.1
[Qemu-devel] [PATCH] qemu-option: Reject anti-social IDs
Restrict IDs to letters, digits, '-', '.', '_', starting with a
letter.
This takes care of '/' in qdev IDs breaking qbus_find().
Signed-off-by: Markus Armbruster arm...@redhat.com
---
qemu-option.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index acd74f9..74fb882 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -672,11 +672,31 @@ QemuOpts *qemu_opts_find(QemuOptsList *list, const char
*id)
return NULL;
}
+static int id_wellformed(const char *id)
+{
+int i;
+
+if (!qemu_isalpha(id[0])) {
+return 0;
+}
+for (i = 1; id[i]; i++) {
+if (!qemu_isalnum(id[i]) !strchr(-._, id[i])) {
+return 0;
+}
+}
+return 1;
+}
+
QemuOpts *qemu_opts_create(QemuOptsList *list, const char *id, int
fail_if_exists)
{
QemuOpts *opts = NULL;
if (id) {
+if (!id_wellformed(id)) {
+qerror_report(QERR_INVALID_PARAMETER_VALUE, id, an identifier);
+error_printf_unless_qmp(Identifiers consist of letters, digits,
'-', '.', '_', starting with a letter.\n);
+return NULL;
+}
opts = qemu_opts_find(list, id);
if (opts != NULL) {
if (fail_if_exists) {
--
1.6.6.1
Re: [Qemu-devel] [PATCH] qdev: Reject duplicate and anti-social device IDs
Paul Brook p...@codesourcery.com writes: Paul Brook p...@codesourcery.com writes: Also require IDs to start with a letter to provide for possible future extensions. I'd go further than that, and require that user specified IDs match [A-Za-z][A-Za-z0-9_-]* I talked with Dan (cc'ed) to make sure we don't trample on existing libvirt usage without need. What about [A-Za-z][A-Za-z0-9_-:.]* i.e. your regexp plus ':' and '.' in the second bracket? I was deliberately avoiding those as they're often used as separators - we already use ':' in other contexts so there's potential ambiguity and parsing/quoting issues. I'm not aware of any current issues with '.'. I checked with Dan, and we can outlaw ':'. I just posted a new patch that covers all qemu-option IDs, not just qdev. [...]
[Qemu-devel] Re: [PATCH] un-register kbd driver for USB kbd unplug
On Tue, Jun 08, 2010 at 12:43:50PM +0200, jes.soren...@redhat.com wrote: Date: Tue, 8 Jun 2010 12:43:50 +0200 From: jes.soren...@redhat.com To: anth...@codemonkey.ws Cc: qemu-devel@nongnu.org, shav...@redhat.com, Jes Sorensen jes.soren...@redhat.com Subject: [PATCH] un-register kbd driver for USB kbd unplug From: Jes Sorensen jes.soren...@redhat.com Hi, This is a fairly simple fix for the problem where the keyboard event handler is left in place when a keyboard is unplugged, eg. USB. The long term solution would be to use Shahar Havivi's multi-keyboard support patch[1] from March, but until Shahar's patch is ready, this one fixes the current crash problem. Cheers, Jes Anthony, You reply that you applied the patch: http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00673.html but it didn't made it, is there a problem with the patch? Thanks, Shahar. [1]: http://www.mail-archive.com/qemu-devel@nongnu.org/msg28589.html Jes Sorensen (1): un-register kbd driver in case of USB kbd unplug. console.h|1 + hw/usb-hid.c |3 +++ input.c |6 ++ 3 files changed, 10 insertions(+), 0 deletions(-)
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On Mon, Jun 07, 2010 at 04:57:09PM -0500, Anthony Liguori wrote: On 06/07/2010 04:37 PM, Anthony Liguori wrote: On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: So I see two ways to go forward: switch default value in my patch, or disable vlans unconditionally. The problem with disabling vlans unconditionally is that you break -net socket and -net dump. If we can come up with an alternative way to do these things, I'm all for removing it. Hmm, I'll try to look at supporting -net socket in netdev. Does -net dump do anything that can't be done with tap+tcpdump? tap+tcpdump requires root privileges (even if you have a tap helper). Plus tcpdump doesn't help with slirp and -net dump is very useful for debugging slirp. Developer's need for root access for debugging seems a reasonable price to pay to prevent user confusion and complexity that we have now. Of course, you could add this functionality to netdev. It's arguably better there too because then you can debug virtio-net+tap with full offload enabled (which you cannot do today). Regards, Anthony Liguori Care taking on it? I never even heard about -net dump before today. -- MST
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote: With -netdev, there now seems to be little need to support vlans, enabling them leads to user confusion and bad performance. Disable support for vlans by default, add config option to enable. No. If you want to remove vlans, then actually do that. As I've said before if you want a point-point network model then you should implement that (and remove the vlan code, probably replacing with equivalent functionality). We should not have both point-point and broadcast interfaces. Paul By the way I agree with this. It would have been better to simply prohibit more than 2 devices on a vlan instead of two competing ways to set up networking that we have now. And the conclusion I think should be to remove broadcast support ASAP. -- MST
[Qemu-devel] [RFC] QMP: new query-snapshots command
Hi there,
This is just an initial draft. I would like to align everybody's opinions and
expectations about this feature before starting coding and submitting patches.
(although I've already started to hack some stuff [1])
The way QEMU tracks snapshot identification is not consistent and lacks various
features already available in other virtualization solutions (free or not).
This proposal tries to bring QEMU to the level of other virtualization solutions
when snapshoting is concerned and to define the QMP semantics for it.
Case A:
$ savevm (no parameters)
When no name is provided, a new id_str is created by searching for the
bigger id_str among the available snapshots in the device being taken
an snapshot.
This is done in block/qcow2-snapshot.c:find_new_snapshot_id() with
conversions from char, to int, and then to char again.
Problems:
A VM is loaded with two devices, one device with three previous snapshots and
the other device with two previous snapshots.
I take a new snapshot of the VM without a name: the first device will
save the snapshot as id_str 4 and the second device with id_str 3.
I play around for a while and I want to restore the VM to my latest
state. When 'info snapshots' is run, only the first device is show
with the VM state, and the latest ID shown will be 4.
So, I fire up loadvm 4. qemu will try to load by id or name anyway,
will succeed loading the VM state from the first device, but will fail
to load an non-existent snapshot id from the second device and will
still be running with the second device out of sync with the VM state.
Just take a look at savevm.c:load_vmstate().
Case B:
qemu allows tacking a new snapshot and use a previously used id_str.
Running again:
$ savevm 4
The previously saved state identified by id_str 4 will be deleted and
replaced by a new one, but only in the first device of my example
above. The second device will get a new snapshot, since it does not
have a id_str equal to 4.
If I run loadvm 4 again, the snapshot id 3 in the second device will be left
there in an state diferent from the snapshot id 3 from the first device.
Case C:
Regarding the history of snapshots, qemu does not keep the
last/current snapshot taken.
typedef struct QEMUSnapshotInfo {
char id_str[128]; /* unique snapshot id */
/* the following fields are informative. They are not needed for
the consistency of the snapshot */
char name[256]; /* user choosen name */
uint32_t vm_state_size; /* VM state info size */
uint32_t date_sec; /* UTC date of the snapshot */
uint32_t date_nsec;
uint64_t vm_clock_nsec; /* VM clock relative to boot */
} QEMUSnapshotInfo;
There is no parent-like information.
To solve this problems, I believe we need to:
- Use a stronger identification for an snapshot, i.e.: bigger and
virtually unique identification for a certain snapshot being taken and
do not re-use an previous used ID for a new snapshot. UUID seams to be
a common denominator, as other virtualization projects use it.
- Add a 'parent_uuid' information. (uuid information can be added using the
extra_data field in qcow2, other formats like VDI already have)
- Take the calculation of the snapshot ID outside the block driver's level.
[1] http://github.com/miguelzinho/qemu-uuid/commits/master
Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
---
qemu-monitor.hx | 61 +++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index f6a94f2..27bd3d7 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -2207,6 +2207,67 @@ show information about active capturing
@item info snapshots
show list of VM snapshots
ETEXI
+SQMP
+query-snapshots
+---
+
+Show snapshot information about a VM.
+
+Each block device that supports and have snapshot information is stored in a
+json-object and the returned value is a json-array containing all devices.
+
+- device: device name (json-string)
+- state: true if the device is elected to hold the VM state. (json-bool)
+- snapshots: a json-object containing:
+ - uuid: UUID that identifies the snapshot (json-string)
+ - parent_uuid: UUID that identifies the a parent snapshot (json-string)
+ - date: date when the snapshot was taken, formated as MMDDHHMMSS
(json-int)
+ - tag: friendly name for an snapshot. It is not unique (json-string,
optional)
+
+Example:
+
+- { execute: query-snapshots }
+- {
+ return: [
+{
+device: virtio0,
+state: true,
+snaphots: [
+{
+uuid: 3fab28c9-a6bd-4659-b9bc-683780d8a2d5,
+parent_uuid: ----,
+date: 20100415164856
+},
+{
+uuid: 54ad75b9-552e-4fd1-852b-a1a20ac66bf5,
+parent_uuid: 3fab28c9-a6bd-4659-b9bc-683780d8a2d5,
+tag:
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
Avi Kivity wrote: On 06/08/2010 02:31 PM, Avi Kivity wrote: On 06/08/2010 02:29 PM, Avi Kivity wrote: On 06/08/2010 12:13 PM, Peter Lieven wrote: sorry, the subject should read 2.6.35-rc2 Peter Lieven wrote: Hi, I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 0.12.4. When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows the following error after the mem transfer has finished: kvm: unhandled exit 8022 kvm: kvm_run returned -22 cmdline: /usr/bin/qemu-kvm-0.12.4 -net none -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 'opensuse-11.2-i586' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.20:5003 -pidfile /var/run/qemu/vm-154.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' Migrating the same VM worked with 2.6.34 kvm module. Please provide you host /proc/cpuinfo. Also, after migration fails, the output of 'info registers' in the monitor. And finally, perhaps you have NX disabled in the bios of one of the machines? What does 'dmesg | grep NX' show on both hosts? nx was disabled on one of the nodes. i will retry the case later today and send info register output. what is the recommended value for nx (and why)? and why was it working with 2.6.34 and is not with 2.6.35-rc2? -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 .
[Qemu-devel] Disable PS/2 mouse
Hi, is there any way to disable the PS/2 mouse emulation from command line? BR, Peter
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
On 06/08/2010 03:49 PM, Peter Lieven wrote: And finally, perhaps you have NX disabled in the bios of one of the machines? What does 'dmesg | grep NX' show on both hosts? nx was disabled on one of the nodes. That explains the problem. i will retry the case later today and send info register output. what is the recommended value for nx (and why)? Enabled (so you get no-execute memory protection). and why was it working with 2.6.34 and is not with 2.6.35-rc2? We fixed a different bug. But you shouldn't live migrate from a machine with nx to a machine without nx, unless you use -cpu ...,-nx on both nodes. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
Avi Kivity wrote: On 06/08/2010 03:49 PM, Peter Lieven wrote: And finally, perhaps you have NX disabled in the bios of one of the machines? What does 'dmesg | grep NX' show on both hosts? nx was disabled on one of the nodes. That explains the problem. i will retry the case later today and send info register output. what is the recommended value for nx (and why)? Enabled (so you get no-execute memory protection). mhh, i am at the moment back to 2.6.34. here i do not see the nx flag in the guest of both 32-bit and 64-bit linux. and why was it working with 2.6.34 and is not with 2.6.35-rc2? We fixed a different bug. But you shouldn't live migrate from a machine with nx to a machine without nx, unless you use -cpu ...,-nx on both nodes. -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 .
Re: [Qemu-devel] [PATCH 10/22] machine: allow boards to specify default values and use it in isapc
On 06/08/2010 03:03 AM, Gerd Hoffmann wrote:
static QEMUMachine pc_machine = {
.name = pc-0.13,
.alias = pc,
.desc = Standard PC,
-.init = pc_init_pci,
+.init = pc_init,
.max_cpus = 255,
.is_default = 1,
.opts_desc = pc_opts_desc,
+.opts_default = (QemuOptValue[]) {
+{
+.name = acpi,
+.value = on,
+},
Should be moved into a separate struct and just referenced as it is
identical for pc-0.*
Would need to be macros because in future patches, things get more
complicated. That may be worth it though.
Regards,
Anthony Liguori
cheers,
Gerd
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On 06/08/2010 06:09 AM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: So I see two ways to go forward: switch default value in my patch, or disable vlans unconditionally. The problem with disabling vlans unconditionally is that you break -net socket and -net dump. -netdev socket seems to be supported. No? Sure, but it's of limited utility in the absence of vlans. A typical thing to do with -net socket would be to launch one instance of qemu with -net user, -net socket, and -net nic. Another qemu would be launched with -net socket and -net nic connected to the previous instance. Now you've got a working virtual network with external access. -netdev socket alone won't get you this. Regards, Anthony Liguori
[Qemu-devel] [PATCH v2] un-register kbd driver for USB kbd unplug
From: Jes Sorensen jes.soren...@redhat.com Hi, Kevin pointed out the TODO comment was obsolete and also suggested turning the if lines into a switch statement. It seems cleaner, so here is a second version of the patch. This is a fairly simple fix for the problem where the keyboard event handler is left in place when a keyboard is unplugged, eg. USB. The long term solution would be to use Shahar Havivi's multi-keyboard support patch[1] from March, but until Shahar's patch is ready, this one fixes the current crash problem. Cheers, Jes [1]: http://www.mail-archive.com/qemu-devel@nongnu.org/msg28589.html Jes Sorensen (1): un-register kbd driver in case of USB kbd unplug. console.h|1 + hw/usb-hid.c |8 ++-- input.c |6 ++ 3 files changed, 13 insertions(+), 2 deletions(-)
[Qemu-devel] [PATCH] un-register kbd driver in case of USB kbd unplug.
From: Jes Sorensen jes.soren...@redhat.com
If a USB keyboard is unplugged, the keyboard eventhandler is never
removed, and events will continue to be passed through to the device,
causing crashes or memory corruption.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
---
console.h|1 +
hw/usb-hid.c |8 ++--
input.c |6 ++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/console.h b/console.h
index cac959f..aafb031 100644
--- a/console.h
+++ b/console.h
@@ -42,6 +42,7 @@ typedef struct QEMUPutLEDEntry {
} QEMUPutLEDEntry;
void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void *opaque);
+void qemu_remove_kbd_event_handler(void);
QEMUPutMouseEntry *qemu_add_mouse_event_handler(QEMUPutMouseEvent *func,
void *opaque, int absolute,
const char *name);
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index 8e6c6e0..ca04511 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -854,9 +854,13 @@ static void usb_hid_handle_destroy(USBDevice *dev)
{
USBHIDState *s = (USBHIDState *)dev;
-if (s-kind != USB_KEYBOARD)
+switch(s-kind) {
+case USB_KEYBOARD:
+qemu_remove_kbd_event_handler();
+break;
+default:
qemu_remove_mouse_event_handler(s-ptr.eh_entry);
-/* TODO: else */
+}
}
static int usb_hid_initfn(USBDevice *dev, int kind)
diff --git a/input.c b/input.c
index 651442d..ec05548 100644
--- a/input.c
+++ b/input.c
@@ -42,6 +42,12 @@ void qemu_add_kbd_event_handler(QEMUPutKBDEvent *func, void
*opaque)
qemu_put_kbd_event = func;
}
+void qemu_remove_kbd_event_handler(void)
+{
+qemu_put_kbd_event_opaque = NULL;
+qemu_put_kbd_event = NULL;
+}
+
static void check_mode_change(void)
{
static int current_is_absolute, current_has_absolute;
--
1.6.5.2
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On 06/08/2010 07:13 AM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 04:57:09PM -0500, Anthony Liguori wrote: On 06/07/2010 04:37 PM, Anthony Liguori wrote: On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: So I see two ways to go forward: switch default value in my patch, or disable vlans unconditionally. The problem with disabling vlans unconditionally is that you break -net socket and -net dump. If we can come up with an alternative way to do these things, I'm all for removing it. Hmm, I'll try to look at supporting -net socket in netdev. Does -net dump do anything that can't be done with tap+tcpdump? tap+tcpdump requires root privileges (even if you have a tap helper). Plus tcpdump doesn't help with slirp and -net dump is very useful for debugging slirp. Developer's need for root access for debugging seems a reasonable price to pay to prevent user confusion and complexity that we have now. Removing vlans has the potential to break existing deployments. That's something we need to do very cautiously. What do we gain from removing vlan support today? Regards, Anthony Liguori Of course, you could add this functionality to netdev. It's arguably better there too because then you can debug virtio-net+tap with full offload enabled (which you cannot do today). Regards, Anthony Liguori Care taking on it? I never even heard about -net dump before today.
[Qemu-devel] Re: [PATCH 00/35] S390 TCG target, version 2
On 04.06.2010, at 21:14, Richard Henderson wrote: Changes v1-v2 * Disassembler doesn't include GPLv3 code. * Smashed about 20 commits into the New TCG Target patch, which is fully functional from the beginning. * Merged a lot of the follow-on patches such that introducing the use of an instruction and conditionalizing the use of the instruction on the active ISA features is not split into two separate patches. This patch series is available at git://repo.or.cz/qemu/rth.git tcg-s390-3 It works for me, it improves the current state, I see no reason not to take it! Let's get S390x host support out for 0.13! Acked-by: Alexander Graf ag...@suse.de Alex
Re: [Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
On 06/08/2010 05:32 AM, Paolo Bonzini wrote:
On 06/08/2010 09:51 AM, Gerd Hoffmann wrote:
On 06/08/10 01:51, Anthony Liguori wrote:
Right now, if you set a QemuOpts option in a section twice, when
you get the option you'll receive the value that was set the first
time. This is less than ideal because if you're manipulating
options in two places like a global config followed by the command
line, you really want the later to override the former.
This patch fixes this behavior.
Note that this reverses the ordering for users which want multiple
values (slirp forwarding for example).
And qemu_opt_find seems to have thought about this too:
static QemuOpt *qemu_opt_find(QemuOpts *opts, const char *name)
{
QemuOpt *opt;
QTAILQ_FOREACH_REVERSE(opt, opts-head, QemuOptHead, next) {
if (strcmp(opt-name, name) != 0)
continue;
return opt;
}
return NULL;
}
Can you show the behavior with commandline arguments only?
The problem I was trying to address can be seen with something like:
-drive file=foo.img,if=virtio,file=bar.img
You get no error, and foo.img is what gets used. It's fair to argue
this is a silly use case but what I'm trying to achieve is to make it
possible to do:
-drive file=foo.img,if=virtio,id=bar -drive file=bar.img,id=bar
Or more specifically:
foo.conf:
[drive]
file=foo.img
if=virtio
id=bar
qemu -readconfig foo.conf -drive file=bar.img,id=bar
IMHO, what's specified next on the command line ought to override what's
in the config.
Suggestions how to achieve this in a more elegant way would be appreciated.
Regards,
Anthony Liguori
Paolo
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
Avi Kivity wrote: On 06/08/2010 03:49 PM, Peter Lieven wrote: And finally, perhaps you have NX disabled in the bios of one of the machines? What does 'dmesg | grep NX' show on both hosts? nx was disabled on one of the nodes. That explains the problem. i will retry the case later today and send info register output. what is the recommended value for nx (and why)? Enabled (so you get no-execute memory protection). do you have a guideline which flags should be identical to ensure proper live migration? i would like to do an automatic compare before life migration to avoid crashes. thanks peter and why was it working with 2.6.34 and is not with 2.6.35-rc2? We fixed a different bug. But you shouldn't live migrate from a machine with nx to a machine without nx, unless you use -cpu ...,-nx on both nodes. -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 .
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On Tue, Jun 08, 2010 at 08:03:33AM -0500, Anthony Liguori wrote: On 06/08/2010 07:13 AM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 04:57:09PM -0500, Anthony Liguori wrote: On 06/07/2010 04:37 PM, Anthony Liguori wrote: On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: So I see two ways to go forward: switch default value in my patch, or disable vlans unconditionally. The problem with disabling vlans unconditionally is that you break -net socket and -net dump. If we can come up with an alternative way to do these things, I'm all for removing it. Hmm, I'll try to look at supporting -net socket in netdev. Does -net dump do anything that can't be done with tap+tcpdump? tap+tcpdump requires root privileges (even if you have a tap helper). Plus tcpdump doesn't help with slirp and -net dump is very useful for debugging slirp. Developer's need for root access for debugging seems a reasonable price to pay to prevent user confusion and complexity that we have now. Removing vlans has the potential to break existing deployments. That's something we need to do very cautiously. You mean you want to support both peer to peer and broadcast indefinitely? What do we gain from removing vlan support today? Regards, Anthony Liguori This would address the following issues: - people configure vlans and get bad performance - people run --help and see info on vlans instead of peer - migration issues betwen vlan/non-vlan - hotplug is broken for vlan nics Of course, you could add this functionality to netdev. It's arguably better there too because then you can debug virtio-net+tap with full offload enabled (which you cannot do today). Regards, Anthony Liguori Care taking on it? I never even heard about -net dump before today.
Re: [Qemu-devel] [PATCH] Fix and simplify gui timer logic.
On 06/08/10 13:50, Paul Brook wrote: Kill nographic timer. Have a global gui_timer instead. Have the gui timer enabled unconditionally. We need a timer running anyway for mmio flush, so the whole have-gui-timer-only-when-needed logic is pretty pointless. It also simplifies displaylisteners coming and going at runtime, we don't need to care about the timer then as it runs anyway. Linking mmio flushes to the gui is completely bogus. The fact that we're doing arbitrary periodic mmio flushes suggests something else is horribly broken. Was added by commit http://git.qemu.org/qemu.git/commit/?id=62a2744ca09a0b44b8406ea0c430c4c67a2 c3231 Patch description makes sense to me. Of course we could have a separate timer for the mmio flushes instead of re-using the gui timer. But we would have more wakeups then ... This suggests we are incorrectly coalescing writes, and we should actually be notifying qemu when (at least) he first write occurs. If we aren't outputting anything we don't want to be waking up periodically just to flush an empty MMIO buffer. That is completely unrelated to this patch though. The patch doesn't change mmio flush behaviour at all. And the periodic wakeup was there even before the mmio flush patch was added. Even without gui, although I can't see a obvious reason for it ... cheers, Gerd
Re: [Qemu-devel] [PATCH 10/22] machine: allow boards to specify default values and use it in isapc
On 06/08/10 15:09, Anthony Liguori wrote:
On 06/08/2010 03:03 AM, Gerd Hoffmann wrote:
+ .opts_default = (QemuOptValue[]) {
+ {
+ .name = acpi,
+ .value = on,
+ },
Should be moved into a separate struct and just referenced as it is
identical for pc-0.*
Would need to be macros because in future patches, things get more
complicated. That may be worth it though.
Well, maybe not. Later patches add the compat properties to that list,
which are different for the pc-0.* versions, so you would have to split
again ...
cheers
Gerd
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On Tue, Jun 08, 2010 at 08:02:27AM -0500, Anthony Liguori wrote: On 06/08/2010 06:09 AM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: So I see two ways to go forward: switch default value in my patch, or disable vlans unconditionally. The problem with disabling vlans unconditionally is that you break -net socket and -net dump. -netdev socket seems to be supported. No? Sure, but it's of limited utility in the absence of vlans. A typical thing to do with -net socket would be to launch one instance of qemu with -net user, -net socket, and -net nic. Another qemu would be launched with -net socket and -net nic connected to the previous instance. Now you've got a working virtual network with external access. Only terribly slow, esp when tunneling tcp over tcp. -netdev socket alone won't get you this. -socket should really support udp. Then you could get what you wanted with halfway decent speed using multicast. Regards, Anthony Liguori
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
On 06/08/2010 04:28 PM, Peter Lieven wrote: i will retry the case later today and send info register output. what is the recommended value for nx (and why)? Enabled (so you get no-execute memory protection). do you have a guideline which flags should be identical to ensure proper live migration? i would like to do an automatic compare before life migration to avoid crashes. All of them [1]. If you have an asymmetric machine, you can disable those flags with the -cpu switch. Note the default qemu cpu disables many flags, so if one machine has sse4.2 and the other doesn't, migration will still work without disabling anything. [1] Rather, all flags understood by qemu and kvm that are enabled by the cpu model that you gave to qemu with -cpu. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
On 06/08/2010 04:44 PM, Peter Lieven wrote: -cpu host is good if you have identical machines and don't plan to add new ones. i will likely add new ones, but my plan would be to use qemu64 and then add all flags manually that are common to all cpus in the pool. would that be safe? Yes. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] Clarify error message when a PCI slot is already in use
When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not
available for virtio-balloon-pci, in use by rtl8139
The user does not configure 'devfn' numbers, they use slot+function.
Thus the error messages should be reported back to the user with that
same terminology rather than the internal QEMU terminology. This
patch makes it report:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu: -device virtio-balloon-pci,bus=pci.0,addr=0x3.7: PCI: slot 3 function 0
not available for virtio-balloon-pci, in use by rtl8139
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
hw/pci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index cbbd1dd..2347708 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -609,12 +609,12 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
if (!bus-devices[devfn])
goto found;
}
-error_report(PCI: no devfn available for %s, all in use, name);
+error_report(PCI: no slot/function available for %s, all in use,
name);
return NULL;
found: ;
} else if (bus-devices[devfn]) {
-error_report(PCI: devfn %d not available for %s, in use by %s,
- devfn, name, bus-devices[devfn]-name);
+error_report(PCI: slot %d function %d not available for %s, in use by
%s,
+ (devfn 3), (devfn % 8), name,
bus-devices[devfn]-name);
return NULL;
}
pci_dev-bus = bus;
--
1.6.6.1
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
Avi Kivity wrote: On 06/08/2010 04:38 PM, Peter Lieven wrote: Avi Kivity wrote: On 06/08/2010 04:28 PM, Peter Lieven wrote: i will retry the case later today and send info register output. what is the recommended value for nx (and why)? Enabled (so you get no-execute memory protection). do you have a guideline which flags should be identical to ensure proper live migration? i would like to do an automatic compare before life migration to avoid crashes. All of them [1]. If you have an asymmetric machine, you can disable those flags with the -cpu switch. Note the default qemu cpu disables many flags, so if one machine has sse4.2 and the other doesn't, migration will still work without disabling anything. which cpu model do you suggest for 4 core xeon cpus? -cpu host ? -cpu host is good if you have identical machines and don't plan to add new ones. i will likely add new ones, but my plan would be to use qemu64 and then add all flags manually that are common to all cpus in the pool. would that be safe? br, peter how important is the match of the virtualization extensions? The virtualization extensions on Intel aren't exposed to the guest, so they don't need to match. -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 .
Re: [Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
On 06/08/10 15:07, Anthony Liguori wrote:
Note that this reverses the ordering for users which want multiple
values (slirp forwarding for example).
And qemu_opt_find seems to have thought about this too:
static QemuOpt *qemu_opt_find(QemuOpts *opts, const char *name)
{
QemuOpt *opt;
QTAILQ_FOREACH_REVERSE(opt, opts-head, QemuOptHead, next) {
if (strcmp(opt-name, name) != 0)
continue;
return opt;
}
return NULL;
}
Can you show the behavior with commandline arguments only?
The problem I was trying to address can be seen with something like:
-drive file=foo.img,if=virtio,file=bar.img
You get no error, and foo.img is what gets used.
Hmm. I think qemuopts need to carry information about the option types,
whenever it is single-entry or multiple-entry.
Oh, and likewise for the sections. With multiple (unnamed) [device]
sections we want create multiple (id-less) device sections. With
multiple [machine] sections we probably want to merge the options instead.
Or more specifically:
foo.conf:
[drive]
file=foo.img
if=virtio
id=bar
This would be '[drive bar]' without id= line btw.
qemu -readconfig foo.conf -drive file=bar.img,id=bar
IMHO, what's specified next on the command line ought to override what's
in the config.
Or the user's config the global config.
For multi-entry options this will be tricky. What do you expect to
happen here:
global.conf
[net user]
type=slirp
guestfwd=fw1
user.conf
[net user]
guestfwd=fw2
guestfwd=fw3
Which forwardings will be active then? All of them? Or will the
user.conf forwardings override the global one?
cheers,
Gerd
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
Avi Kivity wrote: On 06/08/2010 04:28 PM, Peter Lieven wrote: i will retry the case later today and send info register output. what is the recommended value for nx (and why)? Enabled (so you get no-execute memory protection). do you have a guideline which flags should be identical to ensure proper live migration? i would like to do an automatic compare before life migration to avoid crashes. All of them [1]. If you have an asymmetric machine, you can disable those flags with the -cpu switch. Note the default qemu cpu disables many flags, so if one machine has sse4.2 and the other doesn't, migration will still work without disabling anything. which cpu model do you suggest for 4 core xeon cpus? -cpu host ? how important is the match of the virtualization extensions? thanks, peter [1] Rather, all flags understood by qemu and kvm that are enabled by the cpu model that you gave to qemu with -cpu. -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 .
[Qemu-devel] [PATCH v5] savevm: Really verify if a drive supports snapshots
Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.
First issue: Their names implies different porpouses, but they do the same thing
and have exactly the same code. Maybe copied and pasted and forgotten?
bdrv_has_snapshot() is called in various places for actually checking if there
is snapshots or not.
Second issue: the way bdrv_can_snapshot() verifies if a block driver supports or
not snapshots does not catch all cases. E.g.: a raw image.
So when do_savevm() is called, first thing it does is to set a global
BlockDriverState to save the VM memory state calling get_bs_snapshots().
static BlockDriverState *get_bs_snapshots(void)
{
BlockDriverState *bs;
DriveInfo *dinfo;
if (bs_snapshots)
return bs_snapshots;
QTAILQ_FOREACH(dinfo, drives, next) {
bs = dinfo-bdrv;
if (bdrv_can_snapshot(bs))
goto ok;
}
return NULL;
ok:
bs_snapshots = bs;
return bs;
}
bdrv_can_snapshot() may return a BlockDriverState that does not support
snapshots and do_savevm() goes on.
Later on in do_savevm(), we find:
QTAILQ_FOREACH(dinfo, drives, next) {
bs1 = dinfo-bdrv;
if (bdrv_has_snapshot(bs1)) {
/* Write VM state size only to the image that contains the state */
sn-vm_state_size = (bs == bs1 ? vm_state_size : 0);
ret = bdrv_snapshot_create(bs1, sn);
if (ret 0) {
monitor_printf(mon, Error while creating snapshot on '%s'\n,
bdrv_get_device_name(bs1));
}
}
}
bdrv_has_snapshot(bs1) is not checking if the device does support or has
snapshots as explained above. Only in bdrv_snapshot_create() the device is
actually checked for snapshot support.
So, in cases where the first device supports snapshots, and the second does not,
the snapshot on the first will happen anyways. I believe this is not a good
behavior. It should be an all or nothing process.
This patch addresses these issues by making bdrv_can_snapshot() actually do
what it must do and enforces better tests to avoid errors in the middle of
do_savevm(). bdrv_has_snapshot() is removed and replaced by bdrv_can_snapshot()
where appropriate.
bdrv_can_snapshot() was moved from savevm.c to block.c. It makes more sense to
me.
The loadvm_state() function was updated too to enforce that when loading a VM at
least all writable devices must support snapshots too.
Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
---
block.c | 17 +
block.h |1 +
savevm.c | 58 --
3 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/block.c b/block.c
index 39724c1..139feff 100644
--- a/block.c
+++ b/block.c
@@ -1652,6 +1652,23 @@ void bdrv_debug_event(BlockDriverState *bs,
BlkDebugEvent event)
/**/
/* handling of snapshots */
+int bdrv_can_snapshot(BlockDriverState *bs)
+{
+BlockDriver *drv = bs-drv;
+if (!drv || bdrv_is_removable(bs) || bdrv_is_read_only(bs)) {
+return 0;
+}
+
+if (!drv-bdrv_snapshot_create) {
+if (bs-file != NULL) {
+return bdrv_can_snapshot(bs-file);
+}
+return 0;
+}
+
+return 1;
+}
+
int bdrv_snapshot_create(BlockDriverState *bs,
QEMUSnapshotInfo *sn_info)
{
diff --git a/block.h b/block.h
index 756670d..acb327f 100644
--- a/block.h
+++ b/block.h
@@ -174,6 +174,7 @@ int bdrv_get_info(BlockDriverState *bs, BlockDriverInfo
*bdi);
const char *bdrv_get_encrypted_filename(BlockDriverState *bs);
void bdrv_get_backing_filename(BlockDriverState *bs,
char *filename, int filename_size);
+int bdrv_can_snapshot(BlockDriverState *bs);
int bdrv_snapshot_create(BlockDriverState *bs,
QEMUSnapshotInfo *sn_info);
int bdrv_snapshot_goto(BlockDriverState *bs,
diff --git a/savevm.c b/savevm.c
index af92ba2..9b41eff 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1575,22 +1575,6 @@ out:
return ret;
}
-/* device can contain snapshots */
-static int bdrv_can_snapshot(BlockDriverState *bs)
-{
-return (bs
-!bdrv_is_removable(bs)
-!bdrv_is_read_only(bs));
-}
-
-/* device must be snapshots in order to have a reliable snapshot */
-static int bdrv_has_snapshot(BlockDriverState *bs)
-{
-return (bs
-!bdrv_is_removable(bs)
-!bdrv_is_read_only(bs));
-}
-
static BlockDriverState *get_bs_snapshots(void)
{
BlockDriverState *bs;
@@ -1600,8 +1584,9 @@ static BlockDriverState *get_bs_snapshots(void)
return bs_snapshots;
QTAILQ_FOREACH(dinfo, drives, next) {
bs = dinfo-bdrv;
-if (bdrv_can_snapshot(bs))
+if (bdrv_can_snapshot(bs)) {
goto ok;
+}
}
return NULL;
ok:
@@ -1675,12 +1660,26 @@ void do_savevm(Monitor *mon, const QDict
[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2
On 06/08/2010 04:38 PM, Peter Lieven wrote: Avi Kivity wrote: On 06/08/2010 04:28 PM, Peter Lieven wrote: i will retry the case later today and send info register output. what is the recommended value for nx (and why)? Enabled (so you get no-execute memory protection). do you have a guideline which flags should be identical to ensure proper live migration? i would like to do an automatic compare before life migration to avoid crashes. All of them [1]. If you have an asymmetric machine, you can disable those flags with the -cpu switch. Note the default qemu cpu disables many flags, so if one machine has sse4.2 and the other doesn't, migration will still work without disabling anything. which cpu model do you suggest for 4 core xeon cpus? -cpu host ? -cpu host is good if you have identical machines and don't plan to add new ones. how important is the match of the virtualization extensions? The virtualization extensions on Intel aren't exposed to the guest, so they don't need to match. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 0/22] Refactor machine support
On 06/07/2010 10:12 PM, Paul Brook wrote: This series introduces a rather radical change in the way we deal with machine definitions in QEMU. I think we should aim to eliminate machine_register_core, and design appropriately. In particular I'd try and avoid adding options that become trivially redundant once you can easily change the device trees. Long term, I'd rather that machine_register_core started with a core device tree and manipulated from there. I'm undecided how much parameterisation it's worth trying to support in the device tree. IMO the current code has way too much magic, because creating a new variant involves hacking and rebuilding pc.c. I'm extremely tempted by the extreme approach of punting everything to an external device tree builder. i.e. remove automagical device reation altogether. If you want USB and 6 virtio disks then ask your device tree builder to create a machine description that includes pci-ohci and a bunch of virtio-blk-pci devices. The virtio-blk devices reference drives by id, so the same host configuration can be used with a scsi HBA. A small shell script should be sufficient to replicate the limited machine variants currently supported. This is not optimizing for the common case. The overwhelmingly common case is a user that makes small changes to a pre-supplied machine core in QEMU. The problem is that those small changes are not simple things like add a device or remove a device. They often require more complicated mapping logic like translate user supplied ram size to the following ram allocation layout. We cannot expect all users to specify an explicit ram layout. An external builder is a usability nightmare. It has to be something that is included as part of qemu proper and that's effectively what MachineCore's are. They are internal builders. That doesn't mean we shouldn't aim to support external builders. Everything that a MachineCore generates should be possible to generate via a config file statically. The problem with doing clever device tree generation/manipulation inside qemu is that for anything vaguely nonstandard you're likely to have to hack your own device tree anyway. Even ram allocation is nontrivial, e.g. the hole below 4G on the PC, and that's before you start with numa-like layouts. I'm 100% in agreement that a user should be able to specify the exact ram layout for a PC. However, I strongly disagree that a user should have to specify the explicit ram layout if they want to adjust the allocated ram for a guest. Relying on an external shell script would be a nightmare for users. What I think we want is MachineCore to only make use of interfaces that are available via the command line. IOW, things like qdev_create() and friends. On a similar note, I don't see any point having machine_create_from_core, we can just ship appropriate config files. I strongly agree. I didn't include that in this series because I was trying to keep this small and slightly less radical. It'll be a pain for people that don't regularly update their config file via a make install. Regards, Anthony Liguori Paul
[Qemu-devel] [PATCH] megasas: Update to version 1.01
This patch updates the megasas HBA emulation to version 1.01.
It fixes the following issues:
- Remove hand-crafted inquiry command
- Remove bounce-buffer for direct commands
- Implements qdev properties to set 'max_sge', 'max_cmds'.
- Implement JBOD mode
- Improve direct command handling
- Minor cleanups
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/hw/megasas.c b/hw/megasas.c
index 250c3fb..19569a8 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -40,38 +40,17 @@ do { fprintf(stderr, megasas: error: fmt , ##
__VA_ARGS__);} while (0)
#endif
/* Static definitions */
-#define MEGASAS_MAX_FRAMES 1000
-#define MEGASAS_MAX_SGE 8
-#define MEGASAS_MAX_LUNS 128
-
-/* Frame definitions */
-#define MEGASAS_FRAME_CMD_OFFSET 0x00
-#define MEGASAS_FRAME_SENSE_LEN_OFFSET 0x01
-#define MEGASAS_FRAME_CMD_STATUS_OFFSET0x02
-#define MEGASAS_FRAME_SCSI_STATUS_OFFSET 0x03
-#define MEGASAS_FRAME_TARGET_ID_OFFSET 0x04
-#define MEGASAS_FRAME_LUN_ID_OFFSET0x05
-#define MEGASAS_FRAME_CDB_LEN_OFFSET 0x06
-#define MEGASAS_FRAME_SGE_COUNT_OFFSET 0x07
-#define MEGASAS_FRAME_CONTEXT_OFFSET 0x08
-#define MEGASAS_FRAME_FLAGS_OFFSET 0x10
-#define MEGASAS_FRAME_XFER_LEN_OFFSET 0x14
-
-#define MEGASAS_DCMD_SGL_OFFSET0x28
-
-#define MEGASAS_PTHRU_SGL_OFFSET 0x30
-
-#define MEGASAS_IO_SGL_OFFSET 0x28
+#define MEGASAS_VERSION 1.01
+#define MEGASAS_MAX_FRAMES 2048/* Firmware limit at 65535 */
+#define MEGASAS_DEFAULT_FRAMES 1000/* Windows requires this */
+#define MEGASAS_MAX_SGE 255/* Firmware limit */
+#define MEGASAS_DEFAULT_SGE 80
+#define MEGASAS_MAX_ARRAYS 128
const char *mfi_frame_desc[] = {
MFI init, LD Read, LD Write, LD SCSI, PD SCSI,
MFI Doorbell, MFI Abort, MFI SMP, MFI Stop};
-struct megasas_lun_t {
-SCSIDevice *sdev;
-BlockDriverAIOCB *aiocb;
-};
-
struct megasas_cmd_t {
int index;
@@ -81,8 +60,8 @@ struct megasas_cmd_t {
QEMUSGList sg;
void *iov_buf;
long iov_size;
+SCSIDevice *sdev;
struct megasas_state_t *state;
-struct megasas_lun_t *lun;
};
typedef struct megasas_state_t {
@@ -93,12 +72,14 @@ typedef struct megasas_state_t {
uint32_t frame_hi;
int fw_state;
-int fw_sge;
-int fw_cmds;
+uint32_t fw_sge;
+uint32_t fw_cmds;
int fw_luns;
int intr_mask;
int doorbell;
int busy;
+char *raid_mode_str;
+int is_jbod;
int event_count;
int shutdown_event;
@@ -113,8 +94,6 @@ typedef struct megasas_state_t {
struct megasas_cmd_t frames[MEGASAS_MAX_FRAMES];
-struct megasas_lun_t luns[MEGASAS_MAX_LUNS];
-
SCSIBus bus;
} MPTState;
@@ -123,13 +102,19 @@ typedef struct megasas_state_t {
#define MEGASAS_INTR_ENABLED(s) (((s)-intr_mask MEGASAS_INTR_DISABLED_MASK
) != MEGASAS_INTR_DISABLED_MASK)
#define megasas_frame_set_cmd_status(f,v) \
-stb_phys((f) + MEGASAS_FRAME_CMD_STATUS_OFFSET, v);
+stb_phys((f) + offsetof(struct mfi_frame_header, cmd_status), v);
#define megasas_frame_set_sense_len(f,v) \
-stb_phys((f) + MEGASAS_FRAME_SENSE_LEN_OFFSET, v);
+stb_phys((f) + offsetof(struct mfi_frame_header, sense_len), v);
#define megasas_frame_set_scsi_status(f,v) \
-stb_phys((f) + MEGASAS_FRAME_SCSI_STATUS_OFFSET, v);
+stb_phys((f) + offsetof(struct mfi_frame_header, scsi_status), v);
+
+#define megasas_frame_get_cmd(f) \
+ldub_phys((f) + offsetof(struct mfi_frame_header, frame_cmd))
+
+#define megasas_frame_get_context(f) \
+ldl_phys(frame_addr + offsetof(struct mfi_frame_header, context));
static void megasas_soft_reset(MPTState *s);
@@ -181,37 +166,20 @@ static void megasas_build_sense(struct megasas_cmd_t
*cmd, SCSISense sense)
qemu_free(sense_ptr);
}
-static int megasas_get_inq(SCSIDevice *sdev, int pg, uint8_t *buf, int buflen)
-{
-SCSIBus *bus = DO_UPCAST(SCSIBus, qbus, sdev-qdev.parent_bus);
-
-memset(buf, 0, buflen);
-if (pg == 0) {
- memcpy(buf[16], QEMU HARDDISK , 16);
- memcpy(buf[8], QEMU , 8);
- memcpy(buf[32], QEMU_VERSION, 4);
- /* Identify device as SCSI-3 rev 1 */
- buf[2] = 3;
- buf[3] = 2; /* Format 2 */
- buf[4] = buflen - 5; /* Additional Length = (Len - 1) - 4 */
- /* Sync data transfer and TCQ. */
- buf[7] = 0x10 | (bus-tcq ? 0x02 : 0);
-} else if (pg == 0x83) {
- int id_len = strlen(bdrv_get_device_name(sdev-conf.dinfo-bdrv));
-
- buflen = 0;
- buf[buflen++] = 0;
- buf[buflen++] = pg;
- buf[buflen++] = 0x00;
- buf[buflen++] = 3 + id_len;
- buf[buflen++] = 0x2; // ASCII
- buf[buflen++] = 0; // not officially assigned
- buf[buflen++] = 0; // reserved
- buf[buflen++] = id_len; // length of data following
-
[Qemu-devel] Re: [PATCH v5] savevm: Really verify if a drive supports snapshots
Am 08.06.2010 15:40, schrieb Miguel Di Ciurcio Filho:
Both bdrv_can_snapshot() and bdrv_has_snapshot() does not work as advertized.
First issue: Their names implies different porpouses, but they do the same
thing
and have exactly the same code. Maybe copied and pasted and forgotten?
bdrv_has_snapshot() is called in various places for actually checking if there
is snapshots or not.
Second issue: the way bdrv_can_snapshot() verifies if a block driver supports
or
not snapshots does not catch all cases. E.g.: a raw image.
So when do_savevm() is called, first thing it does is to set a global
BlockDriverState to save the VM memory state calling get_bs_snapshots().
static BlockDriverState *get_bs_snapshots(void)
{
BlockDriverState *bs;
DriveInfo *dinfo;
if (bs_snapshots)
return bs_snapshots;
QTAILQ_FOREACH(dinfo, drives, next) {
bs = dinfo-bdrv;
if (bdrv_can_snapshot(bs))
goto ok;
}
return NULL;
ok:
bs_snapshots = bs;
return bs;
}
bdrv_can_snapshot() may return a BlockDriverState that does not support
snapshots and do_savevm() goes on.
Later on in do_savevm(), we find:
QTAILQ_FOREACH(dinfo, drives, next) {
bs1 = dinfo-bdrv;
if (bdrv_has_snapshot(bs1)) {
/* Write VM state size only to the image that contains the state
*/
sn-vm_state_size = (bs == bs1 ? vm_state_size : 0);
ret = bdrv_snapshot_create(bs1, sn);
if (ret 0) {
monitor_printf(mon, Error while creating snapshot on '%s'\n,
bdrv_get_device_name(bs1));
}
}
}
bdrv_has_snapshot(bs1) is not checking if the device does support or has
snapshots as explained above. Only in bdrv_snapshot_create() the device is
actually checked for snapshot support.
So, in cases where the first device supports snapshots, and the second does
not,
the snapshot on the first will happen anyways. I believe this is not a good
behavior. It should be an all or nothing process.
This patch addresses these issues by making bdrv_can_snapshot() actually do
what it must do and enforces better tests to avoid errors in the middle of
do_savevm(). bdrv_has_snapshot() is removed and replaced by
bdrv_can_snapshot()
where appropriate.
bdrv_can_snapshot() was moved from savevm.c to block.c. It makes more sense
to me.
The loadvm_state() function was updated too to enforce that when loading a VM
at
least all writable devices must support snapshots too.
Signed-off-by: Miguel Di Ciurcio Filho miguel.fi...@gmail.com
Thanks, I updated the patch in the block branch. Let's hope we've got it
correct this time.
Kevin
Re: [Qemu-devel] [PATCH] Clarify error message when a PCI slot is already in use
On Tue, Jun 08, 2010 at 02:58:25PM +0100, Daniel P. Berrange wrote:
When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not
available for virtio-balloon-pci, in use by rtl8139
The user does not configure 'devfn' numbers, they use slot+function.
Thus the error messages should be reported back to the user with that
same terminology rather than the internal QEMU terminology. This
patch makes it report:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu: -device virtio-balloon-pci,bus=pci.0,addr=0x3.7: PCI: slot 3 function 0
not available for virtio-balloon-pci, in use by rtl8139
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
hw/pci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index cbbd1dd..2347708 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -609,12 +609,12 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
if (!bus-devices[devfn])
goto found;
}
-error_report(PCI: no devfn available for %s, all in use, name);
+error_report(PCI: no slot/function available for %s, all in use,
name);
return NULL;
found: ;
} else if (bus-devices[devfn]) {
-error_report(PCI: devfn %d not available for %s, in use by %s,
- devfn, name, bus-devices[devfn]-name);
+error_report(PCI: slot %d function %d not available for %s, in use
by %s,
+ (devfn 3), (devfn % 8), name,
bus-devices[devfn]-name);
Please use PCI_SLOT() and PCI_FUNC().
return NULL;
}
pci_dev-bus = bus;
--
1.6.6.1
--
yamahata
[Qemu-devel] [PATCH] Clarify error message when a PCI slot is already in use (v2)
When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not
available for virtio-balloon-pci, in use by rtl8139
The user does not configure 'devfn' numbers, they use slot+function.
Thus the error messages should be reported back to the user with that
same terminology rather than the internal QEMU terminology. This
patch makes it report:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu: -device virtio-balloon-pci,bus=pci.0,addr=0x3.7: PCI: slot 3 function 0
not available for virtio-balloon-pci, in use by rtl8139
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
hw/pci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index cbbd1dd..cd7ce8d 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -609,12 +609,12 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
if (!bus-devices[devfn])
goto found;
}
-error_report(PCI: no devfn available for %s, all in use, name);
+error_report(PCI: no slot/function available for %s, all in use,
name);
return NULL;
found: ;
} else if (bus-devices[devfn]) {
-error_report(PCI: devfn %d not available for %s, in use by %s,
- devfn, name, bus-devices[devfn]-name);
+error_report(PCI: slot %d function %d not available for %s, in use by
%s,
+ PCI_SLOT(devfn), PCI_FUNC(devfn), name,
bus-devices[devfn]-name);
return NULL;
}
pci_dev-bus = bus;
--
1.6.6.1
Re: [Qemu-devel] [PATCH] Clarify error message when a PCI slot is already in use
On Tue, Jun 08, 2010 at 11:16:48PM +0900, Isaku Yamahata wrote:
On Tue, Jun 08, 2010 at 02:58:25PM +0100, Daniel P. Berrange wrote:
When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not
available for virtio-balloon-pci, in use by rtl8139
The user does not configure 'devfn' numbers, they use slot+function.
Thus the error messages should be reported back to the user with that
same terminology rather than the internal QEMU terminology. This
patch makes it report:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu: -device virtio-balloon-pci,bus=pci.0,addr=0x3.7: PCI: slot 3 function
0 not available for virtio-balloon-pci, in use by rtl8139
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
hw/pci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index cbbd1dd..2347708 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -609,12 +609,12 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
if (!bus-devices[devfn])
goto found;
}
-error_report(PCI: no devfn available for %s, all in use, name);
+error_report(PCI: no slot/function available for %s, all in use,
name);
return NULL;
found: ;
} else if (bus-devices[devfn]) {
-error_report(PCI: devfn %d not available for %s, in use by %s,
- devfn, name, bus-devices[devfn]-name);
+error_report(PCI: slot %d function %d not available for %s, in
use by %s,
+ (devfn 3), (devfn % 8), name,
bus-devices[devfn]-name);
Please use PCI_SLOT() and PCI_FUNC().
Thanks for the pointer. I've resent the patch with that change
Daniel
--
|: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On 06/08/10 15:02, Anthony Liguori wrote: On 06/08/2010 06:09 AM, Michael S. Tsirkin wrote: On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: So I see two ways to go forward: switch default value in my patch, or disable vlans unconditionally. The problem with disabling vlans unconditionally is that you break -net socket and -net dump. -netdev socket seems to be supported. No? Sure, but it's of limited utility in the absence of vlans. A typical thing to do with -net socket would be to launch one instance of qemu with -net user, -net socket, and -net nic. Another qemu would be launched with -net socket and -net nic connected to the previous instance. Now you've got a working virtual network with external access. -netdev socket alone won't get you this. I see three possible options to handle this. (1) Write a hub (or morph the current vlan code into this). Then you can do something like: qemu -netdev socket,id=p1 \ -netdev user,id=p2 \ -netdev dump,id=p3 \ -switch peer=p1,peer=p2,monitor=p3,port=p4 \ -device $nic,netdev=p4 (2) Implement the same as external daemon which can be combined with -netdev socket. (3) Just point people who need this to the various virtual switch projects (vde, ...) they can use and drop vlan. cheers, Gerd
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
I'm undecided how much parameterisation it's worth trying to support in the device tree. IMO the current code has way too much magic, because creating a new variant involves hacking and rebuilding pc.c. See patch 22/22. There is really no magic involved, even though the compat machines are not yet as config files. The magic I'm preferring to is precisely things like pci=on. This is an artifact of only having a hardcoded single device tree (defined by pc_init), so we need magic parameters to pick between different variants. If this were just a cleanup of how we implement the various machines that would be harmless. However these are now a user-visible interface. It implies that qemu is expected to know how to add/remove PCI capabilities from a machine. Once you eliminate machine_register_core that knowledge has somehow got to come from your device tree description file. Having a single device tree that can morph into significantly different machines seems like unnecessary complexity given this is a user-specified file. I'm extremely tempted by the extreme approach of punting everything to an external device tree builder. i.e. remove automagical device reation altogether. I think this should have been raised when the -readconfig/-writeconfig scheme was proposed and committed. I don't think it's reasonable to block this patch series (or something very much like it) on the grounds that a better device tree description model than QemuOpts can be designed. I don't see how the introduction of QemuOpts is relevant. That's just a flexible commandline option handling system, which makes a lot of sense. What I'm objecting to is making machine construction be controlled by an arbitrary set of hardcoded parameters. One of the goals of the qdev work is that you don't need to have hardcoded all the interesting ways a machine can vary. Instead you can directly specify how to construct the machine. My argument is that in the short term this parameterization provides limited benefit, and longer term it's going to be obsolete and probably painful to support. Paul
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
I see three possible options to handle this. (1) Write a hub (or morph the current vlan code into this). Then you can do something like: qemu -netdev socket,id=p1 \ -netdev user,id=p2 \ -netdev dump,id=p3 \ -switch peer=p1,peer=p2,monitor=p3,port=p4 \ -device $nic,netdev=p4 (2) Implement the same as external daemon which can be combined with -netdev socket. (3) Just point people who need this to the various virtual switch projects (vde, ...) they can use and drop vlan. (2) is just a special case of (3), where we decide that the existing implementations suck and go write our own. Paul
Re: [Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
The problem I was trying to address can be seen with something like: -drive file=foo.img,if=virtio,file=bar.img You get no error, and foo.img is what gets used. It's fair to argue this is a silly use case but what I'm trying to achieve is to make it possible to do: -drive file=foo.img,if=virtio,id=bar -drive file=bar.img,id=bar IMO these should both behave consistently. I'd prefer that both of are errors. Paul
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
The magic I'm preferring to is precisely things like pci=on. Hmm, pci=on is magic indeed. :-) What I'm objecting to is making machine construction be controlled by an arbitrary set of hardcoded parameters. My argument is that in the short term this parameterization provides limited benefit, and longer term it's going to be obsolete and probably painful to support. Then it would be enough to have these options available internally for use in the machine-core but not export them to the command-line. If we only aim at using management interfaces to use the interface we can be very conservative and not export even things like default_drive. Paolo
Re: [Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
On 06/08/2010 09:38 AM, Paul Brook wrote: The problem I was trying to address can be seen with something like: -drive file=foo.img,if=virtio,file=bar.img You get no error, and foo.img is what gets used. It's fair to argue this is a silly use case but what I'm trying to achieve is to make it possible to do: -drive file=foo.img,if=virtio,id=bar -drive file=bar.img,id=bar IMO these should both behave consistently. I'd prefer that both of are errors. It's fairly common that the last specified argument is what's respected. For instance, if you do qemu -m 512M -m 1G, you'll get 1G of memory. Regards, Anthony Liguori Paul
[Qemu-devel] [PATCH] net: Fix hotplug with pci_add
The correct model type wasn't getting added when hotplugging nics with
pci_add.
Testcase: start VM with default nic type. In the qemu_monitor:
(qemu) pci_add auto nic model=virtio
This results in a nic hot-plug of the same nic type as the default.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
net.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net.c b/net.c
index efa8b3d..ca421ed 100644
--- a/net.c
+++ b/net.c
@@ -1106,6 +1106,7 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
for (i = 0; net_client_types[i].type != NULL; i++) {
if (!strcmp(net_client_types[i].type, type)) {
VLANState *vlan = NULL;
+int ret;
if (qemu_opts_validate(opts, net_client_types[i].desc[0]) == -1) {
return -1;
@@ -1119,13 +1120,14 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
}
if (net_client_types[i].init) {
-if (net_client_types[i].init(opts, mon, name, vlan) 0) {
+ret = net_client_types[i].init(opts, mon, name, vlan);
+if (ret 0) {
/* TODO push error reporting into init() methods */
qerror_report(QERR_DEVICE_INIT_FAILED, type);
return -1;
}
}
-return 0;
+return ret;
}
}
--
1.7.0.1
[Qemu-devel] [RFC PATCH 1/2] USB Video Class device emulation.
Signed-off-by: Natalia Portillo clau...@claunia.com
---
hw/usb-uvc.c | 1096 ++
1 files changed, 1096 insertions(+), 0 deletions(-)
create mode 100644 hw/usb-uvc.c
diff --git a/hw/usb-uvc.c b/hw/usb-uvc.c
new file mode 100644
index 000..b711f51
--- /dev/null
+++ b/hw/usb-uvc.c
@@ -0,0 +1,1096 @@
+/*
+ * USB Video Class Device emulation.
+ *
+ * Copyright (c) 2010 Claunia.com
+ * Written by Natalia Portillo nata...@claunia.com
+ *
+ * Based on hw/usb-hid.c:
+ * Copyright (c) 2005 Fabrice Bellard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation in its version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ */
+#include hw.h
+#include console.h
+#include usb.h
+#include qemu-error.h
+#include stdio.h
+#include fcntl.h
+#include errno.h
+// V4L2 ioctls
+#include sys/ioctl.h
+#include linux/videodev2.h
+
+#define DEBUG_UVC
+
+#ifdef DEBUG_UVC
+#define DPRINTF(fmt, ...) \
+do { printf(usb-uvc: fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while(0)
+#endif
+
+/* USB Video Class Request codes */
+#define USB_UVC_RC_UNDEFINED 0x00
+#define USB_UVC_SET_CUR0x01
+#define USB_UVC_GET_CUR0x81
+#define USB_UVC_GET_MIN0x82
+#define USB_UVC_GET_MAX0x83
+#define USB_UVC_GET_RES0x84
+#define USB_UVC_GET_LEN0x85
+#define USB_UVC_GET_INFO 0x86
+#define USB_UVC_GET_DEF0x87
+
+/* USB Video Class Request types */
+#define UVCSetVideoControl 0x2100
+#define UVCSetVideoStreaming 0x2200
+#define UVCGetVideoControl 0xA100
+#define UVCGetVideoStreaming 0xA200
+
+typedef struct USBUVCState {
+USBDevice dev;
+ charcurrent_input;
+ char*v4l2_device;
+} USBUVCState;
+
+static int v4l2_fd;
+static char *frame;
+static char *frame_start;
+static int frame_length;
+static int frame_id;
+static int first_bulk_packet;
+static int frame_remaining_bytes;
+static int frame_max_length;
+
+static const uint8_t qemu_uvc_dev_descriptor[] = {
+ 0x12, /* u8 bLength; */
+ 0x01, /* u8 bDescriptorType; Device */
+ 0x00, 0x02, /* u16 bcdUSB; v2.0 */
+
+ 0xEF, /* u8 bDeviceClass; */
+ 0x02, /* u8 bDeviceSubClass; */
+ 0x01, /* u8 bDeviceProtocol; [ low/full speeds only ] */
+ 0x08, /* u8 bMaxPacketSize0; 8 Bytes */
+
+ /* Vendor and product id are arbitrary. */
+ 0x00, 0x00, /* u16 idVendor; */
+ 0x00, 0x00, /* u16 idProduct; */
+ 0x00, 0x00, /* u16 bcdDevice */
+
+ 0x01, /* u8 iManufacturer; */
+ 0x02, /* u8 iProduct; */
+ 0x00, /* u8 iSerialNumber; */
+ 0x01/* u8 bNumConfigurations; */
+};
+
+static const uint8_t qemu_uvc_config_descriptor[] = {
+
+ /* one configuration */
+ 0x09, /* u8 bLength; */
+ 0x02, /* u8 bDescriptorType; Configuration */
+ 0xB7, 0x00, /* u16 wTotalLength; */
+ 0x02, /* u8 bNumInterfaces; (2) */
+ 0x01, /* u8 bConfigurationValue; */
+ 0x00, /* u8 iConfiguration; */
+ 0x80, /* u8 bmAttributes;
+Bit 7: must be set,
+6: Self-powered,
+5: Remote wakeup,
+4..0: resvd */
+ 0xFA, /* u8 MaxPower; */
+
+ /* interface association */
+ 0x08, /* u8 ifa_bLength; */
+ 0x0B, /* u8 ifa_bDescriptorType; Interface Association */
+ 0x00, /* u8 ifa_bFirstInterface; */
+ 0x02, /* u8 ifa_bInterfaceCount; */
+ 0x0E, /* u8 ifa_bFunctionClass; CC_VIDEO */
+ 0x03, /* u8 ifa_bFunctionSubClass;
SS_VIDEO_INTERFACE_COLLECTION */
+ 0x00, /* u8 ifa_bFunctionProtocol; unused */
+ 0x02, /* u8 ifa_iFunction; */
+
+ /* video control interface */
+ 0x09, /* u8 if_bLength; */
+ 0x04, /* u8 if_bDescriptorType; Interface */
+ 0x00, /* u8 if_bInterfaceNumber; */
+ 0x00, /* u8 if_bAlternateSetting; */
+ 0x01, /* u8 if_bNumEndpoints; */
+ 0x0E, /* u8 if_bInterfaceClass; CC_VIDEO */
[Qemu-devel] [RFC PATCH 2/2] Adds device to Makefile.
Signed-off-by: Natalia Portillo clau...@claunia.com --- Makefile.objs |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 110f8fd..1535b61 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -70,6 +70,7 @@ common-obj-y += scsi-disk.o cdrom.o common-obj-y += scsi-generic.o scsi-bus.o common-obj-y += usb.o usb-hub.o usb-$(HOST_USB).o usb-hid.o usb-msd.o usb-wacom.o common-obj-y += usb-serial.o usb-net.o usb-bus.o +common-obj-$(CONFIG_LINUX) += usb-uvc.o common-obj-$(CONFIG_SSI) += ssi.o common-obj-$(CONFIG_SSI_SD) += ssi-sd.o common-obj-$(CONFIG_SD) += sd.o --
Re: [Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
What'd expect is: [net user] guestfwd = fw1 fw2 fw3.. I think multiple entry options are probably not a good thing to have. We already have them though (-net switch so QemuOpts added them). cheers, Gerd
[Qemu-devel] [RFC PATCH 0/2] Add USB Video Class device emulation.
Hi, This currently adds an emulated USB webcam compliant with USB Video Class Specification 1.0a. It only works on Linux guests and feeds the emulated device using a Video4Linux 2 host device, as long as it supports 320x240 MJPEG format. This is a Request for Comments as surely code needs some cleaning or style. You can see it working here: http://www.youtube.com/watch?v=fzGYvjZzx6E with Linux guest http://www.youtube.com/watch?v=_Yo9TWPDXCo with Windows XP Home guest To add the device use -device usb-uvc-webcam,device=path to v4l2 device Regards, Natalia Portillo
[Qemu-devel] [PATCH v2] net: Fix hotplug with pci_add
The correct model type wasn't getting added when hotplugging nics with
pci_add.
Testcase: start VM with default nic type. In the qemu_monitor:
(qemu) pci_add auto nic model=virtio
This results in a nic hot-plug of the same nic type as the default.
This was broken in 5294e2c774f120e10b44652ac143abda356f44eb
Also changes the behaviour where no .init is defined for a
net_client_type. Previously, 0 was returned, which indicated the init
was successful and that 0 was the index into the nd_tables[] array.
Return -1, indicating unsuccessful init, in such a case.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
Sorry, v1 was a stale patch.
v2:
- Init 'ret' to -1, fixes compile err and added note in the commit msg
explaining this.
net.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net.c b/net.c
index efa8b3d..4cb93ed 100644
--- a/net.c
+++ b/net.c
@@ -1106,6 +1106,7 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
for (i = 0; net_client_types[i].type != NULL; i++) {
if (!strcmp(net_client_types[i].type, type)) {
VLANState *vlan = NULL;
+int ret;
if (qemu_opts_validate(opts, net_client_types[i].desc[0]) == -1) {
return -1;
@@ -1118,14 +1119,16 @@ int net_client_init(Monitor *mon, QemuOpts *opts, int
is_netdev)
vlan = qemu_find_vlan(qemu_opt_get_number(opts, vlan, 0), 1);
}
+ret = -1;
if (net_client_types[i].init) {
-if (net_client_types[i].init(opts, mon, name, vlan) 0) {
+ret = net_client_types[i].init(opts, mon, name, vlan);
+if (ret 0) {
/* TODO push error reporting into init() methods */
qerror_report(QERR_DEVICE_INIT_FAILED, type);
return -1;
}
}
-return 0;
+return ret;
}
}
--
1.7.0.1
[Qemu-devel] Re: [PATCH v2] net: Fix hotplug with pci_add
Amit Shah amit.s...@redhat.com wrote: The correct model type wasn't getting added when hotplugging nics with pci_add. Testcase: start VM with default nic type. In the qemu_monitor: (qemu) pci_add auto nic model=virtio This results in a nic hot-plug of the same nic type as the default. This was broken in 5294e2c774f120e10b44652ac143abda356f44eb Also changes the behaviour where no .init is defined for a net_client_type. Previously, 0 was returned, which indicated the init was successful and that 0 was the index into the nd_tables[] array. Return -1, indicating unsuccessful init, in such a case. Signed-off-by: Amit Shah amit.s...@redhat.com --- Sorry, v1 was a stale patch. v2: - Init 'ret' to -1, fixes compile err and added note in the commit msg explaining this. net.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) Acked-by: Juan Quintela quint...@redhat.com
[Qemu-devel] [Bug 591320] [NEW] [ARM]: SIMD add/sub instructions are incorrect
Public bug reported: The thumb2 and unsigned arm state SIMD add/sub instructions are implemented incorrectly, for example: UQSUB8 r0, r1, r0 gives r0 as 0, where r0 is 0x12345678 and r1 is 0x23456789 in ARM state, and: UHSUB8 r0, r1, r0 gives r0 as 0xbe01, where r0 is 0x12345678 and r1 is 0x23456789 in thumb2 state. This problem is present in git HEAD, (at time of writing, fd1dc858370d9a9ac7ea2512812c3a152ee6484b). ** Affects: qemu Importance: Undecided Status: New -- [ARM]: SIMD add/sub instructions are incorrect https://bugs.launchpad.net/bugs/591320 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: The thumb2 and unsigned arm state SIMD add/sub instructions are implemented incorrectly, for example: UQSUB8 r0, r1, r0 gives r0 as 0, where r0 is 0x12345678 and r1 is 0x23456789 in ARM state, and: UHSUB8 r0, r1, r0 gives r0 as 0xbe01, where r0 is 0x12345678 and r1 is 0x23456789 in thumb2 state. This problem is present in git HEAD, (at time of writing, fd1dc858370d9a9ac7ea2512812c3a152ee6484b).
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
On 06/08/2010 05:36 PM, Paul Brook wrote:
Once you eliminate machine_register_core that knowledge has
somehow got to come from your device tree description file. Having a
single device tree that can morph into significantly different machines
seems like unnecessary complexity given this is a user-specified file.
99% of qemu users will never touch a device tree. The practical matter
is, we're going to have to provide higher level interfaces that allow a
user to significantly morph a base device tree into something different.
That's the bit I don't get. Why are we significantly morphing a base device
tree? Surely it's easier to just use a different base tree.
Because at some point the base tree will have to be written in C. Of
course you have to decide where to stop allowing customization, but
anyway it will be significantly more complex than a QemuOpts config
file. QemuOpts obviously doesn't have the flexibility to create an
entire device tree.
Want to let the user add an IDE controller? Fine, you need to provide
him with a way of writing the following logic:
for(i = 0; i MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
hd[i] = drive_get(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
}
pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
What do you do? Invent your own language (another YaST? no thanks)?
Massive refactoring of QEMU's bowels (cannot solve all the problems,
Anthony gave more examples in the email I replied to)? Keep C code
(then you're not doing anything different than what Anthony's
MachineCore is doing)?
I think there are four choices:
1) only merge the first 5-7 patches of the series, basically up to the
creation of -machine and conversion of -kernel/-initrd/-M/-m. This is
also what is needed for KVM's irqchip. Think about some other smart way
to implement default devices.
2) do not expose some things to the config files. This requires
implementing an additional QemuOpts feature for internal options, plus
the current patchset. It means that moving machine types out to config
files is not possible.
3) put some things into an implementation-dependent namespace, i.e.
__pci or __default_device or __serial. In the future it's possible to
these things in config files, just nobody has to worry about users
relying on them and can refactor to death. This is the current patchset
plus some search and replace, and is my favorite.
4) expose everything to the user, at the cost of regretting it later.
This is the current patchset.
One smart way to implement default devices could be an inclusion
mechanism where a machine can ask qemu to read other config files. Then
you'd have config files for the default serial/parallel/etc. This could
also be implemented on top of choices 2/3/4 though.
Paolo
[Qemu-devel] KVM call minutes for June 8
Accelerating counters (aka moving PIT to userspace, keeping HPET in userspace) - PIT (in-kernel, userspace, or split) - userspace PIT, too slow - kernel PIT (already seen bugs) - split PIT, not realistic w/out a sane interface (see bugs above) - exit to userspace is a base cost, add MSR save/restore, add qemu overhead...and exit to userspace is expensive - hpet in userspace (at least minimal counter reading) - ioapic - less than half is architectural, more than half endds of being interrupt reinjection Live migration + hotplug - start a machine, hotplug device, allocate ram...can't migrate - last_offset and ramblock sections coming from cmdline may not be compatible w/ hotplug - worst case is different ramblock order and data corruption - alex has patches to convert ramblocks into queuelist - give name, offset - will clean up and send out today migration events? - QMP (wire protocol) has nice async events - QError reasonable - migration is async command, can complete w/ error or success - QMP broken for error - need context for error, default is monitor, but async command - redo qerror_report, propagate error (or always have error context available) - monitor and qmp done w/ same dispatch functions - should do monitor in terms of qmp - every qerror replacing monitor printf error - ends up not sharing enough ($foo not found, where $foo is contextual) - async command (pass in command completion) - may have to do limited (throw away for 0.13 and redo properly for 0.14) - anthony has a (not fully working) tree, and will document direction on wiki migration subsections. - stable IDE version 3 is different for = 0.12.2 than 0.12.2 - for stable could bump to version 4, blacklist version 3 - unstable IDE version 4, works APIC wiring problems (attached slides) - postponed until tomorrow's code overview slot
Re: [Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
On 06/08/2010 08:44 AM, Gerd Hoffmann wrote:
On 06/08/10 15:07, Anthony Liguori wrote:
Note that this reverses the ordering for users which want multiple
values (slirp forwarding for example).
And qemu_opt_find seems to have thought about this too:
static QemuOpt *qemu_opt_find(QemuOpts *opts, const char *name)
{
QemuOpt *opt;
QTAILQ_FOREACH_REVERSE(opt, opts-head, QemuOptHead, next) {
if (strcmp(opt-name, name) != 0)
continue;
return opt;
}
return NULL;
}
Can you show the behavior with commandline arguments only?
The problem I was trying to address can be seen with something like:
-drive file=foo.img,if=virtio,file=bar.img
You get no error, and foo.img is what gets used.
Hmm. I think qemuopts need to carry information about the option
types, whenever it is single-entry or multiple-entry.
Oh, and likewise for the sections. With multiple (unnamed) [device]
sections we want create multiple (id-less) device sections. With
multiple [machine] sections we probably want to merge the options
instead.
Or more specifically:
foo.conf:
[drive]
file=foo.img
if=virtio
id=bar
This would be '[drive bar]' without id= line btw.
qemu -readconfig foo.conf -drive file=bar.img,id=bar
IMHO, what's specified next on the command line ought to override what's
in the config.
Or the user's config the global config.
For multi-entry options this will be tricky. What do you expect to
happen here:
global.conf
[net user]
type=slirp
guestfwd=fw1
user.conf
[net user]
guestfwd=fw2
guestfwd=fw3
Which forwardings will be active then? All of them? Or will the
user.conf forwardings override the global one?
What'd expect is:
[net user]
guestfwd = fw1 fw2 fw3..
I think multiple entry options are probably not a good thing to have.
Regards,
Anthony Liguori
cheers,
Gerd
Re: [Qemu-devel] Re: [PATCH 01/22] QemuOpts: fix a bug in QemuOpts when setting an option twice
On 06/08/2010 10:37 AM, Gerd Hoffmann wrote: What'd expect is: [net user] guestfwd = fw1 fw2 fw3.. I think multiple entry options are probably not a good thing to have. We already have them though (-net switch so QemuOpts added them). Yeah, but let's ignore that for the moment. If we didn't have historical baggage, would we prefer the syntax above or do you think there's value in specifying it on separate lines? At this stage, I'm not worried about config file compatibility. If we need to add some special logic to the -net switch to accommodate it's strange behavior, that's okay with me. Regards, Anthony Liguori cheers, Gerd
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
Once you eliminate machine_register_core that knowledge has somehow got to come from your device tree description file. Having a single device tree that can morph into significantly different machines seems like unnecessary complexity given this is a user-specified file. 99% of qemu users will never touch a device tree. The practical matter is, we're going to have to provide higher level interfaces that allow a user to significantly morph a base device tree into something different. That's the bit I don't get. Why are we significantly morphing a base device tree? Surely it's easier to just use a different base tree. Paul
[Qemu-devel] [PATCH 1/2] virtio-blk: stop tracking old_bs
There is a 1:1 relation between VirtIOBlock and BlockDriverState instances,
no need to track it because it won't change.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/hw/virtio-blk.c
===
--- qemu.orig/hw/virtio-blk.c 2010-05-26 13:36:07.0 +0200
+++ qemu/hw/virtio-blk.c2010-06-08 11:19:56.253262216 +0200
@@ -241,18 +241,17 @@ static void do_multiwrite(BlockDriverSta
}
static void virtio_blk_handle_flush(BlockRequest *blkreq, int *num_writes,
-VirtIOBlockReq *req, BlockDriverState **old_bs)
+VirtIOBlockReq *req)
{
BlockDriverAIOCB *acb;
/*
* Make sure all outstanding writes are posted to the backing device.
*/
-if (*old_bs != NULL) {
-do_multiwrite(*old_bs, blkreq, *num_writes);
+if (*num_writes 0) {
+do_multiwrite(req-dev-bs, blkreq, *num_writes);
}
*num_writes = 0;
-*old_bs = req-dev-bs;
acb = bdrv_aio_flush(req-dev-bs, virtio_blk_flush_complete, req);
if (!acb) {
@@ -261,19 +260,16 @@ static void virtio_blk_handle_flush(Bloc
}
static void virtio_blk_handle_write(BlockRequest *blkreq, int *num_writes,
-VirtIOBlockReq *req, BlockDriverState **old_bs)
+VirtIOBlockReq *req)
{
if (req-out-sector req-dev-sector_mask) {
virtio_blk_rw_complete(req, -EIO);
return;
}
-if (req-dev-bs != *old_bs || *num_writes == 32) {
-if (*old_bs != NULL) {
-do_multiwrite(*old_bs, blkreq, *num_writes);
-}
+if (*num_writes == 32) {
+do_multiwrite(req-dev-bs, blkreq, *num_writes);
*num_writes = 0;
-*old_bs = req-dev-bs;
}
blkreq[*num_writes].sector = req-out-sector;
@@ -305,7 +301,6 @@ static void virtio_blk_handle_read(VirtI
typedef struct MultiReqBuffer {
BlockRequestblkreq[32];
int num_writes;
-BlockDriverState*old_bs;
} MultiReqBuffer;
static void virtio_blk_handle_request(VirtIOBlockReq *req,
@@ -326,15 +321,13 @@ static void virtio_blk_handle_request(Vi
req-in = (void *)req-elem.in_sg[req-elem.in_num - 1].iov_base;
if (req-out-type VIRTIO_BLK_T_FLUSH) {
-virtio_blk_handle_flush(mrb-blkreq, mrb-num_writes,
-req, mrb-old_bs);
+virtio_blk_handle_flush(mrb-blkreq, mrb-num_writes, req);
} else if (req-out-type VIRTIO_BLK_T_SCSI_CMD) {
virtio_blk_handle_scsi(req);
} else if (req-out-type VIRTIO_BLK_T_OUT) {
qemu_iovec_init_external(req-qiov, req-elem.out_sg[1],
req-elem.out_num - 1);
-virtio_blk_handle_write(mrb-blkreq, mrb-num_writes,
-req, mrb-old_bs);
+virtio_blk_handle_write(mrb-blkreq, mrb-num_writes, req);
} else {
qemu_iovec_init_external(req-qiov, req-elem.in_sg[0],
req-elem.in_num - 1);
@@ -348,7 +341,6 @@ static void virtio_blk_handle_output(Vir
VirtIOBlockReq *req;
MultiReqBuffer mrb = {
.num_writes = 0,
-.old_bs = NULL,
};
while ((req = virtio_blk_get_request(s))) {
@@ -356,7 +348,7 @@ static void virtio_blk_handle_output(Vir
}
if (mrb.num_writes 0) {
-do_multiwrite(mrb.old_bs, mrb.blkreq, mrb.num_writes);
+do_multiwrite(s-bs, mrb.blkreq, mrb.num_writes);
}
/*
@@ -372,7 +364,6 @@ static void virtio_blk_dma_restart_bh(vo
VirtIOBlockReq *req = s-rq;
MultiReqBuffer mrb = {
.num_writes = 0,
-.old_bs = NULL,
};
qemu_bh_delete(s-bh);
@@ -386,7 +377,7 @@ static void virtio_blk_dma_restart_bh(vo
}
if (mrb.num_writes 0) {
-do_multiwrite(mrb.old_bs, mrb.blkreq, mrb.num_writes);
+do_multiwrite(s-bs, mrb.blkreq, mrb.num_writes);
}
}
[Qemu-devel] [PATCH 2/2] virtio-blk: simplify multiwrite calling conventions
Pass the MultiReqBuffer structure down all the way to the I/O submission
instead of takin it apart. Also mark num_writes unsigned as it can't
go negative, and take the check for any pending I/O requests into the
submission function. Last but not least rename do_multiwrite to
virtio_submit_multiwrite to fit the general naming scheme and make clear
what it does.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/hw/virtio-blk.c
===
--- qemu.orig/hw/virtio-blk.c 2010-06-08 10:52:25.397010435 +0200
+++ qemu/hw/virtio-blk.c2010-06-08 10:59:19.827254394 +0200
@@ -225,33 +225,39 @@ static void virtio_blk_handle_scsi(VirtI
}
#endif /* __linux__ */
-static void do_multiwrite(BlockDriverState *bs, BlockRequest *blkreq,
-int num_writes)
+typedef struct MultiReqBuffer {
+BlockRequestblkreq[32];
+unsigned intnum_writes;
+} MultiReqBuffer;
+
+static void virtio_submit_multiwrite(BlockDriverState *bs, MultiReqBuffer *mrb)
{
int i, ret;
-ret = bdrv_aio_multiwrite(bs, blkreq, num_writes);
+if (!mrb-num_writes) {
+return;
+}
+
+ret = bdrv_aio_multiwrite(bs, mrb-blkreq, mrb-num_writes);
if (ret != 0) {
-for (i = 0; i num_writes; i++) {
-if (blkreq[i].error) {
-virtio_blk_rw_complete(blkreq[i].opaque, -EIO);
+for (i = 0; i mrb-num_writes; i++) {
+if (mrb-blkreq[i].error) {
+virtio_blk_rw_complete(mrb-blkreq[i].opaque, -EIO);
}
}
}
+
+mrb-num_writes = 0;
}
-static void virtio_blk_handle_flush(BlockRequest *blkreq, int *num_writes,
-VirtIOBlockReq *req)
+static void virtio_blk_handle_flush(VirtIOBlockReq *req, MultiReqBuffer *mrb)
{
BlockDriverAIOCB *acb;
/*
* Make sure all outstanding writes are posted to the backing device.
*/
-if (*num_writes 0) {
-do_multiwrite(req-dev-bs, blkreq, *num_writes);
-}
-*num_writes = 0;
+virtio_submit_multiwrite(req-dev-bs, mrb);
acb = bdrv_aio_flush(req-dev-bs, virtio_blk_flush_complete, req);
if (!acb) {
@@ -259,27 +265,28 @@ static void virtio_blk_handle_flush(Bloc
}
}
-static void virtio_blk_handle_write(BlockRequest *blkreq, int *num_writes,
-VirtIOBlockReq *req)
+static void virtio_blk_handle_write(VirtIOBlockReq *req, MultiReqBuffer *mrb)
{
+BlockRequest *blkreq;
+
if (req-out-sector req-dev-sector_mask) {
virtio_blk_rw_complete(req, -EIO);
return;
}
-if (*num_writes == 32) {
-do_multiwrite(req-dev-bs, blkreq, *num_writes);
-*num_writes = 0;
+if (mrb-num_writes == 32) {
+virtio_submit_multiwrite(req-dev-bs, mrb);
}
-blkreq[*num_writes].sector = req-out-sector;
-blkreq[*num_writes].nb_sectors = req-qiov.size / 512;
-blkreq[*num_writes].qiov = req-qiov;
-blkreq[*num_writes].cb = virtio_blk_rw_complete;
-blkreq[*num_writes].opaque = req;
-blkreq[*num_writes].error = 0;
+blkreq = mrb-blkreq[mrb-num_writes];
+blkreq-sector = req-out-sector;
+blkreq-nb_sectors = req-qiov.size / 512;
+blkreq-qiov = req-qiov;
+blkreq-cb = virtio_blk_rw_complete;
+blkreq-opaque = req;
+blkreq-error = 0;
-(*num_writes)++;
+mrb-num_writes++;
}
static void virtio_blk_handle_read(VirtIOBlockReq *req)
@@ -298,11 +305,6 @@ static void virtio_blk_handle_read(VirtI
}
}
-typedef struct MultiReqBuffer {
-BlockRequestblkreq[32];
-int num_writes;
-} MultiReqBuffer;
-
static void virtio_blk_handle_request(VirtIOBlockReq *req,
MultiReqBuffer *mrb)
{
@@ -321,13 +323,13 @@ static void virtio_blk_handle_request(Vi
req-in = (void *)req-elem.in_sg[req-elem.in_num - 1].iov_base;
if (req-out-type VIRTIO_BLK_T_FLUSH) {
-virtio_blk_handle_flush(mrb-blkreq, mrb-num_writes, req);
+virtio_blk_handle_flush(req, mrb);
} else if (req-out-type VIRTIO_BLK_T_SCSI_CMD) {
virtio_blk_handle_scsi(req);
} else if (req-out-type VIRTIO_BLK_T_OUT) {
qemu_iovec_init_external(req-qiov, req-elem.out_sg[1],
req-elem.out_num - 1);
-virtio_blk_handle_write(mrb-blkreq, mrb-num_writes, req);
+virtio_blk_handle_write(req, mrb);
} else {
qemu_iovec_init_external(req-qiov, req-elem.in_sg[0],
req-elem.in_num - 1);
@@ -347,9 +349,7 @@ static void virtio_blk_handle_output(Vir
virtio_blk_handle_request(req, mrb);
}
-if (mrb.num_writes 0) {
-do_multiwrite(s-bs, mrb.blkreq, mrb.num_writes);
-}
+virtio_submit_multiwrite(s-bs, mrb);
/*
* FIXME: Want to check for completions before returning to guest mode,
@@ -376,9 +376,7 @@ static void virtio_blk_dma_restart_bh(vo
req = req-next;
}
-if (mrb.num_writes 0) {
-
[Qemu-devel] [Bug 586420] Re: WinXP install cd hangs at boot time if machine started with floppy
Well, I tried your command line and I've got the bug qemu: could not load PC BIOS 'bios.bin' It seems something went wrong with my compiled qemu. I'll try qemu.git now. -- WinXP install cd hangs at boot time if machine started with floppy https://bugs.launchpad.net/bugs/586420 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Bug description: I have a second problem: I wanted to install Windows Server 2003 on a virtio drive, so I tried to start the machine with the install cd as the boot drive and a floppy image with the viostor drivers. The problem is, the install cd hangs at boot time. If I start VNC I just see a black ground with 640x480. I've also tried this with the install cd of Windows Server 2008 R2 and it works! Could it be that the BIOS screws up because the older install cds are using the floppy emulation to boot the setup?
[Qemu-devel] Re: KVM call minutes for June 8
On 06/08/2010 10:05 AM, Chris Wright wrote: Accelerating counters (aka moving PIT to userspace, keeping HPET in userspace) - PIT (in-kernel, userspace, or split) - userspace PIT, too slow - kernel PIT (already seen bugs) - split PIT, not realistic w/out a sane interface (see bugs above) - exit to userspace is a base cost, add MSR save/restore, add qemu overhead...and exit to userspace is expensive - hpet in userspace (at least minimal counter reading) - ioapic - less than half is architectural, more than half endds of being interrupt reinjection Live migration + hotplug - start a machine, hotplug device, allocate ram...can't migrate - last_offset and ramblock sections coming from cmdline may not be compatible w/ hotplug - worst case is different ramblock order and data corruption - alex has patches to convert ramblocks into queuelist - give name, offset - will clean up and send out today migration events? - QMP (wire protocol) has nice async events - QError reasonable - migration is async command, can complete w/ error or success - QMP broken for error - need context for error, default is monitor, but async command - redo qerror_report, propagate error (or always have error context available) - monitor and qmp done w/ same dispatch functions - should do monitor in terms of qmp - every qerror replacing monitor printf error - ends up not sharing enough ($foo not found, where $foo is contextual) - async command (pass in command completion) - may have to do limited (throw away for 0.13 and redo properly for 0.14) - anthony has a (not fully working) tree, and will document direction on wiki http://wiki.qemu.org/Features/QMP2 Includes a pointer to the current tree I'm working out of. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 3/3] cow: use qemu block API
Am 07.06.2010 12:06, schrieb Christoph Hellwig: Use bdrv_pwrite to access the backing device instead of pread, and convert the driver to implementing the bdrv_open method which gives it an already opened BlockDriverState for the underlying device. Signed-off-by: Christoph Hellwig h...@lst.de Thanks, applied all to the block branch. Kevin
Re: [Qemu-devel] [PATCH v2] net: Fix hotplug with pci_add
Amit Shah amit.s...@redhat.com writes: The correct model type wasn't getting added when hotplugging nics with pci_add. Testcase: start VM with default nic type. In the qemu_monitor: (qemu) pci_add auto nic model=virtio This results in a nic hot-plug of the same nic type as the default. Works fine for me on master, fd1dc858370d9a9ac7ea2512812c3a152ee6484b. What am I doing wrong? This was broken in 5294e2c774f120e10b44652ac143abda356f44eb Also changes the behaviour where no .init is defined for a net_client_type. Previously, 0 was returned, which indicated the init was successful and that 0 was the index into the nd_tables[] array. Return -1, indicating unsuccessful init, in such a case. The only element of net_client_types[] without an init() method is type none, index 0. So, doesn't this break -net none? And what does it fix?
[Qemu-devel] Re: [PATCH] net: Fix hotplug with pci_add
On (Tue) Jun 08 2010 [17:31:04], Gerd Hoffmann wrote: On 06/08/10 17:17, Amit Shah wrote: The correct model type wasn't getting added when hotplugging nics with pci_add. Testcase: start VM with default nic type. In the qemu_monitor: (qemu) pci_add auto nic model=virtio This results in a nic hot-plug of the same nic type as the default. Same goes for mac address and vlan btw, most likely for the same reason. I guess your patch handles this too? Yes, all the properties. Amit
Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
One smart way to implement default devices could be an inclusion mechanism where a machine can ask qemu to read other config files. Then you'd have config files for the default serial/parallel/etc. This could also be implemented on top of choices 2/3/4 though. Defaults are tough because there are multiple ways to create devices today. Here's something that could potentially address the problem. I'll focus on -serial but it's equally applicable to the other default devices. We would introduce serial0, serial1, serial2, serial3 MachineCore properties. These properties would be chardev names. The pc machine types would do: QOPT_VALUE(serial0, __default_serial0); In vl.c, we would always create a __default_serial0 chardev of 'vc'. The -serial option would keep a counter and: -serial mon:stdio -serial vc Would be equivalent to: -chardev mon:stdio,id=__serial0 -machine serial0=__serial0 \ -chardev vc,id=__serial1 -machine serial1=__serial1 -nodefaults simply suppresses the creation of the default serial devices. It's the job of the MachineCore to try to find each of the serialN properties and if the chardevs have been created, use qdev to create an appropriate serial port device. This would apply equally well to parallel and virtcon. Networking is a bit of a nightmare as many boards simply ignore the networking options. Floppy and cdrom can work in this way too. Regards, Anthony Liguori Paolo
Re: [Qemu-devel] [PATCH v2] net: Fix hotplug with pci_add
On (Tue) Jun 08 2010 [18:33:00], Markus Armbruster wrote: Amit Shah amit.s...@redhat.com writes: The correct model type wasn't getting added when hotplugging nics with pci_add. Testcase: start VM with default nic type. In the qemu_monitor: (qemu) pci_add auto nic model=virtio This results in a nic hot-plug of the same nic type as the default. Works fine for me on master, fd1dc858370d9a9ac7ea2512812c3a152ee6484b. What am I doing wrong? Did you start with a virtio nic added? The 'default' here is the nic type that's added as the first nic. Try this: start a VM with model e1000 and use pci_add to add a nic type of virtio. This was broken in 5294e2c774f120e10b44652ac143abda356f44eb Also changes the behaviour where no .init is defined for a net_client_type. Previously, 0 was returned, which indicated the init was successful and that 0 was the index into the nd_tables[] array. Return -1, indicating unsuccessful init, in such a case. The only element of net_client_types[] without an init() method is type none, index 0. So, doesn't this break -net none? And what does it fix? The net_client_types[] index isn't relevant here. -net none works fine, no problem. Amit
Re: [Qemu-devel] [PATCH] Clarify error message when a PCI slot is already in use (v2)
Daniel P. Berrange berra...@redhat.com writes:
When mistakenly configuring two devices in the same PCI slot,
QEMU gives a not entirely obvious message about a 'devfn' being
in use:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu-kvm: -device virtio-balloon-pci,bus=pci.0,addr=0x3: PCI: devfn 24 not
available for virtio-balloon-pci, in use by rtl8139
The user does not configure 'devfn' numbers, they use slot+function.
Thus the error messages should be reported back to the user with that
same terminology rather than the internal QEMU terminology. This
patch makes it report:
$ qemu -device rtl8139 -device virtio-balloon-pci,bus=pci.0,addr=0x3
qemu: -device virtio-balloon-pci,bus=pci.0,addr=0x3.7: PCI: slot 3 function 0
not available for virtio-balloon-pci, in use by rtl8139
Signed-off-by: Daniel P. Berrange berra...@redhat.com
---
hw/pci.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index cbbd1dd..cd7ce8d 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -609,12 +609,12 @@ static PCIDevice *do_pci_register_device(PCIDevice
*pci_dev, PCIBus *bus,
if (!bus-devices[devfn])
goto found;
}
-error_report(PCI: no devfn available for %s, all in use, name);
+error_report(PCI: no slot/function available for %s, all in use,
name);
return NULL;
found: ;
} else if (bus-devices[devfn]) {
-error_report(PCI: devfn %d not available for %s, in use by %s,
- devfn, name, bus-devices[devfn]-name);
+error_report(PCI: slot %d function %d not available for %s, in use
by %s,
+ PCI_SLOT(devfn), PCI_FUNC(devfn), name,
bus-devices[devfn]-name);
return NULL;
}
pci_dev-bus = bus;
Long lines without true need. Do we care? Looks good otherwise.
Re: [Qemu-devel] [PATCH 01/10] target-mips: break out [ls][wd]c1 and rdhwr insn generation
On Mon, May 24, 2010 at 09:19:35AM -0700, Nathan Froyd wrote:
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate.c | 106
++-
1 files changed, 59 insertions(+), 47 deletions(-)
Thanks, applied.
diff --git a/target-mips/translate.c b/target-mips/translate.c
index c95ecb1..2075d09 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -1220,6 +1220,17 @@ static void gen_flt_ldst (DisasContext *ctx, uint32_t
opc, int ft,
tcg_temp_free(t0);
}
+static void gen_cop1_ldst(CPUState *env, DisasContext *ctx,
+ uint32_t op, int rt, int rs, int16_t imm)
+{
+if (env-CP0_Config1 (1 CP0C1_FP)) {
+check_cp1_enabled(ctx);
+gen_flt_ldst(ctx, op, rt, rs, imm);
+} else {
+generate_exception_err(ctx, EXCP_CpU, 1);
+}
+}
+
/* Arithmetic with immediate operand */
static void gen_arith_imm (CPUState *env, DisasContext *ctx, uint32_t opc,
int rt, int rs, int16_t imm)
@@ -7528,6 +7539,52 @@ static void gen_flt3_arith (DisasContext *ctx,
uint32_t opc,
fregnames[fs], fregnames[ft]);
}
+static void
+gen_rdhwr (CPUState *env, DisasContext *ctx, int rt, int rd)
+{
+TCGv t0;
+
+check_insn(env, ctx, ISA_MIPS32R2);
+t0 = tcg_temp_new();
+
+switch (rd) {
+case 0:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_cpunum(t0);
+gen_store_gpr(t0, rt);
+break;
+case 1:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_synci_step(t0);
+gen_store_gpr(t0, rt);
+break;
+case 2:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_cc(t0);
+gen_store_gpr(t0, rt);
+break;
+case 3:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_ccres(t0);
+gen_store_gpr(t0, rt);
+break;
+case 29:
+#if defined(CONFIG_USER_ONLY)
+tcg_gen_ld_tl(t0, cpu_env, offsetof(CPUState, tls_value));
+gen_store_gpr(t0, rt);
+break;
+#else
+/* XXX: Some CPUs implement this in hardware.
+ Not supported yet. */
+#endif
+default:/* Invalid */
+MIPS_INVAL(rdhwr);
+generate_exception(ctx, EXCP_RI);
+break;
+}
+tcg_temp_free(t0);
+}
+
static void handle_delay_slot (CPUState *env, DisasContext *ctx,
int insn_bytes)
{
@@ -8999,47 +9056,7 @@ static void decode_opc (CPUState *env, DisasContext
*ctx, int *is_branch)
gen_bshfl(ctx, op2, rt, rd);
break;
case OPC_RDHWR:
-check_insn(env, ctx, ISA_MIPS32R2);
-{
-TCGv t0 = tcg_temp_new();
-
-switch (rd) {
-case 0:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_cpunum(t0);
-gen_store_gpr(t0, rt);
-break;
-case 1:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_synci_step(t0);
-gen_store_gpr(t0, rt);
-break;
-case 2:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_cc(t0);
-gen_store_gpr(t0, rt);
-break;
-case 3:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_ccres(t0);
-gen_store_gpr(t0, rt);
-break;
-case 29:
-#if defined(CONFIG_USER_ONLY)
-tcg_gen_ld_tl(t0, cpu_env, offsetof(CPUState,
tls_value));
-gen_store_gpr(t0, rt);
-break;
-#else
-/* XXX: Some CPUs implement this in hardware.
- Not supported yet. */
-#endif
-default:/* Invalid */
-MIPS_INVAL(rdhwr);
-generate_exception(ctx, EXCP_RI);
-break;
-}
-tcg_temp_free(t0);
-}
+gen_rdhwr(env, ctx, rt, rd);
break;
case OPC_FORK:
check_insn(env, ctx, ASE_MT);
@@ -9242,12 +9259,7 @@ static void decode_opc (CPUState *env, DisasContext
*ctx, int *is_branch)
case OPC_LDC1:
case OPC_SWC1:
case OPC_SDC1:
-if (env-CP0_Config1 (1 CP0C1_FP)) {
-check_cp1_enabled(ctx);
-gen_flt_ldst(ctx, op, rt, rs, imm);
-} else {
-generate_exception_err(ctx, EXCP_CpU, 1);
-}
+gen_cop1_ldst(env, ctx, op, rt, rs, imm);
break;
case OPC_CP1:
--
1.6.3.2
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net
Re: [Qemu-devel] [PATCH] configure: add an option to disable vlans
On 06/08/2010 09:37 AM, Paul Brook wrote: I see three possible options to handle this. (1) Write a hub (or morph the current vlan code into this). Then you can do something like: qemu -netdev socket,id=p1 \ -netdev user,id=p2 \ -netdev dump,id=p3 \ -switch peer=p1,peer=p2,monitor=p3,port=p4 \ -device $nic,netdev=p4 (2) Implement the same as external daemon which can be combined with -netdev socket. (3) Just point people who need this to the various virtual switch projects (vde, ...) they can use and drop vlan. (2) is just a special case of (3), where we decide that the existing implementations suck and go write our own. To the extent that (1) is valuable, I think it's the best approach. I'd vote for officially deprecating vlans for 0.13 and then seeing how much people complain. If no one complains too much, then let's not bother introducing -switch. Regards, Anthony Liguori Paul
[Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset
2010/6/4 Blue Swirl blauwir...@gmail.com:
On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/6/1 Blue Swirl blauwir...@gmail.com:
On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
2010/6/1 Blue Swirl blauwir...@gmail.com:
On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko
atar4q...@googlemail.com wrote:
lower interrupt during chip reset. Otherwise the ESP_RSTAT register
may get out of sync with the IRQ line status. This effect became
visible after commit 65899fe3
Hard reset handlers should not touch qemu_irqs, because on cold start,
the receiving end may be unprepared to handle the signal.
Wouldn't the real hardware lower irq on the hardware reset?
Yes, but since qemu_irqs have no state, and on a cold start or system
reset all other devices are guaranteed to be reset, the callback would
be useless.
And if it would not, would it still clear the corresponding bit in
the ESP_RSTAT register?
All registers are set to zero in the lines below.
See
0d0a7e69e853639b123798877e019c3c7ee6634a,
bc26e55a6615dc594be425d293db40d5cdcdb84b and
42f1ced228c9b616cfa2b69846025271618e4ef5.
For ESP there are two other sources of reset: signal from DMA and chip
reset command. On those cases, lowering IRQ makes sense.
So the correct fix is to refactor the reset handling a bit. Does this
patch also fix your test case?
It does, but
+static void esp_soft_reset(DeviceState *d)
+{
+ ESPState *s = container_of(d, ESPState, busdev.qdev);
+
+ qemu_irq_lower(s-irq);
Shouldn't it be esp_lower_irq(s)? What's going to happen to the
DMA_INTR bit if dma was the source of the irq?
Again, the registers are zeroed in esp_hard_reset().
How does it zero the _DMA_ registers? And sparc32_dma does share the
IRQ line with ESP, doesn't it?
I'd suppose DMA registers are separate and they would not be cleared
by for example ESP chip reset command. The IRQ goes from ESP to DMA,
DMA has another line going to interrupt controller.
But do we have separate DMA lines in qemu? If we do, I'm absolutely fine with
qemu_irq_lower(s-irq) . If we don't, imagine the following scenario: DMA
rises an IRQ, then esp chip reset happens, and then... DMA can't rise
the IRQ anymore.
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] Few Questions about QEMU JSON
On Mon, 7 Jun 2010 10:20:47 +0530 (IST) akshay st aksha...@yahoo.co.in wrote: Hello, Basically i want to seperate QEMU(Instruction translations, hardware emulation drivers etc...) and Simulators (UI,events etc...), Someone suggested me to use json mechanism. I want to understand more on json, can u please give me some insight,It there is any document or something it will be helpful. Also is it possible to seperate QEMU and Simulator?If yes can we use JSON? Not sure if I got what you're trying to do, but you're probably talking about QMP. We have a web page: http://www.linux-kvm.org/page/MonitorProtocol It has some explanation and pointers to the README and spec files, also building latest git repo will bring the commands doc in QMP/qmp-commands.txt.
[Qemu-devel] [Bug 485239] Re: Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 0.11.50
I am experiencing similar problems with Win2008 / Win7 guests; BSOD when trying to install; sometimes before the first screen, sometimes just after. Using Ubuntu Lucid: kernel 2.6.32-21-server qemu-kvm-0.12.3 Also on Fedora 12: kernel 2.6.32.12-115.fc12.x86_64 qemu-0.11.0-13.fc12.x86_64 qemu-system-x86-0.11.0-13.fc12.x86_64 I've tried qcow2 and raw, with/without network device, cirrus/std/vmware vga... suggestions welcomed. -- Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 0.11.50 https://bugs.launchpad.net/bugs/485239 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: Installation of Windows 2008 datacenter- 64 bit fails with qemu-system-x86_64. Version of qemu-system-x86_64 is 0.11.50. The installation source is dvd iso. Just after booting for installation of the Windows guest, it hangs for sometime and then the installation crashes with the error: A problem has been detected and windows has been shut down to prevent damage to your computer. Below is the command used for creating the guest. /usr/local/bin/qemu-system-x86_64 -cdrom /home/en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso -hda /var/lib/libvirt/images/win2008_dc_64.qcow2 -m 3000 -smp 3 -net nic -net tap,script=/home/qemu-ifup-latest -name win2008_dc_64 -vnc :1 Disk info of the guest image is as below: /usr/local/bin/qemu-img info /var/lib/libvirt/images/win2008_dc_64.qcow2 image: /var/lib/libvirt/images/win2008_dc_64.qcow2 file format: qcow2 virtual size: 15G (16106127360 bytes) disk size: 136K cluster_size: 65536 This issue is also reproducible with raw image format.
[Qemu-devel] [RFC PATCH 1/6] qemu_ram_alloc: Remove duplicate code
No reason not to call qemu_ram_map() once we have the allocation
and remove duplicate code.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
exec.c | 37 ++---
1 files changed, 10 insertions(+), 27 deletions(-)
diff --git a/exec.c b/exec.c
index 7b0e1c5..c60f9e7 100644
--- a/exec.c
+++ b/exec.c
@@ -2816,18 +2816,17 @@ ram_addr_t qemu_ram_map(ram_addr_t size, void *host)
ram_addr_t qemu_ram_alloc(ram_addr_t size)
{
-RAMBlock *new_block;
+void *host;
size = TARGET_PAGE_ALIGN(size);
-new_block = qemu_malloc(sizeof(*new_block));
if (mem_path) {
#if defined (__linux__) !defined(TARGET_S390X)
-new_block-host = file_ram_alloc(size, mem_path);
-if (!new_block-host) {
-new_block-host = qemu_vmalloc(size);
+host = file_ram_alloc(size, mem_path);
+if (!host) {
+host = qemu_vmalloc(size);
#ifdef MADV_MERGEABLE
-madvise(new_block-host, size, MADV_MERGEABLE);
+madvise(host, size, MADV_MERGEABLE);
#endif
}
#else
@@ -2837,33 +2836,17 @@ ram_addr_t qemu_ram_alloc(ram_addr_t size)
} else {
#if defined(TARGET_S390X) defined(CONFIG_KVM)
/* XXX S390 KVM requires the topmost vma of the RAM to be 256GB */
-new_block-host = mmap((void*)0x100, size,
-PROT_EXEC|PROT_READ|PROT_WRITE,
-MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+host = mmap((void*)0x100, size, PROT_EXEC|PROT_READ|PROT_WRITE,
+MAP_SHARED | MAP_ANONYMOUS, -1, 0);
#else
-new_block-host = qemu_vmalloc(size);
+host = qemu_vmalloc(size);
#endif
#ifdef MADV_MERGEABLE
-madvise(new_block-host, size, MADV_MERGEABLE);
+madvise(host, size, MADV_MERGEABLE);
#endif
}
-new_block-offset = last_ram_offset;
-new_block-length = size;
-
-new_block-next = ram_blocks;
-ram_blocks = new_block;
-
-phys_ram_dirty = qemu_realloc(phys_ram_dirty,
-(last_ram_offset + size) TARGET_PAGE_BITS);
-memset(phys_ram_dirty + (last_ram_offset TARGET_PAGE_BITS),
- 0xff, size TARGET_PAGE_BITS);
-
-last_ram_offset += size;
-if (kvm_enabled())
-kvm_setup_guest_memory(new_block-host, size);
-
-return new_block-offset;
+return qemu_ram_map(size, host);
}
void qemu_ram_free(ram_addr_t addr)
[Qemu-devel] [RFC PATCH 6/6] savevm: Use RAM blocks for basis of migration
We don't want to assume a contiguous address space, so migrate based
on RAM blocks instead of a fixed linear address map.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch_init.c | 67 +--
1 files changed, 42 insertions(+), 25 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 8ba92ec..5780195 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -105,27 +105,26 @@ static int is_dup_page(uint8_t *page, uint8_t ch)
static int ram_save_block(QEMUFile *f)
{
-static ram_addr_t current_addr = 0;
-ram_addr_t saved_addr = current_addr;
-ram_addr_t addr = 0;
-uint64_t total_ram = ram_bytes_total();
+static RAMBlock *last_block = NULL;
+static ram_addr_t last_offset = 0;
+RAMBlock *block = last_block;
+ram_addr_t offset = last_offset;
+ram_addr_t current_addr;
int bytes_sent = 0;
-while (addr total_ram) {
+if (!block)
+block = QLIST_FIRST(ram.blocks);
+
+current_addr = block-offset + offset;
+
+do {
if (cpu_physical_memory_get_dirty(current_addr, MIGRATION_DIRTY_FLAG))
{
-RAMBlock *block;
-ram_addr_t offset;
uint8_t *p;
cpu_physical_memory_reset_dirty(current_addr,
current_addr + TARGET_PAGE_SIZE,
MIGRATION_DIRTY_FLAG);
-QLIST_FOREACH(block, ram.blocks, next) {
-if (current_addr - block-offset block-length)
-break;
-}
-offset = current_addr - block-offset;
p = block-host + offset;
if (is_dup_page(p, *p)) {
@@ -142,9 +141,21 @@ static int ram_save_block(QEMUFile *f)
break;
}
-addr += TARGET_PAGE_SIZE;
-current_addr = (saved_addr + addr) % total_ram;
-}
+
+offset += TARGET_PAGE_SIZE;
+if (offset = block-length) {
+offset = 0;
+block = QLIST_NEXT(block, next);
+if (!block)
+block = QLIST_FIRST(ram.blocks);
+}
+
+current_addr = block-offset + offset;
+
+} while (current_addr != last_block-offset + last_offset);
+
+last_block = block;
+last_offset = offset;
return bytes_sent;
}
@@ -153,13 +164,16 @@ static uint64_t bytes_transferred;
static ram_addr_t ram_save_remaining(void)
{
-ram_addr_t addr;
+RAMBlock *block;
ram_addr_t count = 0;
-uint64_t total_ram = ram_bytes_total();
-for (addr = 0; addr total_ram; addr += TARGET_PAGE_SIZE) {
-if (cpu_physical_memory_get_dirty(addr, MIGRATION_DIRTY_FLAG)) {
-count++;
+QLIST_FOREACH(block, ram.blocks, next) {
+ram_addr_t addr;
+for (addr = block-offset; addr block-offset + block-length;
+ addr += TARGET_PAGE_SIZE) {
+if (cpu_physical_memory_get_dirty(addr, MIGRATION_DIRTY_FLAG)) {
+count++;
+}
}
}
@@ -206,20 +220,23 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
void *opaque)
if (stage == 1) {
RAMBlock *block;
-uint64_t total_ram = ram_bytes_total();
bytes_transferred = 0;
/* Make sure all dirty bits are set */
-for (addr = 0; addr total_ram; addr += TARGET_PAGE_SIZE) {
-if (!cpu_physical_memory_get_dirty(addr, MIGRATION_DIRTY_FLAG)) {
-cpu_physical_memory_set_dirty(addr);
+QLIST_FOREACH(block, ram.blocks, next) {
+for (addr = block-offset; addr block-offset + block-length;
+ addr += TARGET_PAGE_SIZE) {
+if (!cpu_physical_memory_get_dirty(addr,
+ MIGRATION_DIRTY_FLAG)) {
+cpu_physical_memory_set_dirty(addr);
+}
}
}
/* Enable dirty memory tracking */
cpu_physical_memory_set_dirty_tracking(1);
-qemu_put_be64(f, total_ram | RAM_SAVE_FLAG_MEM_SIZE);
+qemu_put_be64(f, ram_bytes_total() | RAM_SAVE_FLAG_MEM_SIZE);
QLIST_FOREACH(block, ram.blocks, next) {
qemu_put_buffer(f, (uint8_t *)block-name, sizeof(block-name));
[Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
let the caller specify a name so we can make a positive match.
Note, this only addresses the qemu-kvm callers so far.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
cpu-all.h |1 +
cpu-common.h |4 ++--
exec.c |8 +---
hw/device-assignment.c |8 ++--
hw/pc.c|8
hw/pci.c |5 -
hw/vga.c |2 +-
hw/vmware_vga.c|2 +-
8 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 458cb4b..a5b886a 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -865,6 +865,7 @@ typedef struct RAMBlock {
uint8_t *host;
ram_addr_t offset;
ram_addr_t length;
+char name[64];
QLIST_ENTRY(RAMBlock) next;
} RAMBlock;
diff --git a/cpu-common.h b/cpu-common.h
index 4b0ba60..5b00544 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -40,8 +40,8 @@ static inline void
cpu_register_physical_memory(target_phys_addr_t start_addr,
}
ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr);
-ram_addr_t qemu_ram_map(ram_addr_t size, void *host);
-ram_addr_t qemu_ram_alloc(ram_addr_t);
+ram_addr_t qemu_ram_map(const char *name, ram_addr_t size, void *host);
+ram_addr_t qemu_ram_alloc(const char *name, ram_addr_t);
void qemu_ram_free(ram_addr_t addr);
/* This should only be used for ram local to a device. */
void *qemu_get_ram_ptr(ram_addr_t addr);
diff --git a/exec.c b/exec.c
index d785de3..dd57515 100644
--- a/exec.c
+++ b/exec.c
@@ -2774,13 +2774,15 @@ static void *file_ram_alloc(ram_addr_t memory, const
char *path)
}
#endif
-ram_addr_t qemu_ram_map(ram_addr_t size, void *host)
+ram_addr_t qemu_ram_map(const char *name, ram_addr_t size, void *host)
{
RAMBlock *new_block;
size = TARGET_PAGE_ALIGN(size);
new_block = qemu_malloc(sizeof(*new_block));
+// XXX check duplicates
+snprintf(new_block-name, sizeof(new_block-name), %s, strdup(name));
new_block-host = host;
new_block-offset = ram.last_offset;
@@ -2801,7 +2803,7 @@ ram_addr_t qemu_ram_map(ram_addr_t size, void *host)
return new_block-offset;
}
-ram_addr_t qemu_ram_alloc(ram_addr_t size)
+ram_addr_t qemu_ram_alloc(const char *name, ram_addr_t size)
{
void *host;
@@ -2833,7 +2835,7 @@ ram_addr_t qemu_ram_alloc(ram_addr_t size)
#endif
}
-return qemu_ram_map(size, host);
+return qemu_ram_map(name, size, host);
}
void qemu_ram_free(ram_addr_t addr)
diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2b963b5..1d631f6 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -569,9 +569,13 @@ static int assigned_dev_register_regions(PCIRegion
*io_regions,
if (!slow_map) {
void *virtbase = pci_dev-v_addrs[i].u.r_virtbase;
+char name[14];
-pci_dev-v_addrs[i].memory_index =
qemu_ram_map(cur_region-size,
-virtbase);
+snprintf(name, sizeof(name), pci:%02x.%x.bar%d,
+ PCI_SLOT(pci_dev-dev.devfn),
+ PCI_FUNC(pci_dev-dev.devfn), i);
+pci_dev-v_addrs[i].memory_index = qemu_ram_map(name,
+ cur_region-size, virtbase);
} else
pci_dev-v_addrs[i].memory_index = 0;
diff --git a/hw/pc.c b/hw/pc.c
index eae0db4..76be151 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -834,7 +834,7 @@ void pc_memory_init(ram_addr_t ram_size,
linux_boot = (kernel_filename != NULL);
/* allocate RAM */
-ram_addr = qemu_ram_alloc(below_4g_mem_size);
+ram_addr = qemu_ram_alloc(ram.pc.lowmem, below_4g_mem_size);
cpu_register_physical_memory(0, 0xa, ram_addr);
cpu_register_physical_memory(0x10,
below_4g_mem_size - 0x10,
@@ -845,7 +845,7 @@ void pc_memory_init(ram_addr_t ram_size,
#if TARGET_PHYS_ADDR_BITS == 32
hw_error(To much RAM for 32-bit physical address);
#else
-ram_addr = qemu_ram_alloc(above_4g_mem_size);
+ram_addr = qemu_ram_alloc(ram.pc.highmem, above_4g_mem_size);
cpu_register_physical_memory(0x1ULL,
above_4g_mem_size,
ram_addr);
@@ -866,7 +866,7 @@ void pc_memory_init(ram_addr_t ram_size,
(bios_size % 65536) != 0) {
goto bios_error;
}
-bios_offset = qemu_ram_alloc(bios_size);
+bios_offset = qemu_ram_alloc(ram.pc.bios, bios_size);
ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size));
if (ret != 0) {
bios_error:
@@ -892,7 +892,7 @@ void pc_memory_init(ram_addr_t ram_size,
}
option_rom[nb_option_roms++] = qemu_strdup(VAPIC_FILENAME);
-option_rom_offset = qemu_ram_alloc(PC_ROM_SIZE);
+option_rom_offset =
[Qemu-devel] [RFC PATCH 5/6] savevm: Migrate RAM based on name/offset
Synchronize RAM blocks with the target and migrate using name/offset
pairs. This ensures both source and target have the same view of
RAM and that we get the right bits into the right slot.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch_init.c | 103 +--
vl.c|2 +
2 files changed, 93 insertions(+), 12 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 6103461..8ba92ec 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -113,20 +113,29 @@ static int ram_save_block(QEMUFile *f)
while (addr total_ram) {
if (cpu_physical_memory_get_dirty(current_addr, MIGRATION_DIRTY_FLAG))
{
+RAMBlock *block;
+ram_addr_t offset;
uint8_t *p;
cpu_physical_memory_reset_dirty(current_addr,
current_addr + TARGET_PAGE_SIZE,
MIGRATION_DIRTY_FLAG);
-p = qemu_get_ram_ptr(current_addr);
+QLIST_FOREACH(block, ram.blocks, next) {
+if (current_addr - block-offset block-length)
+break;
+}
+offset = current_addr - block-offset;
+p = block-host + offset;
if (is_dup_page(p, *p)) {
-qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_COMPRESS);
+qemu_put_be64(f, offset | RAM_SAVE_FLAG_COMPRESS);
+qemu_put_buffer(f, (uint8_t *)block-name,
sizeof(block-name));
qemu_put_byte(f, *p);
bytes_sent = 1;
} else {
-qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_PAGE);
+qemu_put_be64(f, offset | RAM_SAVE_FLAG_PAGE);
+qemu_put_buffer(f, (uint8_t *)block-name,
sizeof(block-name));
qemu_put_buffer(f, p, TARGET_PAGE_SIZE);
bytes_sent = TARGET_PAGE_SIZE;
}
@@ -196,6 +205,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
void *opaque)
}
if (stage == 1) {
+RAMBlock *block;
uint64_t total_ram = ram_bytes_total();
bytes_transferred = 0;
@@ -210,6 +220,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage,
void *opaque)
cpu_physical_memory_set_dirty_tracking(1);
qemu_put_be64(f, total_ram | RAM_SAVE_FLAG_MEM_SIZE);
+
+QLIST_FOREACH(block, ram.blocks, next) {
+qemu_put_buffer(f, (uint8_t *)block-name, sizeof(block-name));
+qemu_put_be64(f, block-length);
+}
}
bytes_transferred_last = bytes_transferred;
@@ -257,7 +272,7 @@ int ram_load(QEMUFile *f, void *opaque, int version_id)
ram_addr_t addr;
int flags;
-if (version_id != 3) {
+if (version_id 3) {
return -EINVAL;
}
@@ -268,23 +283,89 @@ int ram_load(QEMUFile *f, void *opaque, int version_id)
addr = TARGET_PAGE_MASK;
if (flags RAM_SAVE_FLAG_MEM_SIZE) {
-if (addr != ram_bytes_total()) {
-return -EINVAL;
+if (version_id == 3) {
+if (addr != ram_bytes_total()) {
+return -EINVAL;
+}
+} else {
+/* Synchronize RAM block list */
+char name[64];
+ram_addr_t length;
+ram_addr_t total_ram_bytes = addr;
+
+while (total_ram_bytes) {
+RAMBlock *block;
+qemu_get_buffer(f, (uint8_t *)name, sizeof(name));
+length = qemu_get_be64(f);
+
+QLIST_FOREACH(block, ram.blocks, next) {
+if (!strncmp(name, block-name, sizeof(name))) {
+if (block-length != length)
+return -EINVAL;
+break;
+}
+}
+
+if (!block) {
+if (!qemu_ram_alloc(name, length))
+return -ENOMEM;
+}
+
+total_ram_bytes -= length;
+}
}
}
if (flags RAM_SAVE_FLAG_COMPRESS) {
-uint8_t ch = qemu_get_byte(f);
-memset(qemu_get_ram_ptr(addr), ch, TARGET_PAGE_SIZE);
+void *host;
+uint8_t ch;
+
+if (version_id == 3) {
+host = qemu_get_ram_ptr(addr);
+} else {
+RAMBlock *block;
+char name[64];
+
+qemu_get_buffer(f, (uint8_t *)name, sizeof(name));
+
+QLIST_FOREACH(block, ram.blocks, next) {
+if (!strncmp(name, block-name, sizeof(name)))
+break;
+}
+if (!block)
+return -EINVAL;
+
+host = block-host + addr;
+}
+
