[Qemu-devel] buildbot failure in qemu on xen_i386_debian_6_0
The Buildbot has detected a new failure on builder xen_i386_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/xen_i386_debian_6_0/builds/362 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_xen_next' triggered this build Build Source Stamp: [branch xen-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on xen_x86_64_debian_6_0
The Buildbot has detected a new failure on builder xen_x86_64_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/xen_x86_64_debian_6_0/builds/361 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_xen_next' triggered this build Build Source Stamp: [branch xen-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
Re: [Qemu-devel] [PATCH] ehci: Fix setting of halt bit from usbcmd register updates
On 08/15/12 17:08, Hans de Goede wrote: This fixes linux guests started without any USB devices not seeing newly plugged devices until lsusb is done inside the guest. Patch added to usb patch queue. thanks, Gerd
Re: [Qemu-devel] Hard freeze for 1.2 today
Hi, Today is the hard freeze for 1.2. If you have any pull requests and/or patches targetted for the hard freeze, please send them by 3pm US/Central time today and clearly mark them for-1.2. If there are existing patches and/or pull requests on the mailing list that you think should be in 1.2, please respond to the email with a pointer to the mail. http://patchwork.ozlabs.org/patch/175507/ http://patchwork.ozlabs.org/patch/176913/ http://patchwork.ozlabs.org/patch/176914/ cheers, Gerd
[Qemu-devel] buildbot failure in qemu on ppc-next_i386_debian_6_0
The Buildbot has detected a new failure on builder ppc-next_i386_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/ppc-next_i386_debian_6_0/builds/361 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this build Build Source Stamp: [branch ppc-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] Does Qemu simulate the softmmu for memory data access?
Hi, I tried to trace the quest memory access for the load instructions. However, it seems that the softmmu of qemu only works when qemu fetches the guest code, like ldub_code? Is there any place that will call the softmmu for quest memory access, like ldub_data? Thanks. Steven
[Qemu-devel] buildbot failure in qemu on ppc-next_x86_64_debian_6_0
The Buildbot has detected a new failure on builder ppc-next_x86_64_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/ppc-next_x86_64_debian_6_0/builds/361 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_ppc-next' triggered this build Build Source Stamp: [branch ppc-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] qemu log function to print out the registers of the guest
Hi, I would like to is there any function that could log the register content of the guest machine, like info registers in the qemu monitor mode. Thanks. steven
[Qemu-devel] Proper usage of qemu_get_clock_*
Hello! I'm looking at some places in qemu and saw that some code calculate next timer alarm (for qemu_mod_timer) use qemu_get_clock_* and specify specific timer, like vm_timer. I think, that it's more clean is to use timer's clock instead of hardcoded clock. For example, instead of qemu_mod_timer(key_timer, qemu_get_clock_ns(vm_clock) + write this: qemu_mod_timer(key_timer, qemu_get_clock_ns(key_timer-clock) + It will be much cleaner and more understandable. I understand, that in some places we really need another clock, compared to those which in the timer. Am I right? I can make a patch for that (or pull request to my git repo) -- Segmentation fault
[Qemu-devel] Timers speedup
Hello. Please advice me how I can speed up all timers inside VM. I mean patch for qemu that will tick all timers, say, twice as faster. So I expect, that time in VM will go twice as fast, sleep 1 command will last 0.5 real seconds, real time clocks will be twice as faster, TCP timeouts will be proportionally shorter than in real life and so on I began to modify sources for changing PIT, HPET, ACPI, LAPIC and KVM-clock, but I think that there is more proper way. -- Segmentation fault
Re: [Qemu-devel] Does Qemu simulate the softmmu for memory data access?
Hi, I tried to trace the quest memory access for the load instructions. However, it seems that the softmmu of qemu only works when qemu fetches the guest code, like ldub_code? Is there any place that will call the softmmu for quest memory access, like ldub_data? Thanks. You can take a look on qemu_ld/qemu_st, they are TCG IR for guest memory access. For example, take a look on tcg_out_qemu_ld (tcg/i386/tcg-target.c). I only give you a brief introduction on what tcg_out_qemu_ld does here, you can search in the mailing list archieve for more information. Basically, you need to distinguish the following terms: - GVA (Guest Virtual Address) - GPA (Guest Physical Address) - HVA (Host Virtual Address) QEMU will allocate it's virtual memory to the guest virtual machine running upon it, so what guest OS thought as its (guest) physical memory actually is QEMU's virtual memory. When guest application access the guest memory, it'll use GVA. Then guest OS will turn GVA into GPA by using (guest) page tables. Finally, QEMU will turn GPA into HVA (it knows the mapping since it allocates to the guest virtual machine), and use HVA for usual memory access. In order to speedup the address translation (GVA - GPA - HVA), QEMU has a software TLB (`grep tlb_table`) which stores GVA - HVA mapping. For each guest memory access, it'll look for software TLB first (now I am describing what tcg_out_qemu_ld does). If TLB hit, then you have corresponding HVA ready to use; otherwise, it'll call qemu_ld_helpers which are actually functions synthesized by macro in files softmmu_*.h. Note that what I am describing above is for QEMU system mode. Good luck! HTH, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[Qemu-devel] buildbot failure in qemu on s390-next_x86_64_debian_6_0
The Buildbot has detected a new failure on builder s390-next_x86_64_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/s390-next_x86_64_debian_6_0/builds/362 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_s390-next' triggered this build Build Source Stamp: [branch s390-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
Re: [Qemu-devel] [PATCH] block-migration: deprecate block migration for the 1.2 release
Hi Stefan, Thanks for your explanation. On Wed, Aug 15, 2012 at 2:38 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: I think when classic block migration is removed for good it should be just as easy to use through libvirt using TCP because that's still a valid use case and probably the simplest one to get started. (Libvirt could orchestrate an NBD connection behind the scenes, for example.) I really don't care which protocol is used, as long as libvirt handles it for me. Kind regards, Ruben
[Qemu-devel] Apparent USB assignment issue on 1.1+
Hello. This issue has been reported several times already, but I can't reproduce it locally. Gerd, can you please take a look, maybe you may ask better question to the OP(s) about what to try. https://bugs.launchpad.net/qemu/+bug/1033727 http://bugs.debian.org/683983 Gerd, I tried to catch you on irc for several days, but you appears to be a non-frequent guest there these days... :) Thanks, /mjt
[Qemu-devel] buildbot failure in qemu on s390-next_i386_debian_6_0
The Buildbot has detected a new failure on builder s390-next_i386_debian_6_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/s390-next_i386_debian_6_0/builds/362 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_s390-next' triggered this build Build Source Stamp: [branch s390-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
Re: [Qemu-devel] [Qemu-trivial] [PATCH] srp: Don't use QEMU_PACKED for single elements of a structured type
On Wed, Aug 15, 2012 at 05:59:26PM +0200, Stefan Weil wrote:
Am 15.08.2012 16:16, schrieb Stefan Hajnoczi:
On Fri, Aug 10, 2012 at 10:03:27PM +0200, Stefan Weil wrote:
QEMU_PACKED results in a MinGW compiler warning when it is
used for single structure elements:
warning: 'gcc_struct' attribute ignored
Using QEMU_PACKED for the whole structure avoids the compiler warning
without changing the memory layout.
Quick link for other reviewers:
http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Type-Attributes.html#Type-Attributes
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/srp.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/srp.h b/hw/srp.h
index 3009bd5..5e0cad5 100644
--- a/hw/srp.h
+++ b/hw/srp.h
@@ -177,13 +177,13 @@ struct srp_tsk_mgmt {
uint8_treserved1[6];
uint64_t tag;
uint8_treserved2[4];
-uint64_t lun QEMU_PACKED;
+uint64_t lun;
uint8_treserved3[2];
uint8_ttsk_mgmt_func;
uint8_treserved4;
uint64_t task_tag;
uint8_treserved5[8];
-};
+} QEMU_PACKED;
Here I actually see a difference for the uint64_t task_tag field.
Previously it was not packed, now it is packed and because it has 4 *
uint8_t before it there will be a difference in layout.
Looking at how QEMU accesses srp_tsk_mgmt, I think we're safe because we
never actually access task_tag?
Ben: Any thoughts on this patch?
Stefan
4 * uint8_t + 4 bytes from the packed lun, so there is no change
for task_tag, it's always on a 8 byte boundary!
Ah, yes, I see it now! Glad we're switching to struct-level packing :).
Stefan
Re: [Qemu-devel] qemu log function to print out the registers of the guest
I would like to is there any function that could log the register content of the guest machine, like info registers in the qemu monitor mode. Why not check how info registes be implemented in QEMU? ;) I guess you just have to log env-regs or something like that. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Apparent USB assignment issue on 1.1+
On 08/16/12 09:45, Michael Tokarev wrote: Hello. This issue has been reported several times already, but I can't reproduce it locally. Gerd, can you please take a look, maybe you may ask better question to the OP(s) about what to try. https://bugs.launchpad.net/qemu/+bug/1033727 http://patchwork.ozlabs.org/patch/176030/ could fix this. If not: enable all usb_host_* tracepoints send log. http://bugs.debian.org/683983 No idea, must be some QOM thingy. cheers, Gerd
[Qemu-devel] [PATCH 0/4] add support for spice migration
The following series introduces support for keeping the spice session active after migration. For more details about spice seamless migration, see http://lists.freedesktop.org/archives/spice-devel/2012-August/010412.html Spice branches with seamless migration support can be found at: spice-protocol: http://cgit.freedesktop.org/~yhalperi/spice-protocol/log/?h=seamless-migration.v1 spice-common: http://cgit.freedesktop.org/~yhalperi/spice-common/log/ spice: http://cgit.freedesktop.org/~yhalperi/spice/log/?h=seamless-migration.v1 spicei-gtk: http://cgit.freedesktop.org/~yhalperi/spice-gtk/log/ Regards, Yonit. Yonit Halperin (4): spice: notify spice server on vm start/stop spice migration: add QEVENT_SPICE_MIGRATE_COMPLETED spice: add 'migrated' flag to spice info spice: adding seamless-migration option to the command line hmp.c|2 ++ monitor.c|1 + monitor.h|1 + qapi-schema.json |5 - qemu-config.c|3 +++ qemu-options.hx |3 +++ ui/spice-core.c | 34 +- 7 files changed, 47 insertions(+), 2 deletions(-) -- 1.7.7.6
[Qemu-devel] [PATCH 1/4] spice: notify spice server on vm start/stop
Spice server needs to know about the vm state in order to prevent
attempts to write to devices when they are stopped, mainly during
the non-live stage of migration.
Instead, spice will take care of restoring this writes, on the migration
target side, after migration completes.
Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
ui/spice-core.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 4fc48f8..32de1f1 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -545,6 +545,18 @@ static int add_channel(const char *name, const char
*value, void *opaque)
return 0;
}
+static void vm_change_state_handler(void *opaque, int running,
+RunState state)
+{
+#if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
+if (running) {
+spice_server_vm_start(spice_server);
+} else {
+spice_server_vm_stop(spice_server);
+}
+#endif
+}
+
void qemu_spice_init(void)
{
QemuOpts *opts = QTAILQ_FIRST(qemu_spice_opts.head);
@@ -718,6 +730,8 @@ void qemu_spice_init(void)
qemu_spice_input_init();
qemu_spice_audio_init();
+qemu_add_vm_change_state_handler(vm_change_state_handler, spice_server);
+
g_free(x509_key_file);
g_free(x509_cert_file);
g_free(x509_cacert_file);
--
1.7.7.6
[Qemu-devel] [PATCH 4/4] spice: adding seamless-migration option to the command line
The seamless-migration flag is required in order to identify
whether libvirt supports the new QEVENT_SPICE_MIGRATE_COMPLETED or not
(by default the flag is off).
New libvirt versions that wait for QEVENT_SPICE_MIGRATE_COMPLETED should turn
on this flag.
When this flag is off, spice fallbacks to its old migration method, which
can result in data loss.
Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
qemu-config.c |3 +++
qemu-options.hx |3 +++
ui/spice-core.c |7 +++
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 5c3296b..b7bb28f 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -524,6 +524,9 @@ QemuOptsList qemu_spice_opts = {
},{
.name = playback-compression,
.type = QEMU_OPT_BOOL,
+}, {
+.name = seamless-migration,
+.type = QEMU_OPT_BOOL,
},
{ /* end of list */ }
},
diff --git a/qemu-options.hx b/qemu-options.hx
index 47cb5bd..0727f4f 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -917,6 +917,9 @@ Enable/disable passing mouse events via vdagent. Default
is on.
@item playback-compression=[on|off]
Enable/disable audio stream compression (using celt 0.5.1). Default is on.
+@item seamless-migration=[on|off]
+Enable/disable spice seamless migration. Default is off.
+
@end table
ETEXI
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 4d3d05e..f5e2d5c 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -581,6 +581,9 @@ void qemu_spice_init(void)
int port, tls_port, len, addr_flags;
spice_image_compression_t compression;
spice_wan_compression_t wan_compr;
+#if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
+bool seamless_migration;
+#endif
qemu_thread_get_self(me);
@@ -724,6 +727,10 @@ void qemu_spice_init(void)
spice_server_set_uuid(spice_server, qemu_uuid);
#endif
+#if SPICE_SERVER_VERSION = 0x000b02 /* 0.11.2 */
+seamless_migration = qemu_opt_get_bool(opts, seamless-migration, 0);
+spice_server_set_seamless_migration(spice_server, seamless_migration);
+#endif
if (0 != spice_server_init(spice_server, core_interface)) {
error_report(failed to initialize spice server);
exit(1);
--
1.7.7.6
Re: [Qemu-devel] Apparent USB assignment issue on 1.1+
On 16 August 2012 09:14, Gerd Hoffmann kra...@redhat.com wrote: On 08/16/12 09:45, Michael Tokarev wrote: This issue has been reported several times already, but I can't reproduce it locally. Gerd, can you please take a look, maybe you may ask better question to the OP(s) about what to try. https://bugs.launchpad.net/qemu/+bug/1033727 http://patchwork.ozlabs.org/patch/176030/ could fix this. If not: enable all usb_host_* tracepoints send log. http://bugs.debian.org/683983 No idea, must be some QOM thingy. The crash on usb_del problem has been discussed on the list before, Paolo posted a sketch of a patch to fix this: http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01357.html I'd forgotten about the issue but I think we should definitely fix for 1.2 if we can. Anthony -- does Paolo's patch look like the right direction? -- PMM
[Qemu-devel] [PATCH 3/4] spice: add 'migrated' flag to spice info
The flag is 'true' when spice migration has completed on the src side.
It is needed for a case where libvirt dies before migration completes
and it misses the event QEVENT_SPICE_MIGRATE_COMPLETED.
When libvirt is restored and queries the migration status, it also needs
to query spice and check if its migration has completed.
Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
hmp.c|2 ++
qapi-schema.json |5 -
ui/spice-core.c |4
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/hmp.c b/hmp.c
index a9d5675..62f4dee 100644
--- a/hmp.c
+++ b/hmp.c
@@ -413,6 +413,8 @@ void hmp_info_spice(Monitor *mon)
monitor_printf(mon, address: %s:% PRId64 [tls]\n,
info-host, info-tls_port);
}
+monitor_printf(mon, migrated: %s\n,
+ info-migrated ? true : false);
monitor_printf(mon, auth: %s\n, info-auth);
monitor_printf(mon, compiled: %s\n, info-compiled_version);
monitor_printf(mon, mouse-mode: %s\n,
diff --git a/qapi-schema.json b/qapi-schema.json
index 3d2b2d1..bf3f924 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -808,6 +808,9 @@
#
# @enabled: true if the SPICE server is enabled, false otherwise
#
+# @migrated: true if the last guest migration completed and spice
+#migration had completed as well. false otherwise.
+#
# @host: #optional The hostname the SPICE server is bound to. This depends on
#the name resolution on the host and may be an IP address.
#
@@ -833,7 +836,7 @@
# Since: 0.14.0
##
{ 'type': 'SpiceInfo',
- 'data': {'enabled': 'bool', '*host': 'str', '*port': 'int',
+ 'data': {'enabled': 'bool', 'migrated': 'bool', '*host': 'str', '*port':
'int',
'*tls-port': 'int', '*auth': 'str', '*compiled-version': 'str',
'mouse-mode': 'SpiceQueryMouseMode', '*channels': ['SpiceChannel']}
}
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 6b4d216..4d3d05e 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -45,6 +45,7 @@ static Notifier migration_state;
static const char *auth = spice;
static char *auth_passwd;
static time_t auth_expires = TIME_MAX;
+static int spice_migration_completed;
int using_spice = 0;
static QemuThread me;
@@ -309,6 +310,7 @@ static void
migrate_connect_complete_cb(SpiceMigrateInstance *sin)
static void migrate_end_complete_cb(SpiceMigrateInstance *sin)
{
monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
+spice_migration_completed = true;
}
#endif
@@ -441,6 +443,7 @@ SpiceInfo *qmp_query_spice(Error **errp)
}
info-enabled = true;
+info-migrated = spice_migration_completed;
addr = qemu_opt_get(opts, addr);
port = qemu_opt_get_number(opts, port, 0);
@@ -494,6 +497,7 @@ static void migration_state_notifier(Notifier *notifier,
void *data)
#ifndef SPICE_INTERFACE_MIGRATION
spice_server_migrate_switch(spice_server);
monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
+spice_migration_completed = true;
#else
spice_server_migrate_end(spice_server, true);
} else if (migration_has_failed(s)) {
--
1.7.7.6
Re: [Qemu-devel] Apparent USB assignment issue on 1.1+
On 16.08.2012 12:14, Gerd Hoffmann wrote: On 08/16/12 09:45, Michael Tokarev wrote: Hello. This issue has been reported several times already, but I can't reproduce it locally. Gerd, can you please take a look, maybe you may ask better question to the OP(s) about what to try. https://bugs.launchpad.net/qemu/+bug/1033727 http://patchwork.ozlabs.org/patch/176030/ could fix this. Interesting. If not: enable all usb_host_* tracepoints send log. Ok, will try to ping the OP... ;) http://bugs.debian.org/683983 No idea, must be some QOM thingy. There are two issues in there -- QOM (assertion failure) is unrelated. The main issue is that win BSODs when trying to use the USB device, but it worked fine in 1.0. I guess the only possible solution here is to try to bisect it. But it wont be easy due to other issues between 1.0 and 1.1. Overall, somehow I thought the two issues are related. Now when I re-read it again, I don't see why I thought so -- that's two different problems apparently. Thank you! /mjt
[Qemu-devel] [PATCH 2/4] spice migration: add QEVENT_SPICE_MIGRATE_COMPLETED
When migrating, libvirt queries the migration status, and upon migration
completions, it closes the migration src. On the other hand, when
migration is completed, spice transfers data from the src to destination
via the client. This data is required for keeping the spice session
after migration, without suffering from data loss and inconsistencies.
In order to allow this data transfer, we add QEVENT for signaling
libvirt that spice migration has completed, and libvirt needs to wait
for this event before quitting the src process.
Signed-off-by: Yonit Halperin yhalp...@redhat.com
---
monitor.c |1 +
monitor.h |1 +
ui/spice-core.c |9 -
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/monitor.c b/monitor.c
index ce42466..584efe0 100644
--- a/monitor.c
+++ b/monitor.c
@@ -455,6 +455,7 @@ static const char *monitor_event_names[] = {
[QEVENT_SUSPEND_DISK] = SUSPEND_DISK,
[QEVENT_WAKEUP] = WAKEUP,
[QEVENT_BALLOON_CHANGE] = BALLOON_CHANGE,
+[QEVENT_SPICE_MIGRATE_COMPLETED] = SPICE_MIGRATE_COMPLETED,
};
QEMU_BUILD_BUG_ON(ARRAY_SIZE(monitor_event_names) != QEVENT_MAX)
diff --git a/monitor.h b/monitor.h
index 47d556b..5fc2983 100644
--- a/monitor.h
+++ b/monitor.h
@@ -43,6 +43,7 @@ typedef enum MonitorEvent {
QEVENT_SUSPEND_DISK,
QEVENT_WAKEUP,
QEVENT_BALLOON_CHANGE,
+QEVENT_SPICE_MIGRATE_COMPLETED,
/* Add to 'monitor_event_names' array in monitor.c when
* defining new events here */
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 32de1f1..6b4d216 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -284,6 +284,7 @@ typedef struct SpiceMigration {
} SpiceMigration;
static void migrate_connect_complete_cb(SpiceMigrateInstance *sin);
+static void migrate_end_complete_cb(SpiceMigrateInstance *sin);
static const SpiceMigrateInterface migrate_interface = {
.base.type = SPICE_INTERFACE_MIGRATION,
@@ -291,7 +292,7 @@ static const SpiceMigrateInterface migrate_interface = {
.base.major_version = SPICE_INTERFACE_MIGRATION_MAJOR,
.base.minor_version = SPICE_INTERFACE_MIGRATION_MINOR,
.migrate_connect_complete = migrate_connect_complete_cb,
-.migrate_end_complete = NULL,
+.migrate_end_complete = migrate_end_complete_cb,
};
static SpiceMigration spice_migrate;
@@ -304,6 +305,11 @@ static void
migrate_connect_complete_cb(SpiceMigrateInstance *sin)
}
sm-connect_complete.cb = NULL;
}
+
+static void migrate_end_complete_cb(SpiceMigrateInstance *sin)
+{
+monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
+}
#endif
/* config string parsing */
@@ -487,6 +493,7 @@ static void migration_state_notifier(Notifier *notifier,
void *data)
} else if (migration_has_finished(s)) {
#ifndef SPICE_INTERFACE_MIGRATION
spice_server_migrate_switch(spice_server);
+monitor_protocol_event(QEVENT_SPICE_MIGRATE_COMPLETED, NULL);
#else
spice_server_migrate_end(spice_server, true);
} else if (migration_has_failed(s)) {
--
1.7.7.6
Re: [Qemu-devel] Apparent USB assignment issue on 1.1+
On 16.08.2012 12:23, Peter Maydell wrote: On 16 August 2012 09:14, Gerd Hoffmann kra...@redhat.com wrote: [] http://bugs.debian.org/683983 No idea, must be some QOM thingy. This was http://bugs.debian.org/684282, unrelated to usb. The crash on usb_del problem has been discussed on the list before, Paolo posted a sketch of a patch to fix this: http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01357.html I'd forgotten about the issue but I think we should definitely fix for 1.2 if we can. Anthony -- does Paolo's patch look like the right direction? Yes, this definitely needs fixing for 1.2. I too almost forgot about that after applying Paolo's patch to debian package... Thanks, /mjt
[Qemu-devel] [PATCH 0/2] vmdk: Fix streamOptimized images
The other day someone turned up in IRC with a VMDK image [1] that can't be converted (or even read). We found the problem, discussed the fix and the reporter promised to send a fix. Well, he didn't in almost a month, so here's my fix. This was reported as https://bugs.launchpad.net/qemu/+bug/1028908 [1] http://downloads.puppetlabs.com/learning/learn_puppet_centos_pe2.5.1_ovf.2012.04.18.zip Kevin Wolf (2): vmdk: Fix header structure vmdk: Read footer for streamOptimized images block/vmdk.c | 18 +- 1 files changed, 17 insertions(+), 1 deletions(-) -- 1.7.6.5
[Qemu-devel] [PATCH 2/2] vmdk: Read footer for streamOptimized images
The footer takes precedence over the header when it exists. It contains
the real grain directory offset that is missing in the header. Without
this patch, streamOptimized images with a footer cannot be read.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vmdk.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 9648398..c243a96 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -35,6 +35,7 @@
#define VMDK4_FLAG_RGD (1 1)
#define VMDK4_FLAG_COMPRESS (1 16)
#define VMDK4_FLAG_MARKER (1 17)
+#define VMDK4_GD_AT_END 0xULL
typedef struct {
uint32_t version;
@@ -451,6 +452,21 @@ static int vmdk_open_vmdk4(BlockDriverState *bs,
if (header.capacity == 0 header.desc_offset) {
return vmdk_open_desc_file(bs, flags, header.desc_offset 9);
}
+
+if (header.gd_offset == VMDK4_GD_AT_END) {
+/*
+ * The footer takes precedence over the header, so read it in. The
+ * footer starts at offset -1024 from the end: One sector for the
+ * footer, and another one for the end-of-stream marker.
+ */
+ret = bdrv_pread(file,
+bs-file-total_sectors * 512 - 1024 + sizeof(magic),
+header, sizeof(header));
+if (ret 0) {
+return ret;
+}
+}
+
l1_entry_sectors = le32_to_cpu(header.num_gtes_per_gte)
* le64_to_cpu(header.granularity);
if (l1_entry_sectors == 0) {
--
1.7.6.5
[Qemu-devel] [PATCH 1/2] vmdk: Fix header structure
Commit bb45ded9 swapped gd_offset and rgd_offset. This is wrong.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vmdk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index daee426..9648398 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -57,8 +57,8 @@ typedef struct {
int64_t desc_offset;
int64_t desc_size;
int32_t num_gtes_per_gte;
-int64_t gd_offset;
int64_t rgd_offset;
+int64_t gd_offset;
int64_t grain_offset;
char filler[1];
char check_bytes[4];
--
1.7.6.5
[Qemu-devel] [PATCH for-1.2] virtio-blk: hide VIRTIO_BLK_F_CONFIG_WCE from old machine types
QEMU has a policy of keeping a stable guest device ABI. When new guest device
features are introduced they must not change hardware info seen by existing
guests. This is important because operating systems or applications may
fingerprint the hardware and refuse to run when the hardware changes. To
always get the latest guest device ABI, run with x86 machine type pc.
This patch hides the new VIRTIO_BLK_F_CONFIG_WCE virtio feature bit from
existing machine types. Only pc-1.2 and later will expose this feature
by default.
For more info on the VIRTIO_BLK_F_CONFIG_WCE feature bit, see:
commit 13e3dce068773c971ff2f19d986378c55897c4a3
Author: Paolo Bonzini pbonz...@redhat.com
Date: Thu Aug 9 16:07:19 2012 +0200
virtio-blk: support VIRTIO_BLK_F_CONFIG_WCE
Also rename VIRTIO_BLK_F_WCACHE to VIRTIO_BLK_F_WCE for consistency with
the spec.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
Anthony Liguori aligu...@us.ibm.com reported:
This broke qemu-test because it changed the pc-1.0 machine type:
Setting guest RANDOM seed to 47167
*** Running tests ***
Running test /tests/finger-print.sh...OK
--- fingerprints/pc-1.0.x86_642011-12-18 13:08:40.0 -0600
+++ fingerprint.txt 2012-08-12 13:30:48.0 -0500
@@ -55,7 +55,7 @@
/sys/bus/pci/devices/:00:06.0/subsystem_device=0x0002
/sys/bus/pci/devices/:00:06.0/class=0x01
/sys/bus/pci/devices/:00:06.0/revision=0x00
-/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x710006d4
+/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x71000ed4
/sys/class/dmi/id/bios_vendor=Bochs
/sys/class/dmi/id/bios_date=01/01/2007
/sys/class/dmi/id/bios_version=Bochs
Guest fingerprint changed for pc-1.0!
Reported-by: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
Anthony, does this fix your test case?
hw/pc_piix.c|4
hw/virtio-blk.c |4 +++-
hw/virtio-blk.h |1 +
hw/virtio-pci.c |1 +
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0c0096f..d68dbb2 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -375,6 +375,10 @@ static QEMUMachine pc_machine_v1_2 = {
.driver = qxl,\
.property = vgamem_mb,\
.value= stringify(8),\
+},{\
+.driver = virtio-blk-pci,\
+.property = config-wce,\
+.value= off,\
}
static QEMUMachine pc_machine_v1_1 = {
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index fd8fa90..0bc2b5e 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -533,7 +533,9 @@ static uint32_t virtio_blk_get_features(VirtIODevice *vdev,
uint32_t features)
features |= (1 VIRTIO_BLK_F_BLK_SIZE);
features |= (1 VIRTIO_BLK_F_SCSI);
-features |= (1 VIRTIO_BLK_F_CONFIG_WCE);
+if (s-blk-config_wce) {
+features |= (1 VIRTIO_BLK_F_CONFIG_WCE);
+}
if (bdrv_enable_write_cache(s-bs))
features |= (1 VIRTIO_BLK_F_WCE);
diff --git a/hw/virtio-blk.h b/hw/virtio-blk.h
index 35834cf..454f445 100644
--- a/hw/virtio-blk.h
+++ b/hw/virtio-blk.h
@@ -104,6 +104,7 @@ struct VirtIOBlkConf
BlockConf conf;
char *serial;
uint32_t scsi;
+uint32_t config_wce;
};
#define DEFINE_VIRTIO_BLK_FEATURES(_state, _field) \
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 5e6e09e..2a3d86f 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -886,6 +886,7 @@ static Property virtio_blk_properties[] = {
#ifdef __linux__
DEFINE_PROP_BIT(scsi, VirtIOPCIProxy, blk.scsi, 0, true),
#endif
+DEFINE_PROP_BIT(config-wce, VirtIOPCIProxy, blk.config_wce, 0, true),
DEFINE_PROP_BIT(ioeventfd, VirtIOPCIProxy, flags,
VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
DEFINE_PROP_UINT32(vectors, VirtIOPCIProxy, nvectors, 2),
DEFINE_VIRTIO_BLK_FEATURES(VirtIOPCIProxy, host_features),
--
1.7.10.4
[Qemu-devel] [PATCH] Documentation: Warn against qemu-img on active image
People have repeatedly expected that you can do things like snapshotting
an image with qemu-img while a qemu instance is running. Maybe we need
to consider locking the files while they are in use, but having a
warning in the qemu-img manpage is doable for 1.2 and can't hurt anyway.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-img.texi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu-img.texi b/qemu-img.texi
index 77c6d0b..0b363e7 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -4,6 +4,14 @@ usage: qemu-img command [command options]
@c man end
@end example
+@c man begin DESCRIPTION
+qemu-img allows to create, convert and modify images offline. It can handle all
+image formats supported by QEMU.
+
+@b{Warning:} Never use qemu-img to modify images in use by a running virtual
+machine or any other process, this may destroy the image.
+@c man end
+
@c man begin OPTIONS
The following commands are supported:
--
1.7.6.5
[Qemu-devel] [RESEND][PATCH for 1.2] audio: Make pcspk card selectable again
Since we moved pcspk into hwlib, CONFIG_PCSPK is no longer defined per target. Therefore, statically built soundhw array in arch_init.c stopped including this card. Work around this by re-adding this define to config-target.mak. Long-term, a dynamic creation of this soundhw list will be necessary. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- configure |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/configure b/configure index be292fe..672da59 100755 --- a/configure +++ b/configure @@ -3902,6 +3902,11 @@ if test $target_bsd_user = yes ; then echo CONFIG_BSD_USER=y $config_target_mak fi +# the static way of configuring available audio cards requires this workaround +if test $target_user_only != yes grep -q CONFIG_PCSPK $source_path/default-configs/$target.mak; then + echo CONFIG_PCSPK=y $config_target_mak +fi + # generate QEMU_CFLAGS/LDFLAGS for targets cflags= -- 1.7.3.4
Re: [Qemu-devel] [PATCH for-1.2] virtio-blk: hide VIRTIO_BLK_F_CONFIG_WCE from old machine types
Am 16.08.2012 10:57, schrieb Stefan Hajnoczi: QEMU has a policy of keeping a stable guest device ABI. When new guest device features are introduced they must not change hardware info seen by existing guests. This is important because operating systems or applications may fingerprint the hardware and refuse to run when the hardware changes. To always get the latest guest device ABI, run with x86 machine type pc. This patch hides the new VIRTIO_BLK_F_CONFIG_WCE virtio feature bit from existing machine types. Only pc-1.2 and later will expose this feature by default. For more info on the VIRTIO_BLK_F_CONFIG_WCE feature bit, see: commit 13e3dce068773c971ff2f19d986378c55897c4a3 Author: Paolo Bonzini pbonz...@redhat.com Date: Thu Aug 9 16:07:19 2012 +0200 virtio-blk: support VIRTIO_BLK_F_CONFIG_WCE Also rename VIRTIO_BLK_F_WCACHE to VIRTIO_BLK_F_WCE for consistency with the spec. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Kevin Wolf kw...@redhat.com Anthony Liguori aligu...@us.ibm.com reported: This broke qemu-test because it changed the pc-1.0 machine type: Setting guest RANDOM seed to 47167 *** Running tests *** Running test /tests/finger-print.sh... OK --- fingerprints/pc-1.0.x86_64 2011-12-18 13:08:40.0 -0600 +++ fingerprint.txt 2012-08-12 13:30:48.0 -0500 @@ -55,7 +55,7 @@ /sys/bus/pci/devices/:00:06.0/subsystem_device=0x0002 /sys/bus/pci/devices/:00:06.0/class=0x01 /sys/bus/pci/devices/:00:06.0/revision=0x00 -/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x710006d4 +/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x71000ed4 /sys/class/dmi/id/bios_vendor=Bochs /sys/class/dmi/id/bios_date=01/01/2007 /sys/class/dmi/id/bios_version=Bochs Guest fingerprint changed for pc-1.0! Reported-by: Anthony Liguori aligu...@us.ibm.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- Anthony, does this fix your test case? Looks good to me, but I think I'll wait for Anthony to check it. Kevin
Re: [Qemu-devel] [PATCH for-1.2] virtio-blk: hide VIRTIO_BLK_F_CONFIG_WCE from old machine types
On Thu, Aug 16, 2012 at 10:07 AM, Kevin Wolf kw...@redhat.com wrote: Am 16.08.2012 10:57, schrieb Stefan Hajnoczi: QEMU has a policy of keeping a stable guest device ABI. When new guest device features are introduced they must not change hardware info seen by existing guests. This is important because operating systems or applications may fingerprint the hardware and refuse to run when the hardware changes. To always get the latest guest device ABI, run with x86 machine type pc. This patch hides the new VIRTIO_BLK_F_CONFIG_WCE virtio feature bit from existing machine types. Only pc-1.2 and later will expose this feature by default. For more info on the VIRTIO_BLK_F_CONFIG_WCE feature bit, see: commit 13e3dce068773c971ff2f19d986378c55897c4a3 Author: Paolo Bonzini pbonz...@redhat.com Date: Thu Aug 9 16:07:19 2012 +0200 virtio-blk: support VIRTIO_BLK_F_CONFIG_WCE Also rename VIRTIO_BLK_F_WCACHE to VIRTIO_BLK_F_WCE for consistency with the spec. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Signed-off-by: Kevin Wolf kw...@redhat.com Anthony Liguori aligu...@us.ibm.com reported: This broke qemu-test because it changed the pc-1.0 machine type: Setting guest RANDOM seed to 47167 *** Running tests *** Running test /tests/finger-print.sh... OK --- fingerprints/pc-1.0.x86_64 2011-12-18 13:08:40.0 -0600 +++ fingerprint.txt 2012-08-12 13:30:48.0 -0500 @@ -55,7 +55,7 @@ /sys/bus/pci/devices/:00:06.0/subsystem_device=0x0002 /sys/bus/pci/devices/:00:06.0/class=0x01 /sys/bus/pci/devices/:00:06.0/revision=0x00 -/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x710006d4 +/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x71000ed4 /sys/class/dmi/id/bios_vendor=Bochs /sys/class/dmi/id/bios_date=01/01/2007 /sys/class/dmi/id/bios_version=Bochs Guest fingerprint changed for pc-1.0! Reported-by: Anthony Liguori aligu...@us.ibm.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- Anthony, does this fix your test case? Looks good to me, but I think I'll wait for Anthony to check it. Yep, we definitely need to check because I haven't run qemu-test myself. Stefan
Re: [Qemu-devel] [PATCH 2/2] vmdk: Read footer for streamOptimized images
On Thu, Aug 16, 2012 at 9:54 AM, Kevin Wolf kw...@redhat.com wrote:
The footer takes precedence over the header when it exists. It contains
the real grain directory offset that is missing in the header. Without
this patch, streamOptimized images with a footer cannot be read.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vmdk.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 9648398..c243a96 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -35,6 +35,7 @@
#define VMDK4_FLAG_RGD (1 1)
#define VMDK4_FLAG_COMPRESS (1 16)
#define VMDK4_FLAG_MARKER (1 17)
+#define VMDK4_GD_AT_END 0xULL
typedef struct {
uint32_t version;
@@ -451,6 +452,21 @@ static int vmdk_open_vmdk4(BlockDriverState *bs,
if (header.capacity == 0 header.desc_offset) {
return vmdk_open_desc_file(bs, flags, header.desc_offset 9);
}
+
+if (header.gd_offset == VMDK4_GD_AT_END) {
+/*
+ * The footer takes precedence over the header, so read it in. The
+ * footer starts at offset -1024 from the end: One sector for the
+ * footer, and another one for the end-of-stream marker.
+ */
+ret = bdrv_pread(file,
+bs-file-total_sectors * 512 - 1024 + sizeof(magic),
+header, sizeof(header));
+if (ret 0) {
+return ret;
+}
+}
+
l1_entry_sectors = le32_to_cpu(header.num_gtes_per_gte)
* le64_to_cpu(header.granularity);
if (l1_entry_sectors == 0) {
I think we should check the magic number or marker before trusting the
contents of the footer.
Stefan
[Qemu-devel] Slow inbound traffic on macvtap interfaces
I'm experiencing a problem with qemu + macvtap which I can reproduce on a variety of hardware, with kernels varying from 3.0.4 (the oldest I tried) to 3.5.1 and with qemu[-kvm] versions 0.14.1, 1.0, and 1.1. Large data transfers over TCP into a guest from another machine on the network are very slow (often less than 100kB/s) whereas transfers outbound from the guest, between two guests on the same host, or between the guest and its host run at normal speeds (= 50MB/s). The slow inbound data transfer speeds up substantially when a ping flood is aimed either at the host or the guest, or when the qemu process is straced. Presumably both of these are ways to wake up something that is otherwise sleeping too long? For example, I can run ip addr add 192.168.1.2/24 dev eth0 ip link set eth0 up ip link add link eth0 name tap0 address 02:02:02:02:02:02 type macvtap mode bridge ip link set tap0 up qemu-kvm -hda debian.img -cpu host -m 512 -vnc :0 \ -net nic,model=virtio,macaddr=02:02:02:02:02:02 \ -net tap,fd=3 3/dev/tap$( /sys/class/net/tap0/ifindex) on one physical host which is otherwise completely idle. From a second physical host on the same network, I then scp a large (say 50MB) file onto the new guest. On a gigabit LAN, speeds consistently drop to less than 100kB/s as the transfer progresses, within a second of starting. The choice of virtio virtual nic in the above isn't significant: the same thing happens with e1000 or rtl8139. You can also replace the scp with a straight netcat and see the same effect. Doing the transfer in the other direction (i.e. copying a large file from the guest to an external host) achieves 50MB/s or faster as expected. Copying between two guests on the same host (i.e. taking advantage of the 'mode bridge') is also fast. If I create a macvlan device attached to eth0 and move the host IP address to that, I can communicate between the host itself and the guest because of the 'mode bridge'. Again, this case is fast in both directions. Using a bridge and a standard tap interface, transfers in and out are fast too: ip tuntap add tap0 mode tap brctl addbr br0 brctl addif br0 eth0 brctl addif br0 tap1 ip link set eth0 up ip link set tap0 up ip link set br0 up ip addr add 192.168.1.2/24 dev br0 qemu-kvm -hda debian.img -cpu host -m 512 -vnc :0 \ -net nic,model=virtio,macaddr=02:02:02:02:02:02 \ -net tap,script=no,downscript=no,ifname=tap0 As mentioned in the summary at the beginning of this report, when I strace a guest in the original configuration which is receiving data slowly, the data rate improves from less than 100kB/s to around 3.1MB/s. Similarly, if I ping flood either the guest or the host it is running on from another machine on the network, the transfer rate improves to around 1.1MB/s. This seems quite suggestive of a problem with delayed wake-up of the guest. Two reasonably up-to-date examples of machines I've reproduced this on are my laptop with an r8169 gigabit ethernet card, Debian qemu-kvm 1.0 and upstream 3.4.8 kernel whose .config and boot dmesg are at http://cdw.me.uk/tmp/laptop-config.txt http://cdw.me.uk/tmp/laptop-dmesg.txt and one of our large servers with an igb gigabit ethernet card, upstream qemu-kvm 1.1.1 and upstream 3.5.1 linux: http://cdw.me.uk/tmp/server-config.txt http://cdw.me.uk/tmp/server-dmesg.txt For completeness, I've put the Debian 6 test image I've been using for testing at http://cdw.me.uk/tmp/test-debian.img.xz though I've see the same problem from a variety of guest operating systems. (In fact, I've not yet found any combination of host kernel, guest OS and hardware which doesn't show these symptoms, so it seems to be very easy to reproduce.) Cheers, Chris.
Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
On 08/16/2012 06:22 AM, liu ping fan wrote:
On Tue, Aug 14, 2012 at 6:49 PM, Avi Kivity a...@redhat.com wrote:
On 08/14/2012 11:30 AM, liu ping fan wrote:
To make memoryRegion survive without the protection of qemu big lock,
we need to pin its based Object.
In current code, the type of mr-opaque are quite different. Lots of
them are Object, but quite of them are not yet.
The most challenge for changing from memory_region_init_io(..., void
*opaque, ...) to memory_region_init_io(..., Object *opaque,...) is
such codes:
hw/ide/cmd646.c:
static void setup_cmd646_bar(PCIIDEState *d, int bus_num)
{
IDEBus *bus = d-bus[bus_num];
CMD646BAR *bar = d-cmd646_bar[bus_num];
bar-bus = bus;
bar-pci_dev = d;
memory_region_init_io(bar-cmd, cmd646_cmd_ops, bar, cmd646-cmd, 4);
memory_region_init_io(bar-data, cmd646_data_ops, bar, cmd646-data,
8);
}
If we passed in mr's based Object @d to substitute @bar, then we can
not pass the extra info @bus_num.
To solve such issue, introduce extra member Object *base for MemoryRegion.
diff --git a/memory.c b/memory.c
index 643871b..afd5dea 100644
--- a/memory.c
+++ b/memory.c
@@ -931,6 +931,7 @@ static void memory_region_dispatch_write(MemoryRegion
*mr,
void memory_region_init_io(MemoryRegion *mr,
const MemoryRegionOps *ops,
+ Object *base,
void *opaque,
const char *name,
uint64_t size)
@@ -938,6 +939,7 @@ void memory_region_init_io(MemoryRegion *mr,
memory_region_init(mr, name, size);
mr-ops = ops;
mr-opaque = opaque;
+mr-base = base;
mr-terminates = true;
mr-destructor = memory_region_destructor_iomem;
mr-ram_addr = ~(ram_addr_t)0;
diff --git a/memory.h b/memory.h
index bd1bbae..2746e70 100644
--- a/memory.h
+++ b/memory.h
@@ -120,6 +120,7 @@ struct MemoryRegion {
/* All fields are private - violators will be prosecuted */
const MemoryRegionOps *ops;
void *opaque;
+Object *base;
MemoryRegion *parent;
Int128 size;
target_phys_addr_t addr;
Any comment?
I prefer that we convert the third parameter (opaque) to be an Object.
That is a huge change, but I think it will improve the code base overall.
Object may be many different opaque, and each has different
MemoryRegionOps. We need to pass in both object and opaque.
Why? Usually there's a 1:1 mapping between object and opaque. Can you
show cases where there isn't?
Maybe we can use Object's property to store the pair (mr, opaque),
then we can use mr as key to get opaque in mmio-dispatch, but the
property's query will hurt the performance.
Or define a new struct X {Object *base, void *opaque}, and pass it to
memory_region_init_io() to substitute void *opaque . Finally,
reclaim X in memory_region_destroy().
Usually the access callback can just cast the object to the real type.
That's all that's needed.
Other options are:
1) add MemoryRegionOps::ref(MemoryRegion *) and ::unref(MemoryRegion *)
If NULL, these callbacks are ignored. If not, they are called with the
MemoryRegion as a parameter. Their responsibility is to derive the
Object from the MemoryRegion (through the opaque or using
container_of()) and ref or unref it respectively.
2) add Object *MemoryRegionOps::object(MemoryRegion *)
Similar; if NULL it is ignored, otherwise it is used to derive the
Object, which the memory core will ref and unref.
3) add bool MemoryRegionOps::opaque_is_object
Tells the memory core that it is safe to cast the opaque into an Object.
Above methods, the process of derive the Object will be hard, we can
not tell opaque is Object or not without something like trycatch
Take for example e1000. It passes E1000State as the opaque, which is a
PCIDevice, which is a DeviceState, which is an Object. So for that
device, nothing needs to be done.
4) add memory_region_set_object(MemoryRegion *, Object *)
Like your proposal, but avoids adding an extra paramter and changing all
call sites.
Yeah, this seems the easy one.
Easy but wrong, IMO.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] QEMU 1.2 Test Day - August 16 2012
On Tue, Aug 14, 2012 at 2:37 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Thu, Aug 2, 2012 at 1:22 PM, Stefan Hajnoczi stefa...@gmail.com wrote: I have set up the QEMU 1.2 Testing wiki page and suggest August 16 as the Test Day: http://wiki.qemu.org/Planning/1.2/Testing QEMU 1.2 Test Day is only 2 days away! Please help test QEMU 1.2-rc and add yourself to the wiki: http://wiki.qemu.org/Planning/1.2/Testing More about QEMU 1.2 Test Day from my original email: An update on Test Day and the QEMU 1.2 release: Postponing Test Day until -rc0 is tagged. v1.2-rc0 has not been tagged yet. Release blockers being discussed and will be resolved before -rc0 is tagged. If you are hitting build failures or critical bugs in qemu.git/master at this point, please discuss on qemu-devel@nongnu.org as soon as possible and mention 1.2 in the email subject line. Stefan
[Qemu-devel] What is the cause of -net socket, mcast bad performance?
Hello. On my PC, tap -- bridge -- tap networking gives 600 megbit. Exactly the same, but -net socket,mcast gives about 1 megbit (!) I do not understand why. In my mind, -net socket,mcast is the same as tap, but ethernet frames are going in much simplier way: instead of qemu1 - /dev/tun - kernel/bridge - /dev/tun - qemu2 in such way: qemu1 - qemu2 Does somebody knows, why -net socket,mcast works so slowly? People said, that VDE performace is like TAP. Why not to make same performace on -net socket,mcast ? -- Segmentation fault
Re: [Qemu-devel] [PATCH 1/4] spice: notify spice server on vm start/stop
On 08/16/12 10:23, Yonit Halperin wrote: Spice server needs to know about the vm state in order to prevent attempts to write to devices when they are stopped, mainly during the non-live stage of migration. Why this new hook? qemu already notifies spice-server using QXLWorker start/stop callbacks. cheers, Gerd
[Qemu-devel] [PATCH v2 2/2] vmdk: Read footer for streamOptimized images
The footer takes precedence over the header when it exists. It contains
the real grain directory offset that is missing in the header. Without
this patch, streamOptimized images with a footer cannot be read.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
v2:
- Enough footer sanity checks, I hope? :-)
block/vmdk.c | 56
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 9648398..bba4c61 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -35,6 +35,7 @@
#define VMDK4_FLAG_RGD (1 1)
#define VMDK4_FLAG_COMPRESS (1 16)
#define VMDK4_FLAG_MARKER (1 17)
+#define VMDK4_GD_AT_END 0xULL
typedef struct {
uint32_t version;
@@ -115,6 +116,13 @@ typedef struct VmdkGrainMarker {
uint8_t data[0];
} VmdkGrainMarker;
+enum {
+MARKER_END_OF_STREAM= 0,
+MARKER_GRAIN_TABLE = 1,
+MARKER_GRAIN_DIRECTORY = 2,
+MARKER_FOOTER = 3,
+};
+
static int vmdk_probe(const uint8_t *buf, int buf_size, const char *filename)
{
uint32_t magic;
@@ -451,6 +459,54 @@ static int vmdk_open_vmdk4(BlockDriverState *bs,
if (header.capacity == 0 header.desc_offset) {
return vmdk_open_desc_file(bs, flags, header.desc_offset 9);
}
+
+if (le64_to_cpu(header.gd_offset) == VMDK4_GD_AT_END) {
+/*
+ * The footer takes precedence over the header, so read it in. The
+ * footer starts at offset -1024 from the end: One sector for the
+ * footer, and another one for the end-of-stream marker.
+ */
+struct {
+struct {
+uint64_t val;
+uint32_t size;
+uint32_t type;
+uint8_t pad[512 - 16];
+} QEMU_PACKED footer_marker;
+
+uint32_t magic;
+VMDK4Header header;
+uint8_t pad[512 - 4 - sizeof(VMDK4Header)];
+
+struct {
+uint64_t val;
+uint32_t size;
+uint32_t type;
+uint8_t pad[512 - 16];
+} QEMU_PACKED eos_marker;
+} QEMU_PACKED footer;
+
+ret = bdrv_pread(file,
+bs-file-total_sectors * 512 - 1536,
+footer, sizeof(footer));
+if (ret 0) {
+return ret;
+}
+
+/* Some sanity checks for the footer */
+if (be32_to_cpu(footer.magic) != VMDK4_MAGIC ||
+le32_to_cpu(footer.footer_marker.size) != 0 ||
+le32_to_cpu(footer.footer_marker.type) != MARKER_FOOTER ||
+le64_to_cpu(footer.eos_marker.val) != 0 ||
+le32_to_cpu(footer.eos_marker.size) != 0 ||
+le32_to_cpu(footer.eos_marker.type) != MARKER_END_OF_STREAM)
+{
+return -EINVAL;
+}
+
+header = footer.header;
+}
+
l1_entry_sectors = le32_to_cpu(header.num_gtes_per_gte)
* le64_to_cpu(header.granularity);
if (l1_entry_sectors == 0) {
--
1.7.6.5
Re: [Qemu-devel] [PATCH] Documentation: Warn against qemu-img on active image
On 16 August 2012 10:00, Kevin Wolf kw...@redhat.com wrote:
People have repeatedly expected that you can do things like snapshotting
an image with qemu-img while a qemu instance is running. Maybe we need
to consider locking the files while they are in use, but having a
warning in the qemu-img manpage is doable for 1.2 and can't hurt anyway.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-img.texi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/qemu-img.texi b/qemu-img.texi
index 77c6d0b..0b363e7 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -4,6 +4,14 @@ usage: qemu-img command [command options]
@c man end
@end example
Some minor grammar tweaks:
+@c man begin DESCRIPTION
+qemu-img allows to create, convert and modify images offline. It can handle
all
+image formats supported by QEMU.
allows you to.
+
+@b{Warning:} Never use qemu-img to modify images in use by a running virtual
+machine or any other process, this may destroy the image.
; or , because.
+@c man end
+
@c man begin OPTIONS
The following commands are supported:
--
1.7.6.5
-- PMM
Re: [Qemu-devel] [PATCH v2 2/2] vmdk: Read footer for streamOptimized images
On Thu, Aug 16, 2012 at 10:50 AM, Kevin Wolf kw...@redhat.com wrote: The footer takes precedence over the header when it exists. It contains the real grain directory offset that is missing in the header. Without this patch, streamOptimized images with a footer cannot be read. Signed-off-by: Kevin Wolf kw...@redhat.com --- v2: - Enough footer sanity checks, I hope? :-) block/vmdk.c | 56 1 files changed, 56 insertions(+), 0 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Re: [Qemu-devel] [PATCH 13/18] qapi: Convert savevm
On 08/15/2012 09:49 PM, Eric Blake wrote:
On 08/15/2012 01:41 AM, Pavel Hrdina wrote:
Signed-off-by: Pavel Hrdinaphrd...@redhat.com
---
I'm focusing my review more on the public interface (since that's what
affects libvirt), and therefore glanced through 1 through 12 but did not
pay close attention to them.
hmp-commands.hx | 2 +-
hmp.c| 10 ++
hmp.h| 1 +
qapi-schema.json | 19 +++
qmp-commands.hx | 29 +
savevm.c | 25 +
sysemu.h | 1 -
7 files changed, 69 insertions(+), 18 deletions(-)
+
+void hmp_vm_snapshot_save(Monitor *mon, const QDict *qdict)
+{
+const char *name = qdict_get_try_str(qdict, name);
In the cover letter, you said and for QMP you have to always provide
name parameter - but this says 'name' is optional and can still be
empty (id only).
I said in cover letter that the last two patches introduce this
functionality.
+++ b/qapi-schema.json
@@ -2356,3 +2356,22 @@
# Since: 1.2.0
##
{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
+
+##
+# @vm-snapshot-save:
+#
+# Create a snapshot of the whole virtual machine. If 'tag' is provided,
'tag' is a misnomer, since you list @name as the parameter name.
+# it is used as human readable identifier. If there is already a snapshot
+# with the same tag or ID, it is replaced.
+#
+# The VM is automatically stopped and resumed and saving a snapshot can take
+# a long time.
+#
+# @name: tag or id of new or existing snapshot
Here, you document @name as required,
+#
+# Returns: Nothing on success
+# If an error occurs, GenericError with error message
+#
+# Since: 1.2
We missed 1.2 hard freeze. This better be 1.3.
+##
+{ 'command': 'vm-snapshot-save', 'data': {'*name': 'str'} }
but here, you listed it as '*name' meaning optional. I'm okay with
leaving name optional, provided that it means that you end up allocating
the next unique id. But if that's the case, then returning nothing is
wrong; this command needs to return { 'id':'int', '*name':'str' }, so
that the user knows what snapshot just got allocated.
If you apply whole patch-series, then you have to for QMP always provide
@name.
As I said above, this behaviour is introduced by last two patches.
+SQMP
+vm-snapshot-save
+--
+
+Create a snapshot of the whole virtual machine. If 'tag' is provided,
+it is used as human readable identifier. If there is already a snapshot
+with the same tag or ID, it is replaced.
+
+The VM is automatically stopped and resumed and saving a snapshot can take
+a long time.
I don't like that this command can take a long time. Just today on
#virt IRC, someone was complaining that 'savevm' HMP cannot be canceled.
If we're going to create a new interface, it would be nicer to create a
command that starts the save process and returns immediately, as well as
commands to track progress, allow an early abort, and send an event on
completion. The HMP 'savevm' interface can issue multiple QMP commands
under the hood to continue with it's blocking behavior, but as long as
we are fixing things, I think the QMP interface should be more powerful.
Well, I could try to do it...with this I'll probably introduce new
command vm-snapshot-save-cancel or vm-snaphsot-cancel as we have migrate
and migrate-cancel.
+
+Arguments:
+
+- name: tag or id of new or existing snapshot
+
+Example:
+
+- { execute: vm-snapshot-save, arguments: { name: my_snapshot } }
+- { return: {} }
Again, you need to return the id of the just-created snapshot.
@@ -2176,21 +2174,20 @@ void do_savevm(Monitor *mon, const QDict *qdict)
}
/* Delete old snapshots of the same name */
-if (name del_existing_snapshots(name, NULL) 0) {
+if (has_name del_existing_snapshots(name, errp) 0) {
Here's hoping later in the series updates this to make saner decisions.
(Maybe I should peruse the entire series before commenting on
individual patches?)
Re: [Qemu-devel] [PATCH 16/18] qapi: Convert info snapshots
On 08/16/2012 06:36 AM, Eric Blake wrote:
On 08/15/2012 01:41 AM, Pavel Hrdina wrote:
Signed-off-by: Pavel Hrdinaphrd...@redhat.com
---
hmp.c| 33 +
hmp.h| 1 +
monitor.c| 2 +-
qapi-schema.json | 34 ++
qmp-commands.hx | 30 ++
savevm.c | 51 ---
sysemu.h | 2 --
7 files changed, 123 insertions(+), 30 deletions(-)
@@ -1053,6 +1053,40 @@
{ 'command': 'query-block-jobs', 'returns': ['BlockJobInfo'] }
##
+# @SnapshotInfo:
+#
We've got competition here:
https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg02961.html
These two patches need to converge into a single design.
I can use his design.
+# Snapshot list. This structure contains list of snapshots for virtual
machine.
+#
+# @id: id of the snapshot.
+#
+# @tag: human readable tag of the snapshot.
+#
+# @vm_size: size of the snapshot in Bytes.
As this is a new QMP command, you should use '-', not '_'. Benoit's
patch named this @vm-state-size.
+#
+# @date: date and time of the snapshot as unix timestamp.
+#
+# @vm_clock: time in the guest in nsecs.
For online internal snapshots (those created by savevm), the vm clock
offset makes sense. But for offline snapshots (those created by
'qemu-img snapshot', with no VM state), there is no vm clock offset.
'qemu-img info' lists 00:00:00.000 as a result, but I wonder if it would
be better to leave this field (and vm-state-size) as #optional and omit
them from the JSON for offline snapshots.
And since qemu refuses to load offline snapshots, it might be worth an
additional field in the JSON that says whether a snapshot is online or
offline, to make it easier for the parsing application to determine
whether it can be loaded or must go through qemu-img while the guest is
offline (then again, keeping vm-state-size as non-optional, and checking
for 0 size, somewhat covers this).
As you said, this is covered and I think that checking for 0 size is
good enough.
+#
+# Since: 1.2
1.3 (entire series...)
Re: [Qemu-devel] What is the cause of -net socket, mcast bad performance?
On Thu, Aug 16, 2012 at 10:38 AM, Марк Коренберг socketp...@gmail.com wrote: On my PC, tap -- bridge -- tap networking gives 600 megbit. Exactly the same, but -net socket,mcast gives about 1 megbit (!) I do not understand why. In my mind, -net socket,mcast is the same as tap, but ethernet frames are going in much simplier way: instead of qemu1 - /dev/tun - kernel/bridge - /dev/tun - qemu2 in such way: qemu1 - qemu2 Does somebody knows, why -net socket,mcast works so slowly? People said, that VDE performace is like TAP. Why not to make same performace on -net socket,mcast ? 600 - 1 Mbit/s performance difference is larger than expected. Can you post more details? 1. qemu and Linux kernel versions 2. qemu command-lines for your tap and mcast setups 3. Which benchmark and the command-line to run the test Stefan
Re: [Qemu-devel] [PATCH 18/18] vm-snapshot-save: add force parameter
On 08/16/2012 07:00 AM, Eric Blake wrote:
On 08/15/2012 01:41 AM, Pavel Hrdina wrote:
HMP command savevm now takes extra optional force parameter to specifi whether
s/specifi/specify/
replace existing snapshot or not.
QMP command vm-snapshot-save has also extra optional force parameter and
name parameter isn't optional anymore.
When HMP omits the name, what name are you using in it's place? Either
a nameless snapshot is okay (and QMP must expose it), or it is an error
(and HMP must now be passing a reasonable name).
/me reads patch
Oh, there was always a name; the default name was a timestamp, and you
moved the timestamp creation into HMP.
+++ b/hmp-commands.hx
@@ -264,19 +264,19 @@ ETEXI
{
.name = savevm,
-.args_type = name:s?,
-.params = [tag|id],
-.help = save a VM snapshot. If no tag or id are provided, a new
snapshot is created,
+.args_type = name:s?,force:b?,
+.params = [tag|id] [on|off],
Rather than sticking 'force' as an optional parameter at the end,
instead you want to add '-f' as a flag at the beginning.
.args_type = force:-b,name:s?,
.params = [-f] name
By doing this, you no longer need 17/18.
Thanks, I'll rewrite it for v2.
+.help = save a VM snapshot. To replace existing snapshot use force
parameter.,
.mhandler.cmd = hmp_vm_snapshot_save,
},
STEXI
@item savevm [@var{tag}|@var{id}]
@findex savevm
-Create a snapshot of the whole virtual machine. If @var{tag} is
-provided, it is used as human readable identifier. If there is already
-a snapshot with the same tag or ID, it is replaced. More info at
-@ref{vm_snapshots}.
+Create a snapshot of the whole virtual machine. Parameter name is optional.
+If @var{tag} is provided, it is used as human readable identifier. If there is
+already a snapshot with the same tag, force argument need to be yes to
s/force argument need/the force argument needs/
+++ b/qapi-schema.json
@@ -2394,21 +2394,23 @@
##
# @vm-snapshot-save:
#
-# Create a snapshot of the whole virtual machine. If 'tag' is provided,
-# it is used as human readable identifier. If there is already a snapshot
-# with the same tag or ID, it is replaced.
+# Create a snapshot of the whole virtual machine. Provided 'tag' is used as
+# human readable identifier. If there is already a snapshot with the same tag,
+# force argument need to be yes to replace it.
s/need to be yes/needs to be 'true'/
#
# The VM is automatically stopped and resumed and saving a snapshot can take
# a long time.
#
-# @name: tag or id of new or existing snapshot
+# @name: tag of new or existing snapshot
Given your new semantics, @name must be tag when @force is false; but
the old HMP semantics allowed 'savevm 1' to rewrite snapshot id 1
regardless of the name, all while keeping the old tag. Does the new HMP
code do an id lookup, and pass in the correct @name to the QMP code?
Should the QMP code allow the same semantics of being able to pass
@force=true and @name=id instead of the normal creation of @name=tag?
You can override existing snapshot specified by id. I'll fix the
documentation.
+#
+# @force: specify whether existing snapshot is replaced or not
Based on the JSON below, this needs an #optional marking, as well as
mentioning that the default is false.
#
# Returns: Nothing on success
# If an error occurs, GenericError with error message
Knowing that a creation failed due to a snapshot already existing by the
same name or id might be worth a distinct error class (do we already
have an error class that we could reuse?)
Regarding the Luiz's new error handling, for new errors we should use
one error class.
Re: [Qemu-devel] [PATCH] pseries: Instantiate USB interface when required
On 16.08.2012, at 04:03, David Gibson wrote: The pseries machine already supports the -vga std option, creating a graphics adapter. However, this is not very useful without being able to add a keyboard and mouse as well. This patch addresses this by adding a USB interface when requested, and automatically adding a USB keyboard and mouse when VGA is enabled. This is a stop gap measure to get usable graphics mode on pseries while waiting for Li Zhang's rework of USB options to go in after 1.2. Signed-off-by: David Gibson da...@gibson.dropbear.id.au Thanks, applied to ppc-next. Anthony, this is a bug fix that IMHO should still go into 1.2. How do we handle this? Should I just send another pull request tagged for 1.2? Alex
[Qemu-devel] Windows slow boot: contractor wanted
Hi, We run a cloud hosting provider using qemu-kvm 1.1, and are keen to find a contractor to track down and fix problems we have with large memory Windows guests booting very slowly - they can take several hours. We previously reported these problems in July (copied below) and they are still present with Linux kernel 3.5.1 and qemu-kvm 1.1.1. This is a serious issue for us which is causing significant pain to our larger Windows VM customers when their servers are offline for many hours during boot. If anyone knowledgeable in the area would be interested in being paid to work on this, or if you know someone who might be, I would be delighted to hear from you. Cheers, Richard. = Previous bug report http://marc.info/?l=qemu-develm=134304194329745 We have been experiencing this problem for a while now too, using qemu-kvm (currently at 1.1.1). Unfortunately, hv_relaxed doesn't seem to fix it. The following command line produces the issue: qemu-kvm -nodefaults -m 4096 -smp 8 -cpu host,hv_relaxed -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda test.img The hardware consists of dual AMD Opteron 6128 processors (16 cores in total) and 64GB of memory. This command line was tested on kernel 3.1.4. I've also tested with -no-hpet. What I have seen is much as described: the memory fills out slowly, and top on the host will show the process using 100% on all allocated CPU cores. The most extreme case was a machine which took something between 6 and 8 hours to boot. This seems to be related to the assigned memory, as described, but also the number of processor cores (which makes sense if we believe it's a timing issue?). I have seen slow-booting guests improved by switching down to a single or even two cores. Matthew, I agree that this seems to be linked to the number of VMs running - in fact, shutting down other VMs on a dedicated test host caused the machine to start booting at a normal speed (with no reboot required). However, the level of contention is never such that this could be explained by the host simply being overcommitted. If it helps anyone, there's an image of the hard drive I've been using to test at: http://46.20.114.253/ It's 5G of gzip file containing a fairly standard Windows 2008 trial installation. Since it's in the trial period, anyone who wants to use it may have to re-arm the trial: http://support.microsoft.com/kb/948472 Please let me know if I can provide any more information, or test anything. Best wishes, Owen Tuz
[Qemu-devel] [PATCH for-1.2 3/4] ehci: fix Interrupt Threshold Control implementation
First, not all interrupts are subject to Interrupt Threshold Control,
some of them must be delivered without delay.
Second, Interrupt Threshold Control state must be part of vmstate,
otherwise we might loose IRQs on migration.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/hcd-ehci.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 104c21d..e489509 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -575,7 +575,12 @@ static inline void ehci_update_irq(EHCIState *s)
/* flag interrupt condition */
static inline void ehci_raise_irq(EHCIState *s, int intr)
{
-s-usbsts_pending |= intr;
+if (intr (USBSTS_PCD | USBSTS_FLR | USBSTS_HSE)) {
+s-usbsts |= intr;
+ehci_update_irq(s);
+} else {
+s-usbsts_pending |= intr;
+}
}
/*
@@ -2466,13 +2471,16 @@ static int usb_ehci_post_load(void *opaque, int
version_id)
static const VMStateDescription vmstate_ehci = {
.name= ehci,
-.version_id = 1,
+.version_id = 2,
+.minimum_version_id = 1,
.post_load = usb_ehci_post_load,
.fields = (VMStateField[]) {
VMSTATE_PCI_DEVICE(dev, EHCIState),
/* mmio registers */
VMSTATE_UINT32(usbcmd, EHCIState),
VMSTATE_UINT32(usbsts, EHCIState),
+VMSTATE_UINT32_V(usbsts_pending, EHCIState, 2),
+VMSTATE_UINT32_V(usbsts_frindex, EHCIState, 2),
VMSTATE_UINT32(usbintr, EHCIState),
VMSTATE_UINT32(frindex, EHCIState),
VMSTATE_UINT32(ctrldssegment, EHCIState),
--
1.7.1
[Qemu-devel] [PATCH for-1.2 2/4] usb: update uas product id
Pick other product id to fix clash with audio.
Current usage list (after applying this patch):
46f4:0001 -- usb-storage
46f4:0002 -- usb-audio
46f4:0003 -- usb-uas
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/dev-uas.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/usb/dev-uas.c b/hw/usb/dev-uas.c
index 9b02ff4..b13eeba 100644
--- a/hw/usb/dev-uas.c
+++ b/hw/usb/dev-uas.c
@@ -223,7 +223,7 @@ static const USBDescDevice desc_device_high = {
static const USBDesc desc = {
.id = {
.idVendor = 0x46f4, /* CRC16() of QEMU */
-.idProduct = 0x0002,
+.idProduct = 0x0003,
.bcdDevice = 0,
.iManufacturer = STR_MANUFACTURER,
.iProduct = STR_PRODUCT,
--
1.7.1
[Qemu-devel] [PATCH for-1.2] osdep: Fix compilation failure on BSD systems
Fix compilation failure on BSD systems (which don't have
O_DIRECT or O_NOATIME:
osdep.c:116: error: ‘O_DIRECT’ undeclared (first use in this function)
osdep.c:116: error: (Each undeclared identifier is reported only once
osdep.c:116: error: for each function it appears in.)
osdep.c:116: error: ‘O_NOATIME’ undeclared (first use in this function)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
PS: Do we care about O_DSYNC, O_RSYNC, O_SYNC? POSIX says those can be
used via fcntl() too...
osdep.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/osdep.c b/osdep.c
index 5b78cee..3b25297 100644
--- a/osdep.c
+++ b/osdep.c
@@ -113,7 +113,13 @@ static int qemu_dup_flags(int fd, int flags)
}
/* Set/unset flags that we can with fcntl */
-setfl_flags = O_APPEND | O_ASYNC | O_DIRECT | O_NOATIME | O_NONBLOCK;
+setfl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
+#ifdef O_NOATIME
+setfl_flags |= O_NOATIME;
+#endif
+#ifdef O_DIRECT
+setfl_flags |= O_DIRECT;
+#endif
dup_flags = ~setfl_flags;
dup_flags |= (flags setfl_flags);
if (fcntl(ret, F_SETFL, dup_flags) == -1) {
--
1.7.11.4
[Qemu-devel] [PULL for-1.2 0/4] usb bugfix patch queue
Hi, USB patch queue, carrying some bugfixes for qemu 1.2. please pull, Gerd Gerd Hoffmann (3): usb: async control xfer fixup usb: update uas product id ehci: fix Interrupt Threshold Control implementation Hans de Goede (1): ehci: Fix setting of halt bit from usbcmd register updates hw/usb/core.c |1 + hw/usb/dev-uas.c|2 +- hw/usb/hcd-ehci.c | 27 ++- hw/usb/host-linux.c |1 + 4 files changed, 21 insertions(+), 10 deletions(-)
[Qemu-devel] Trouble with pc_system_firmware_init()
I noticed a few things I'd like to discuss. 0. pc_fw_add_pflash_drv() lacks error checking, patch coming. 1. Watch this: $ qemu-system-x86_64 -nodefaults -S -vnc :0 -bios /dev/null Bad ram offset 800 Aborted (core dumped) Backtrace: #0 0x003b0de35925 in raise () from /lib64/libc.so.6 #1 0x003b0de370d8 in abort () from /lib64/libc.so.6 #2 0x0061b606 in qemu_get_ram_ptr (addr=134217728) at /work/armbru/qemu/exec.c:2716 #3 0x0067c71a in memory_region_get_ram_ptr (mr=0x13bb358) at /work/armbru/qemu/memory.c:1136 #4 0x00548b6b in pflash_cfi01_register (base=4294967296, qdev=0x0, name=0x803e3e system.flash, size=0, bs=0x13b9940, sector_len=4096, nb_blocs=0, width=1, id0=0, id1=0, id2=0, id3=0, be=0) at /work/armbru/qemu/hw/pflash_cfi01.c:609 #5 0x00647de3 in pc_system_flash_init (rom_memory=0x13a6400, pflash_drv=0x13aee20) at /work/armbru/qemu/hw/i386/../pc_sysfw.c:134 #6 0x00648112 in pc_system_firmware_init (rom_memory=0x13a6400) at /work/armbru/qemu/hw/i386/../pc_sysfw.c:234 #7 0x00646607 in pc_memory_init (system_memory=0x138d4f0, kernel_filename=0x0, kernel_cmdline=0x7e6fba , initrd_filename=0x0, below_4g_mem_size=134217728, above_4g_mem_size=0, rom_memory=0x13a6400, ram_memory=0x7fffdbe0) at /work/armbru/qemu/hw/i386/../pc.c:985 #8 0x0064714a in pc_init1 (system_memory=0x138d4f0, system_io= 0x138d5c0, ram_size=134217728, boot_device=0x7fffdf00 cad, kernel_filename=0x0, kernel_cmdline=0x7e6fba , initrd_filename=0x0, cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1) at /work/armbru/qemu/hw/i386/../pc_piix.c:177 #9 0x006477ed in pc_init_pci (ram_size=134217728, boot_device= ---Type return to continue, or q return to quit--- 0x7fffdf00 cad, kernel_filename=0x0, kernel_cmdline=0x7e6fba , initrd_filename=0x0, cpu_model=0x0) at /work/armbru/qemu/hw/i386/../pc_piix.c:297 #10 0x005883d4 in main (argc=7, argv=0x7fffe138, envp= 0x7fffe178) at /work/armbru/qemu/vl.c:3571 Same with an empty regular file instead of /dev/null. Shouldn't pflash_cfi01_register() survive funny sizes? Its code to check the size is disabled since commit c8b153d7 Malta flash support.: /* XXX: to be fixed */ #if 0 if (total_len != (8 * 1024 * 1024) total_len != (16 * 1024 * 1024) total_len != (32 * 1024 * 1024) total_len != (64 * 1024 * 1024)) return NULL; #endif And why do we pass the size both as (sector_len, nb_blocs) and size? Since commit cfe5f011 pflash_cfi01/pflash_cfi02: convert to memory API. pc_system_flash_init() rejects sizes that aren't a multiple of 4096 (hardcoded). Why not just zero-pad up to the next muliple? If that's a bad idea: shouldn't size checking be left to pflash_cfi01_register()? 2. If kvm_enabled(), we add a pflash_cfi01 device to hold the BIOS, else we map a ROM the old-fashioned way. Doesn't make that guest ABI depend on the accelerator?
[Qemu-devel] [PATCH for-1.2 1/4] usb: async control xfer fixup
Need to clear p-result after copying setup data using usb_packet_copy()
because we'll reuse the USBPacket for the data transfer.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/core.c |1 +
hw/usb/host-linux.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/usb/core.c b/hw/usb/core.c
index 01a7622..c7e5bc0 100644
--- a/hw/usb/core.c
+++ b/hw/usb/core.c
@@ -107,6 +107,7 @@ static int do_token_setup(USBDevice *s, USBPacket *p)
}
usb_packet_copy(p, s-setup_buf, p-iov.size);
+p-result = 0;
s-setup_len = (s-setup_buf[7] 8) | s-setup_buf[6];
s-setup_index = 0;
diff --git a/hw/usb/host-linux.c b/hw/usb/host-linux.c
index d55be87..8df9207 100644
--- a/hw/usb/host-linux.c
+++ b/hw/usb/host-linux.c
@@ -1045,6 +1045,7 @@ static int usb_host_handle_control(USBDevice *dev,
USBPacket *p,
/* Note request is (bRequestType 8) | bRequest */
trace_usb_host_req_control(s-bus_num, s-addr, p, request, value, index);
+assert(p-result == 0);
switch (request) {
case DeviceOutRequest | USB_REQ_SET_ADDRESS:
--
1.7.1
Re: [Qemu-devel] [PATCH 1/2] extract file_load() function from rom_add_file() for reusing
On 08/16/2012 02:13 PM, Yin Olivia-R63875 wrote: Hi Avi Ben, I've got feedback from qemu-ppc list and revised this patch according to Blue's comments. Could you please give any comments? I don't really have any comments, those files are outside my area of expertise. They look okay to me, but that doesn't mean much as I'm not familiar with ppc. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH for-1.2 4/4] ehci: Fix setting of halt bit from usbcmd register updates
From: Hans de Goede hdego...@redhat.com
This fixes linux guests started without any USB devices not seeing newly
plugged devices until lsusb is done inside the guest.
Signed-off-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb/hcd-ehci.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index e489509..8b94b17 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -1187,22 +1187,23 @@ static void ehci_mem_writel(void *ptr,
target_phys_addr_t addr, uint32_t val)
break;
}
+/* not supporting dynamic frame list size at the moment */
+if ((val USBCMD_FLS) !(s-usbcmd USBCMD_FLS)) {
+fprintf(stderr, attempt to set frame list size -- value %d\n,
+val USBCMD_FLS);
+val = ~USBCMD_FLS;
+}
+
if (((USBCMD_RUNSTOP | USBCMD_PSE | USBCMD_ASE) val) !=
((USBCMD_RUNSTOP | USBCMD_PSE | USBCMD_ASE) s-usbcmd)) {
if (s-pstate == EST_INACTIVE) {
SET_LAST_RUN_CLOCK(s);
}
+s-usbcmd = val; /* Set usbcmd for ehci_update_halt() */
ehci_update_halt(s);
s-async_stepdown = 0;
qemu_mod_timer(s-frame_timer, qemu_get_clock_ns(vm_clock));
}
-
-/* not supporting dynamic frame list size at the moment */
-if ((val USBCMD_FLS) !(s-usbcmd USBCMD_FLS)) {
-fprintf(stderr, attempt to set frame list size -- value %d\n,
-val USBCMD_FLS);
-val = ~USBCMD_FLS;
-}
break;
case USBSTS:
--
1.7.1
Re: [Qemu-devel] [PATCH 1/2] extract file_load() function from rom_add_file() for reusing
On 14 August 2012 08:49, Olivia Yin hong-hua@freescale.com wrote:
Sanity check in rom_add_file() could be reused by other image loaders.
Signed-off-by: Olivia Yin hong-hua@freescale.com
---
This patch is based on branch 'ppc-next' of Alex's upstream QEMU repo:
http://repo.or.cz/r/qemu/agraf.git
hw/loader.c | 61 +++---
1 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/hw/loader.c b/hw/loader.c
index 33acc2f..f2099b6 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -86,6 +86,36 @@ int load_image(const char *filename, uint8_t *addr)
return size;
}
+static int file_load(const char *file, uint8_t **data)
+{
+int fd = -1;
+ssize_t rc, size;
+
+fd = open(file, O_RDONLY | O_BINARY);
+if (fd == -1) {
+fprintf(stderr, Could not open file '%s': %s\n,
+file, strerror(errno));
+return -1;
+}
+
+size = lseek(fd, 0, SEEK_END);
+*data = g_malloc0(size);
+lseek(fd, 0, SEEK_SET);
+rc = read(fd, *data, size);
+if (rc != size) {
+fprintf(stderr, file %-20s: read error: rc=%zd (expected %zd)\n,
+file, rc, size);
+goto err;
+}
+close(fd);
+return size;
+err:
+if (fd != -1)
+close(fd);
+g_free(*data);
+return -1;
+}
Isn't this function effectively a reimplementation of the glib
g_file_get_contents() function? It would probably be better to
just make the callers use that instead.
-- PMM
Re: [Qemu-devel] Windows slow boot: contractor wanted
On 08/16/2012 01:47 PM, Richard Davies wrote: Hi, We run a cloud hosting provider using qemu-kvm 1.1, and are keen to find a contractor to track down and fix problems we have with large memory Windows guests booting very slowly - they can take several hours. We previously reported these problems in July (copied below) and they are still present with Linux kernel 3.5.1 and qemu-kvm 1.1.1. This is a serious issue for us which is causing significant pain to our larger Windows VM customers when their servers are offline for many hours during boot. If anyone knowledgeable in the area would be interested in being paid to work on this, or if you know someone who might be, I would be delighted to hear from you. I happen to be gainfully employed but maybe I can help. Can you collect a trace during the slow boot period and post in somewhere? See http://www.linux-kvm.org/page/Tracing for instructions. 4G/8way is not a particularly large guest. What is the host configuration (memory, core count)? -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 0/2] Fix two buggy pc_sysfw error paths
Markus Armbruster (2): pc_sysfw: Check for qemu_find_file() failure pc_sysfw: Plug memory leak on pc_fw_add_pflash_drv() error path hw/pc_sysfw.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- 1.7.11.2
[Qemu-devel] [PATCH 1/2] pc_sysfw: Check for qemu_find_file() failure
pc_fw_add_pflash_drv() ignores qemu_find_file() failure, and happily
creates a drive without a medium.
When pc_system_flash_init() asks for its size, bdrv_getlength() fails
with -ENOMEDIUM, which isn't checked either. It fails relatively
cleanly only because -ENOMEDIUM isn't a multiple of 4096:
$ qemu-system-x86_64 -S -vnc :0 -bios nonexistant
qemu: PC system firmware (pflash) must be a multiple of 0x1000
[Exit 1 ]
Fix by handling the qemu_find_file() failure.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/pc_sysfw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/pc_sysfw.c b/hw/pc_sysfw.c
index b45f0ac..fd22154 100644
--- a/hw/pc_sysfw.c
+++ b/hw/pc_sysfw.c
@@ -84,6 +84,11 @@ static void pc_fw_add_pflash_drv(void)
bios_name = BIOS_FILENAME;
}
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (!filename) {
+error_report(Can't open BIOS image %s: %s,
+ bios_name, strerror(errno));
+exit(1);
+}
opts = drive_add(IF_PFLASH, -1, filename, readonly=on);
--
1.7.11.2
Re: [Qemu-devel] Slow inbound traffic on macvtap interfaces
On Thu, Aug 16, 2012 at 10:20:05AM +0100, Chris Webb wrote: I'm experiencing a problem with qemu + macvtap which I can reproduce on a variety of hardware, with kernels varying from 3.0.4 (the oldest I tried) to 3.5.1 and with qemu[-kvm] versions 0.14.1, 1.0, and 1.1. Large data transfers over TCP into a guest from another machine on the network are very slow (often less than 100kB/s) whereas transfers outbound from the guest, between two guests on the same host, or between the guest and its host run at normal speeds (= 50MB/s). The slow inbound data transfer speeds up substantially when a ping flood is aimed either at the host or the guest, or when the qemu process is straced. Presumably both of these are ways to wake up something that is otherwise sleeping too long? For example, I can run ip addr add 192.168.1.2/24 dev eth0 ip link set eth0 up ip link add link eth0 name tap0 address 02:02:02:02:02:02 type macvtap mode bridge ip link set tap0 up qemu-kvm -hda debian.img -cpu host -m 512 -vnc :0 \ -net nic,model=virtio,macaddr=02:02:02:02:02:02 \ -net tap,fd=3 3/dev/tap$( /sys/class/net/tap0/ifindex) on one physical host which is otherwise completely idle. From a second physical host on the same network, I then scp a large (say 50MB) file onto the new guest. On a gigabit LAN, speeds consistently drop to less than 100kB/s as the transfer progresses, within a second of starting. The choice of virtio virtual nic in the above isn't significant: the same thing happens with e1000 or rtl8139. You can also replace the scp with a straight netcat and see the same effect. Doing the transfer in the other direction (i.e. copying a large file from the guest to an external host) achieves 50MB/s or faster as expected. Copying between two guests on the same host (i.e. taking advantage of the 'mode bridge') is also fast. If I create a macvlan device attached to eth0 and move the host IP address to that, I can communicate between the host itself and the guest because of the 'mode bridge'. Again, this case is fast in both directions. Using a bridge and a standard tap interface, transfers in and out are fast too: ip tuntap add tap0 mode tap brctl addbr br0 brctl addif br0 eth0 brctl addif br0 tap1 ip link set eth0 up ip link set tap0 up ip link set br0 up ip addr add 192.168.1.2/24 dev br0 qemu-kvm -hda debian.img -cpu host -m 512 -vnc :0 \ -net nic,model=virtio,macaddr=02:02:02:02:02:02 \ -net tap,script=no,downscript=no,ifname=tap0 As mentioned in the summary at the beginning of this report, when I strace a guest in the original configuration which is receiving data slowly, the data rate improves from less than 100kB/s to around 3.1MB/s. Similarly, if I ping flood either the guest or the host it is running on from another machine on the network, the transfer rate improves to around 1.1MB/s. This seems quite suggestive of a problem with delayed wake-up of the guest. Two reasonably up-to-date examples of machines I've reproduced this on are my laptop with an r8169 gigabit ethernet card, Debian qemu-kvm 1.0 and upstream 3.4.8 kernel whose .config and boot dmesg are at http://cdw.me.uk/tmp/laptop-config.txt http://cdw.me.uk/tmp/laptop-dmesg.txt and one of our large servers with an igb gigabit ethernet card, upstream qemu-kvm 1.1.1 and upstream 3.5.1 linux: http://cdw.me.uk/tmp/server-config.txt http://cdw.me.uk/tmp/server-dmesg.txt For completeness, I've put the Debian 6 test image I've been using for testing at http://cdw.me.uk/tmp/test-debian.img.xz though I've see the same problem from a variety of guest operating systems. (In fact, I've not yet found any combination of host kernel, guest OS and hardware which doesn't show these symptoms, so it seems to be very easy to reproduce.) Cheers, Chris. Thanks for the report. I'll try to reproduce this early next week. Meanwhile a question - do you still observe this behaviour if you enable vhost-net? Thanks, -- MST
[Qemu-devel] [PATCH 2/2] pc_sysfw: Plug memory leak on pc_fw_add_pflash_drv() error path
Harmless, because we the error inevitably leads to another, fatal one
in pc_system_flash_init(): PC system firmware (pflash) not available.
Fix it anyway.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/pc_sysfw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/pc_sysfw.c b/hw/pc_sysfw.c
index fd22154..ebb6b25 100644
--- a/hw/pc_sysfw.c
+++ b/hw/pc_sysfw.c
@@ -103,7 +103,9 @@ static void pc_fw_add_pflash_drv(void)
return;
}
-drive_init(opts, machine-use_scsi);
+if (!drive_init(opts, machine-use_scsi)) {
+qemu_opts_del(opts);
+}
}
static void pc_system_flash_init(MemoryRegion *rom_memory,
--
1.7.11.2
Re: [Qemu-devel] [PATCH 17/23] mips_malta mips_r4k: Suppress unused default drives
Am 09.08.2012 15:31, schrieb Markus Armbruster:
Cc: Aurelien Jarno aurel...@aurel32.net
Suppress default SD card drive for machines malta, mips.
Suppress default floppy drive for machine mips.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/mips_malta.c | 1 +
hw/mips_r4k.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index 351c88e..c1c52ac 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -1019,6 +1019,7 @@ static QEMUMachine mips_malta_machine = {
.desc = MIPS Malta Core LV,
.init = mips_malta_init,
.max_cpus = 16,
+.no_sdcard = 1,
.is_default = 1,
};
diff --git a/hw/mips_r4k.c b/hw/mips_r4k.c
index 967a76e..d9f6dc5 100644
--- a/hw/mips_r4k.c
+++ b/hw/mips_r4k.c
@@ -299,6 +299,8 @@ static QEMUMachine mips_machine = {
.name = mips,
.desc = mips r4k platform,
.init = mips_r4k_init,
+.no_floppy = 1,
+.no_sdcard = 1,
};
static void mips_machine_init(void)
Reviewed-by: Stefan Weil s...@weilnetz.de
I'd prefer using 'true' instead of '1' (and changing the
variables to type bool), but that can be done later.
Regards,
Stefan W.
Re: [Qemu-devel] [PATCH 0/7] qapi: add commands to remove the need (v2)
Am 15.08.2012 18:53, schrieb Luiz Capitulino: On Wed, 15 Aug 2012 08:07:57 +0200 Stefan Weil s...@weilnetz.de wrote: Am 13.08.2012 19:16, schrieb Luiz Capitulino: On Fri, 10 Aug 2012 11:04:08 -0500 Anthony Liguori aligu...@us.ibm.com wrote: This series implements the necessary commands to implements danpb's idea to remove -help parsing in libvirt. We would introduce all of these commands in 1.2 and then change the -help output starting in 1.3. Applied to the qmp branch, thanks. The series breaks cross compilation of QEMU for w32 on Debian Linux: LINK arm-softmmu/qemu-system-armw.exe ../qmp-marshal.o: In function `qmp_marshal_input_query_cpu_definitions': /home/stefan/w32/qmp-marshal.c:2585: undefined reference to `_qmp_query_cpu_definitions' Does this patch fix it? http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg02676.html Yes, Anthony's patch fixes that. I just noticed that he already applied it to git master. The solution which I had suggested below would have been much simpler. Using GCC_WEAK in the declaration worked for me with gcc from Debian Lenny, too. Which gcc requires different handling for w32 and non-w32? Weak symbols obviously use a different name mangling, therefore qmp_query_cpu_definitions is not found by the linker. Adding GCC_WEAK to the declaration of qmp_query_cpu_definitions in generated file qmp-commands.h fixes that. Regards, Stefan Weil
Re: [Qemu-devel] [PATCH v2 for-1.2 00/27] Suppress unused default drives
On 15 August 2012 20:36, Peter Maydell peter.mayd...@linaro.org wrote:
I also think we should follow up Paul Brook's suggestion
that we don't need to have any kind of default sd card flag
at all. Floppy is weird because we don't properly separate out
the drive and the controller, right? Not sure about cdrom...
So I looked at the IF_SD users, which fall into two categories:
(1) ssi-sd.c, pl181.c, milkymist-memcard.c
These are all SD controller models, which in init do something
along the lines of
dinfo = drive_get_next(IF_SD);
s-card = sd_init(dinfo ? dinfo-bdrv : NULL, 0);
so they correctly handle there being no drive provided by
the user (sd_init() treats NULL bdrv as like no card present).
(2) omap1.c, omap2.c, pxa2xx.c
These are board models, which do:
dinfo = drive_get(IF_SD, 0, 0);
if (!dinfo) {
fprintf(stderr, qemu: missing SecureDigital device\n);
exit(1);
}
s-mmc = pxa2xx_mmci_init(address_space, 0x4110, dinfo-bdrv,
qdev_get_gpio_in(s-pic, PXA2XX_PIC_MMC),
qdev_get_gpio_in(s-dma, PXA2XX_RX_RQ_MMCI),
qdev_get_gpio_in(s-dma, PXA2XX_TX_RQ_MMCI));
ie they do the drive_get themselves and pass the bdrv to the
MMC/SD controller model, which assumes it's not NULL.
So we should convert the case (2) systems to behave like (1)
and then we can drop the creation of a default sd card.
-- PMM
Re: [Qemu-devel] [PATCH for-1.2] osdep: Fix compilation failure on BSD systems
Am 16.08.2012 13:15, schrieb Peter Maydell:
Fix compilation failure on BSD systems (which don't have
O_DIRECT or O_NOATIME:
osdep.c:116: error: ‘O_DIRECT’ undeclared (first use in this function)
osdep.c:116: error: (Each undeclared identifier is reported only once
osdep.c:116: error: for each function it appears in.)
osdep.c:116: error: ‘O_NOATIME’ undeclared (first use in this function)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
PS: Do we care about O_DSYNC, O_RSYNC, O_SYNC? POSIX says those can be
used via fcntl() too...
osdep.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/osdep.c b/osdep.c
index 5b78cee..3b25297 100644
--- a/osdep.c
+++ b/osdep.c
@@ -113,7 +113,13 @@ static int qemu_dup_flags(int fd, int flags)
}
/* Set/unset flags that we can with fcntl */
-setfl_flags = O_APPEND | O_ASYNC | O_DIRECT | O_NOATIME | O_NONBLOCK;
+setfl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
+#ifdef O_NOATIME
+setfl_flags |= O_NOATIME;
+#endif
+#ifdef O_DIRECT
+setfl_flags |= O_DIRECT;
+#endif
dup_flags = ~setfl_flags;
dup_flags |= (flags setfl_flags);
if (fcntl(ret, F_SETFL, dup_flags) == -1) {
Would O_DSYNC be a good replacement here for an
undefined O_DIRECT? block/raw-posix.c does it like that.
What about defining O_NOATIME and O_DIRECT in qemu-common.h
when needed (like it is done for O_BINARY)?
But I don't want to delay 1.2, therefore
Reviewed-by: Stefan Weil s...@weilnetz.de
Regards,
Stefan W.
Re: [Qemu-devel] [PATCH] Fix spelling (licenced - licensed) in GPL
Ping? Am 10.08.2012 22:03, schrieb Stefan Weil: The patch also fixes the case of written. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/imx_avic.c |4 ++-- hw/imx_timer.c |4 ++-- hw/kzm.c |2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/hw/imx_avic.c b/hw/imx_avic.c index 4f010e8..b1a8fe6 100644 --- a/hw/imx_avic.c +++ b/hw/imx_avic.c @@ -6,9 +6,9 @@ * * Copyright (c) 2008 OKL * Copyright (c) 2011 NICTA Pty Ltd - * Originally Written by Hans Jiang + * Originally written by Hans Jiang * - * This code is licenced under the GPL version 2 or later. See + * This code is licensed under the GPL version 2 or later. See * the COPYING file in the top-level directory. * * TODO: implement vectors. diff --git a/hw/imx_timer.c b/hw/imx_timer.c index 16215cc..c28c537 100644 --- a/hw/imx_timer.c +++ b/hw/imx_timer.c @@ -3,10 +3,10 @@ * * Copyright (c) 2008 OK Labs * Copyright (c) 2011 NICTA Pty Ltd - * Originally Written by Hans Jiang + * Originally written by Hans Jiang * Updated by Peter Chubb * - * This code is licenced under GPL version 2 or later. See + * This code is licensed under GPL version 2 or later. See * the COPYING file in the top-level directory. * */ diff --git a/hw/kzm.c b/hw/kzm.c index 6a5e9df..68cd1b4 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -5,7 +5,7 @@ * Written by Hans at OK-Labs * Updated by Peter Chubb. * - * This code is licenced under the GPL, version 2 or later. + * This code is licensed under the GPL, version 2 or later. * See the file `COPYING' in the top level directory. * * It (partially) emulates a Kyoto Microcomputer
Re: [Qemu-devel] [PATCH] Spelling fixes in comments and documentation
Ping?
Am 10.08.2012 22:03, schrieb Stefan Weil:
These wrong spellings were detected by codespell:
* successully - successfully
* alot - a lot
* wanna - want to
* infomation - information
* occured - occurred
Signed-off-by: Stefan Weil s...@weilnetz.de
---
docs/specs/ppc-spapr-hcalls.txt |2 +-
docs/usb2.txt |4 ++--
hw/xen_pt.h |4 ++--
hw/xen_pt_config_init.c | 14 +++---
qemu-img.c |2 +-
qemu-img.texi |2 +-
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/docs/specs/ppc-spapr-hcalls.txt b/docs/specs/ppc-spapr-hcalls.txt
index 52ba8d4..667b3fa 100644
--- a/docs/specs/ppc-spapr-hcalls.txt
+++ b/docs/specs/ppc-spapr-hcalls.txt
@@ -31,7 +31,7 @@ Arguments:
Returns:
- H_SUCCESS : Successully called the RTAS function (RTAS result
+ H_SUCCESS : Successfully called the RTAS function (RTAS result
will have been stored in the parameter block)
H_PARAMETER : Unknown token
diff --git a/docs/usb2.txt b/docs/usb2.txt
index d17e3c0..21f6d14 100644
--- a/docs/usb2.txt
+++ b/docs/usb2.txt
@@ -58,11 +58,11 @@ try ...
xhci controller support
---
-There also is xhci host controller support available. It got alot
+There also is xhci host controller support available. It got a lot
less testing than ehci and there are a bunch of known limitations, so
ehci may work better for you. On the other hand the xhci hardware
design is much more virtualization-friendly, thus xhci emulation uses
-less ressources (especially cpu). If you wanna give xhci a try
+less ressources (especially cpu). If you want to give xhci a try
use this to add the host controller ...
qemu -device nec-usb-xhci,id=xhci
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 41904ec..112477a 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -96,7 +96,7 @@ typedef struct XenPTRegion {
* - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
*/
-/* emulated register infomation */
+/* emulated register information */
struct XenPTRegInfo {
uint32_t offset;
uint32_t size;
@@ -140,7 +140,7 @@ typedef int (*xen_pt_reg_size_init_fn)
(XenPCIPassthroughState *, const XenPTRegGroupInfo *,
uint32_t base_offset, uint8_t *size);
-/* emulated register group infomation */
+/* emulated register group information */
struct XenPTRegGroupInfo {
uint8_t grp_id;
XenPTRegisterGroupType grp_type;
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 00eb3d9..e524a40 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -562,7 +562,7 @@ static int
xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* Header Type0 reg static infomation table */
+/* Header Type0 reg static information table */
static XenPTRegInfo xen_pt_emu_reg_header0[] = {
/* Vendor ID reg */
{
@@ -753,7 +753,7 @@ static XenPTRegInfo xen_pt_emu_reg_header0[] = {
* Vital Product Data Capability
*/
-/* Vital Product Data Capability Structure reg static infomation table */
+/* Vital Product Data Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
{
.offset = PCI_CAP_LIST_NEXT,
@@ -775,7 +775,7 @@ static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
* Vendor Specific Capability
*/
-/* Vendor Specific Capability Structure reg static infomation table */
+/* Vendor Specific Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
{
.offset = PCI_CAP_LIST_NEXT,
@@ -866,7 +866,7 @@ static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState
*s,
return 0;
}
-/* PCI Express Capability Structure reg static infomation table */
+/* PCI Express Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
/* Next Pointer reg */
{
@@ -981,7 +981,7 @@ static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* Power Management Capability reg static infomation table */
+/* Power Management Capability reg static information table */
static XenPTRegInfo xen_pt_emu_reg_pm[] = {
/* Next Pointer reg */
{
@@ -1259,7 +1259,7 @@ static int
xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* MSI Capability Structure reg static infomation table */
+/* MSI Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_msi[] = {
/* Next Pointer reg */
{
@@ -1396,7 +1396,7 @@ static int
xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* MSI-X Capability Structure reg static infomation table */
+/* MSI-X Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_msix[] = {
/* Next Pointer reg */
Re: [Qemu-devel] [PATCH for-1.2] osdep: Fix compilation failure on BSD systems
On 16 August 2012 13:27, Stefan Weil s...@weilnetz.de wrote:
Am 16.08.2012 13:15, schrieb Peter Maydell:
Fix compilation failure on BSD systems (which don't have
O_DIRECT or O_NOATIME:
osdep.c:116: error: ‘O_DIRECT’ undeclared (first use in this function)
osdep.c:116: error: (Each undeclared identifier is reported only once
osdep.c:116: error: for each function it appears in.)
osdep.c:116: error: ‘O_NOATIME’ undeclared (first use in this function)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
PS: Do we care about O_DSYNC, O_RSYNC, O_SYNC? POSIX says those can be
used via fcntl() too...
osdep.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/osdep.c b/osdep.c
index 5b78cee..3b25297 100644
--- a/osdep.c
+++ b/osdep.c
@@ -113,7 +113,13 @@ static int qemu_dup_flags(int fd, int flags)
}
/* Set/unset flags that we can with fcntl */
-setfl_flags = O_APPEND | O_ASYNC | O_DIRECT | O_NOATIME | O_NONBLOCK;
+setfl_flags = O_APPEND | O_ASYNC | O_NONBLOCK;
+#ifdef O_NOATIME
+setfl_flags |= O_NOATIME;
+#endif
+#ifdef O_DIRECT
+setfl_flags |= O_DIRECT;
+#endif
dup_flags = ~setfl_flags;
dup_flags |= (flags setfl_flags);
if (fcntl(ret, F_SETFL, dup_flags) == -1) {
Would O_DSYNC be a good replacement here for an
undefined O_DIRECT? block/raw-posix.c does it like that.
I think it would be better to have this function handle
O_DSYNC as a flag to go in setfl_flags independently of
whether O_DIRECT is defined or not; at this level I don't
think it makes sense to try to #define O_DIRECT O_DSYNC
(we are interpreting flags given us by a caller, not picking
flags to try to get the behaviour we want from a function
we're going to call).
What about defining O_NOATIME and O_DIRECT in qemu-common.h
when needed (like it is done for O_BINARY)?
Again, I think that would be a fix at the wrong level: it
might be OK if we wanted to allow people to call this function
with those flags even if the host OS didn't know about them,
but it's not what you need to make the function itself
perform correctly. What we might want is to add
#ifdef O_DSYNC
setfl_flags |= O_DSYNC;
#endif
etc, but I'm not sure about that.
But I don't want to delay 1.2, therefore
Reviewed-by: Stefan Weil s...@weilnetz.de
Thanks; this is indeed really just a minimal make it compile
fix.
-- PMM
Re: [Qemu-devel] [PATCH] Spelling fixes in comments and documentation
On 10 August 2012 21:03, Stefan Weil s...@weilnetz.de wrote: diff --git a/docs/usb2.txt b/docs/usb2.txt index d17e3c0..21f6d14 100644 --- a/docs/usb2.txt +++ b/docs/usb2.txt @@ -58,11 +58,11 @@ try ... xhci controller support --- -There also is xhci host controller support available. It got alot +There also is xhci host controller support available. It got a lot is also less testing than ehci and there are a bunch of known limitations, so ehci may work better for you. On the other hand the xhci hardware design is much more virtualization-friendly, thus xhci emulation uses -less ressources (especially cpu). If you wanna give xhci a try +less ressources (especially cpu). If you want to give xhci a try resources -- PMM
Re: [Qemu-devel] [PATCH] Documentation: Warn against qemu-img on active image
On 08/16/2012 04:00 AM, Peter Maydell wrote:
On 16 August 2012 10:00, Kevin Wolf kw...@redhat.com wrote:
People have repeatedly expected that you can do things like snapshotting
an image with qemu-img while a qemu instance is running. Maybe we need
to consider locking the files while they are in use,
Sounds like a nice feature bit to add to qcow2v3, where both qemu-img
and qemu check if the locking feature is enabled for an image, as well
as maintain a header bit that is set when the image is open read-write
and refuse to use the image if the lock bit is set.
but having a
warning in the qemu-img manpage is doable for 1.2 and can't hurt anyway.
Signed-off-by: Kevin Wolf kw...@redhat.com
+
+@b{Warning:} Never use qemu-img to modify images in use by a running virtual
+machine or any other process, this may destroy the image.
; or , because.
Is this strong enough? Remember, with qcow2v3 and qed, the mere act of
opening an image will perform refcount checks that modify the image,
unless you explicitly request otherwise, which means even a query of the
file metadata may result in modifying the image as part of the default
open. Maybe incorporate some ideas from this attempt:
Never use qemu-img to modify files in use by a running virtual machine
or any other process; this may destroy the image. Be aware that some
image formats perform modifications even on query operations. Also, be
aware that querying an image that is being modified by another process
may encounter inconsistent state.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC 0/7] Migration stats
Hi, Juan I have a brief test with these patches applied and it's very useful. It's more precise and time-saving than calculate it with some other method for the downtime,etc. Thank you, Qunfang On 08/13/2012 06:50 PM, Juan Quintela wrote: Hi This modifies the output of info migrate/qmp_query_migrate to add the stats that I got request for. - It moves total time to MigrationInfo instead of ram (luiz suggestion) - Prints the real downtime that we have had really, it prints the total downtime of the complete phase, but the downtime also includes the last ram_iterate phase. Working on fixing that one. - Prints the expected downtime of the last time that we synchronized the dirty bitmap with kvm. So we have one idea of what downtime value we need for migration to converge. - Prints the dirty_pages_rate, that is the number of pages that we have written in the last second. This one prints always zero. To fill it, I need the dirty bitmap changes on the migration_thread series. Patch series apply on top of the migration-next-20120808 series sent to anthony. What do I want to know: - is there any stat that you want? Once here, adding a new one should be easy. - examples are not done, waiting until people agree with what params are needed. - luiz added in case he has QMP commets. - erik added for libvirt comments. Added before is the link to the branch on my repository. The following changes since commit 346fe0c4c0b88f11a3d0c01c34d9a170d73429cc: Merge remote-tracking branch 'stefanha/trivial-patches' into staging (2012-08-11 19:49:03 -0500) are available in the git repository at: http://repo.or.cz/r/qemu/quintela.git migration-stats for you to fetch changes up to e0599012abfc4f9a68185c6f0a10a7b98c0a180f: migration: Add dirty_pages_rate to query migrate output (2012-08-13 12:33:35 +0200) Please review, and comment. Juan Quintela (7): migration: move total_time from ram stats to migration info migration: store end_time in a local variable migration: print total downtime for final phase of migration migration: rename expected_time to expected_downtime migration: export migration_get_current() migration: print expected downtime in info migrate migration: Add dirty_pages_rate to query migrate output arch_init.c | 19 +++ hmp.c| 16 ++-- migration.c | 19 ++- migration.h | 4 qapi-schema.json | 26 +++--- 5 files changed, 62 insertions(+), 22 deletions(-)
Re: [Qemu-devel] [PATCH 1/2] extract file_load() function from rom_add_file() for reusing
Hi Avi Ben,
I've got feedback from qemu-ppc list and revised this patch according to Blue's
comments.
Could you please give any comments?
Best Regards,
Olivia
-Original Message-
From: Yin Olivia-R63875
Sent: Tuesday, August 14, 2012 3:50 PM
To: qemu-...@nongnu.org; qemu-devel@nongnu.org
Cc: Yin Olivia-R63875
Subject: [PATCH 1/2] extract file_load() function from rom_add_file() for
reusing
Sanity check in rom_add_file() could be reused by other image loaders.
Signed-off-by: Olivia Yin hong-hua@freescale.com
---
This patch is based on branch 'ppc-next' of Alex's upstream QEMU repo:
http://repo.or.cz/r/qemu/agraf.git
hw/loader.c | 61 +++--
-
1 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/hw/loader.c b/hw/loader.c
index 33acc2f..f2099b6 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -86,6 +86,36 @@ int load_image(const char *filename, uint8_t *addr)
return size;
}
+static int file_load(const char *file, uint8_t **data) {
+int fd = -1;
+ssize_t rc, size;
+
+fd = open(file, O_RDONLY | O_BINARY);
+if (fd == -1) {
+fprintf(stderr, Could not open file '%s': %s\n,
+file, strerror(errno));
+return -1;
+}
+
+size = lseek(fd, 0, SEEK_END);
+*data = g_malloc0(size);
+lseek(fd, 0, SEEK_SET);
+rc = read(fd, *data, size);
+if (rc != size) {
+fprintf(stderr, file %-20s: read error: rc=%zd
(expected %zd)\n,
+file, rc, size);
+goto err;
+}
+close(fd);
+return size;
+err:
+if (fd != -1)
+close(fd);
+g_free(*data);
+return -1;
+}
+
/* read()-like version */
ssize_t read_targphys(const char *name,
int fd, target_phys_addr_t dst_addr, size_t nbytes)
@@ -568,38 +598,22 @@ int rom_add_file(const char *file, const char
*fw_dir,
target_phys_addr_t addr, int32_t bootindex) {
Rom *rom;
-int rc, fd = -1;
char devpath[100];
rom = g_malloc0(sizeof(*rom));
rom-name = g_strdup(file);
+rom-addr = addr;
rom-path = qemu_find_file(QEMU_FILE_TYPE_BIOS, rom-name);
if (rom-path == NULL) {
rom-path = g_strdup(file);
}
-fd = open(rom-path, O_RDONLY | O_BINARY);
-if (fd == -1) {
-fprintf(stderr, Could not open option rom '%s': %s\n,
-rom-path, strerror(errno));
-goto err;
-}
-
if (fw_dir) {
rom-fw_dir = g_strdup(fw_dir);
rom-fw_file = g_strdup(file);
}
-rom-addr= addr;
-rom-romsize = lseek(fd, 0, SEEK_END);
-rom-data= g_malloc0(rom-romsize);
-lseek(fd, 0, SEEK_SET);
-rc = read(fd, rom-data, rom-romsize);
-if (rc != rom-romsize) {
-fprintf(stderr, rom: file %-20s: read error: rc=%d
(expected %zd)\n,
-rom-name, rc, rom-romsize);
-goto err;
-}
-close(fd);
+
+rom-romsize = file_load(rom-path, rom-data);
rom_insert(rom);
if (rom-fw_file fw_cfg) {
const char *basename;
@@ -621,15 +635,6 @@ int rom_add_file(const char *file, const char
*fw_dir,
add_boot_device_path(bootindex, NULL, devpath);
return 0;
-
-err:
-if (fd != -1)
-close(fd);
-g_free(rom-data);
-g_free(rom-path);
-g_free(rom-name);
-g_free(rom);
-return -1;
}
int rom_add_blob(const char *name, const void *blob, size_t len,
--
1.7.1
Re: [Qemu-devel] [PATCH 1/4] spice: notify spice server on vm start/stop
On 08/16/2012 12:42 PM, Gerd Hoffmann wrote: On 08/16/12 10:23, Yonit Halperin wrote: Spice server needs to know about the vm state in order to prevent attempts to write to devices when they are stopped, mainly during the non-live stage of migration. Why this new hook? qemu already notifies spice-server using QXLWorker start/stop callbacks. It notifies the QXLWorker, and it goes to the display_channel. Spice api changes anyway, by adding spice_server_set_seamless_migration, and as other channels need this notification as well, it would be nicer to explicitly notify the server about the vm start/stop and not abuse the QXLWorker notification. Another option would have been to add notifier for SpiceCharDeviceInterface as well, and then to any other new interface that will require it. Regards, Yonit. cheers, Gerd
Re: [Qemu-devel] [Qemu-trivial] [PATCH] Spelling fixes in comments and documentation
On Fri, Aug 10, 2012 at 10:03:25PM +0200, Stefan Weil wrote: These wrong spellings were detected by codespell: * successully - successfully * alot - a lot * wanna - want to * infomation - information * occured - occurred Signed-off-by: Stefan Weil s...@weilnetz.de --- docs/specs/ppc-spapr-hcalls.txt |2 +- docs/usb2.txt |4 ++-- hw/xen_pt.h |4 ++-- hw/xen_pt_config_init.c | 14 +++--- qemu-img.c |2 +- qemu-img.texi |2 +- 6 files changed, 14 insertions(+), 14 deletions(-) Added Peter's suggestions. Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] Fix spelling (licenced - licensed) in GPL
On Fri, Aug 10, 2012 at 10:03:26PM +0200, Stefan Weil wrote: The patch also fixes the case of written. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/imx_avic.c |4 ++-- hw/imx_timer.c |4 ++-- hw/kzm.c |2 +- 3 files changed, 5 insertions(+), 5 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH for-1.2] osdep: Fix compilation failure on BSD systems
On 08/16/2012 07:15 AM, Peter Maydell wrote: Fix compilation failure on BSD systems (which don't have O_DIRECT or O_NOATIME: osdep.c:116: error: ‘O_DIRECT’ undeclared (first use in this function) osdep.c:116: error: (Each undeclared identifier is reported only once osdep.c:116: error: for each function it appears in.) osdep.c:116: error: ‘O_NOATIME’ undeclared (first use in this function) Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- PS: Do we care about O_DSYNC, O_RSYNC, O_SYNC? POSIX says those can be used via fcntl() too... Thanks very much Peter. The patch looks good to me. Could you point me to the reference you saw the fcntl description in? I didn't notice any flags mentioned here: http://pubs.opengroup.org/onlinepubs/009695399/functions/fcntl.html The choice of flags was based on the Linux man page for fcntl() which says F_SETFL can change only the O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, and O_NONBLOCK flags. -- Regards, Corey
[Qemu-devel] [PATCH] Spelling fixes in comments and macro names (ressource - resource)
Macro XEN_HOST_PCI_RESOURCE_BUFFER_SIZE is only used locally,
so the change should be safe.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
hw/xen-host-pci-device.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
index e7ff680..743b37b 100644
--- a/hw/xen-host-pci-device.c
+++ b/hw/xen-host-pci-device.c
@@ -47,13 +47,13 @@ static int xen_host_pci_sysfs_path(const XenHostPCIDevice
*d,
}
-/* This size should be enough to read the first 7 lines of a ressource file */
-#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
+/* This size should be enough to read the first 7 lines of a resource file */
+#define XEN_HOST_PCI_RESOURCE_BUFFER_SIZE 400
static int xen_host_pci_get_resource(XenHostPCIDevice *d)
{
int i, rc, fd;
char path[PATH_MAX];
-char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+char buf[XEN_HOST_PCI_RESOURCE_BUFFER_SIZE];
unsigned long long start, end, flags, size;
char *endptr, *s;
uint8_t type;
--
1.7.10
Re: [Qemu-devel] [RFC V3 4/9] quorum: Add quorum_getlength().
Le Tuesday 14 Aug 2012 à 10:08:24 (-0600), Eric Blake a écrit :
On 08/14/2012 08:14 AM, Benoît Canet wrote:
Signed-off-by: Benoit Canet ben...@irqsave.net
---
block/quorum.c |9 +
1 file changed, 9 insertions(+)
diff --git a/block/quorum.c b/block/quorum.c
index f228428..a3f16ed 100644
--- a/block/quorum.c
+++ b/block/quorum.c
@@ -162,12 +162,21 @@ static void quorum_close(BlockDriverState *bs)
g_free(s-bs);
}
+static int64_t quorum_getlength(BlockDriverState *bs)
+{
+BDRVQuorumState *s = bs-opaque;
+
+return bdrv_getlength(s-bs[0]);
Is this implementation right? Shouldn't this be a quorum decision,
where all s-bs[...] elements have to agree on the same size, or even
where they can differ on size, as long as all files with larger size
have unallocated holes past the size of the smaller member?
You are right.
I have trouble figuring how it would work with differents sizes.
Requiring quorum decision on the same size seems the best solutions
I will implement it.
Benoît
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
[Qemu-devel] [PATCH v2] configure: properly check if -lrt and -lm is needed
Fixes build against uClibc.
uClibc provides 2 versions of clock_gettime(), one with realtime
support and one without (this is so you can avoid linking in -lrt
unless actually needed). This means that the clock_gettime() don't
need -lrt. We still need it for timer_create() so we check for this
function in addition.
We also need check if -lm is needed for isnan().
Both -lm and -lrt are needed for libs_qga.
Signed-off-by: Natanael Copa nc...@alpinelinux.org
---
The Xen people have nagged me to get this patch upstream so I have come
up with a rebased v2 patch after consulting with pm215 on IRC.
Please consider include this.
Changes v1-v2:
- Check for sin() in addition to isnan()
- Add comment on why we also check for timer_create
- Use $LIBS and $libs_qga instead of $libm and $librt, based on
feedback from pm215 on IRC
- Do not remove the explicit add of -lm unless Haiku. This was due
to http://www.mail-archive.com/qemu-devel@nongnu.org/msg102965.html
I am not sure if this is valid, though.
configure | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index edf9da4..a351f9b 100755
--- a/configure
+++ b/configure
@@ -2624,17 +2624,48 @@ fi
##
+# Do we need libm
+cat $TMPC EOF
+#include math.h
+int main(void) { return isnan(sin(0.0)); }
+EOF
+if compile_prog ; then
+ :
+elif compile_prog -lm ; then
+ LIBS=-lm $LIBS
+ libs_qga=-lm $libs_qga
+else
+ echo
+ echo Error: libm check failed
+ echo
+ exit 1
+fi
+
+##
# Do we need librt
+# uClibc provides 2 versions of clock_gettime(), one with realtime
+# support and one without. This means that the clock_gettime() don't
+# need -lrt. We still need it for timer_create() so we check for this
+# function in addition.
cat $TMPC EOF
#include signal.h
#include time.h
-int main(void) { return clock_gettime(CLOCK_REALTIME, NULL); }
+int main(void) {
+ timer_create(CLOCK_REALTIME, NULL, NULL);
+ return clock_gettime(CLOCK_REALTIME, NULL);
+}
EOF
if compile_prog ; then
:
elif compile_prog -lrt ; then
LIBS=-lrt $LIBS
+ libs_qga=-lrt $libs_qga
+else
+ echo
+ echo Error: librt check failed
+ echo
+ exit 1
fi
if test $darwin != yes -a $mingw32 != yes -a $solaris != yes -a \
--
1.7.11.4
Re: [Qemu-devel] [PATCH for-1.2] osdep: Fix compilation failure on BSD systems
On 16 August 2012 14:11, Corey Bryant cor...@linux.vnet.ibm.com wrote: On 08/16/2012 07:15 AM, Peter Maydell wrote: Fix compilation failure on BSD systems (which don't have O_DIRECT or O_NOATIME: osdep.c:116: error: ‘O_DIRECT’ undeclared (first use in this function) osdep.c:116: error: (Each undeclared identifier is reported only once osdep.c:116: error: for each function it appears in.) osdep.c:116: error: ‘O_NOATIME’ undeclared (first use in this function) Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- PS: Do we care about O_DSYNC, O_RSYNC, O_SYNC? POSIX says those can be used via fcntl() too... Thanks very much Peter. The patch looks good to me. Could you point me to the reference you saw the fcntl description in? I didn't notice any flags mentioned here: http://pubs.opengroup.org/onlinepubs/009695399/functions/fcntl.html The choice of flags was based on the Linux man page for fcntl() which says F_SETFL can change only the O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME, and O_NONBLOCK flags. The posix spec for fcntl.h http://pubs.opengroup.org/onlinepubs/007908799/xsh/fcntl.h.html describes all of O_APPEND O_DSYNC O_NONBLOCK O_RSYNC O_SYNC as File status flags used for open() and fcntl(). (However the MacOS fcntl manpage lists only O_APPEND, O_ASYNC and O_NONBLOCK for F_GETFL/F_SETFL flags.) -- PMM
Re: [Qemu-devel] [PATCH 1/2] pc_sysfw: Check for qemu_find_file() failure
On Thu, 16 Aug 2012 13:41:12 +0200
Markus Armbruster arm...@redhat.com wrote:
pc_fw_add_pflash_drv() ignores qemu_find_file() failure, and happily
creates a drive without a medium.
When pc_system_flash_init() asks for its size, bdrv_getlength() fails
with -ENOMEDIUM, which isn't checked either. It fails relatively
cleanly only because -ENOMEDIUM isn't a multiple of 4096:
$ qemu-system-x86_64 -S -vnc :0 -bios nonexistant
qemu: PC system firmware (pflash) must be a multiple of 0x1000
[Exit 1 ]
Fix by handling the qemu_find_file() failure.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/pc_sysfw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/pc_sysfw.c b/hw/pc_sysfw.c
index b45f0ac..fd22154 100644
--- a/hw/pc_sysfw.c
+++ b/hw/pc_sysfw.c
@@ -84,6 +84,11 @@ static void pc_fw_add_pflash_drv(void)
bios_name = BIOS_FILENAME;
}
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (!filename) {
+error_report(Can't open BIOS image %s: %s,
+ bios_name, strerror(errno));
Why not use plain fprintf()? This is called from machine init time, I
don't think this is ever called in monitor context.
Also, maybe you could add the following patch to this series?
http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg04686.html
Although I'm not sure it qualifies for hard-freeze...
+exit(1);
+}
opts = drive_add(IF_PFLASH, -1, filename, readonly=on);
Re: [Qemu-devel] [PATCH] Spelling fixes in comments and macro names (ressource - resource)
On Thu, Aug 16, 2012 at 03:12:21PM +0200, Stefan Weil wrote: Macro XEN_HOST_PCI_RESOURCE_BUFFER_SIZE is only used locally, so the change should be safe. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/xen-host-pci-device.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH] Documentation: Warn against qemu-img on active image
Am 16.08.2012 14:56, schrieb Eric Blake:
On 08/16/2012 04:00 AM, Peter Maydell wrote:
On 16 August 2012 10:00, Kevin Wolf kw...@redhat.com wrote:
People have repeatedly expected that you can do things like snapshotting
an image with qemu-img while a qemu instance is running. Maybe we need
to consider locking the files while they are in use,
Sounds like a nice feature bit to add to qcow2v3, where both qemu-img
and qemu check if the locking feature is enabled for an image, as well
as maintain a header bit that is set when the image is open read-write
and refuse to use the image if the lock bit is set.
I thought the same. However, then you need some way to override this
mechanism when recovering from a crash etc., so it's not a trivial
addition and it would be user-visible.
but having a
warning in the qemu-img manpage is doable for 1.2 and can't hurt anyway.
Signed-off-by: Kevin Wolf kw...@redhat.com
+
+@b{Warning:} Never use qemu-img to modify images in use by a running
virtual
+machine or any other process, this may destroy the image.
; or , because.
Is this strong enough? Remember, with qcow2v3 and qed, the mere act of
opening an image will perform refcount checks that modify the image,
unless you explicitly request otherwise, which means even a query of the
file metadata may result in modifying the image as part of the default
open.
Not for read-only opens. I think qemu-img gets this right meanwhile, so
that images are opened read-only when they are only queried.
(And for qcow2v3 the check only happens with lazy refcounting enabled,
which is not the default)
Maybe incorporate some ideas from this attempt:
Never use qemu-img to modify files in use by a running virtual machine
or any other process; this may destroy the image. Be aware that some
image formats perform modifications even on query operations. Also, be
aware that querying an image that is being modified by another process
may encounter inconsistent state.
Adding the last sentence is probably a good idea anyway.
Kevin
Re: [Qemu-devel] [PATCH for-1.2 v3 1/3] qlist: add qlist_size()
On Wed, 15 Aug 2012 13:45:42 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
I've applied this series to the qmp branch for 1.2. I'll run some tests and if
all goes alright will send a pull request shortly.
---
qlist.c | 13 +
qlist.h |1 +
2 files changed, 14 insertions(+)
diff --git a/qlist.c b/qlist.c
index 88498b1..b48ec5b 100644
--- a/qlist.c
+++ b/qlist.c
@@ -124,6 +124,19 @@ int qlist_empty(const QList *qlist)
return QTAILQ_EMPTY(qlist-head);
}
+static void qlist_size_iter(QObject *obj, void *opaque)
+{
+size_t *count = opaque;
+(*count)++;
+}
+
+size_t qlist_size(const QList *qlist)
+{
+size_t count = 0;
+qlist_iter(qlist, qlist_size_iter, count);
+return count;
+}
+
/**
* qobject_to_qlist(): Convert a QObject into a QList
*/
diff --git a/qlist.h b/qlist.h
index d426bd4..ae776f9 100644
--- a/qlist.h
+++ b/qlist.h
@@ -49,6 +49,7 @@ void qlist_iter(const QList *qlist,
QObject *qlist_pop(QList *qlist);
QObject *qlist_peek(QList *qlist);
int qlist_empty(const QList *qlist);
+size_t qlist_size(const QList *qlist);
QList *qobject_to_qlist(const QObject *obj);
static inline const QListEntry *qlist_first(const QList *qlist)
Re: [Qemu-devel] 2 issues with qemu-master / 1.2 ehci code
Hi,
On 08/14/2012 06:12 PM, Hans de Goede wrote:
Hi,
snip
2) I'm hitting:
qemu-system-x86_64: /home/hans/projects/qemu/hw/usb/hcd-ehci.c:2075:
ehci_state_executing: Assertion `p-qtdaddr == q-qtdaddr' failed.
When trying to redirect a microsoft lifecam, since this is a device with
multiple interfaces
(both uvc and usb-audio) I think it may be a case of multiple control requests
getting submitted at the same time,
but that is just a wild guess.
Some gdb output:
(gdb) fr 4
#4 0x556c33ce in ehci_state_executing (q=0x566c9590)
at /home/hans/projects/qemu/hw/usb/hcd-ehci.c:2075
2075assert(p-qtdaddr == q-qtdaddr);
(gdb) p q
$1 = (EHCIQueue *) 0x566c9590
(gdb) p *q
$2 = {ehci = 0x566e58b0, next = {tqe_next = 0x566c23e0, tqe_prev =
0x566e7188}, seen = 1, ts = 500707440673, async = 1, revalidate = 0,
qh = {next = 915959810, epchar = 1077960706, epcap = 1073741824,
current_qtd = 915964192, next_qtd = 915964384, altnext_qtd = 1, token =
2147483720, bufptr = {865509240, 0, 0, 0, 0}}, qhaddr = 915959906,
qtdaddr = 915964192, dev = 0x56710e10, packets = {tqh_first =
0x5676a440, tqh_last = 0x5676aca8}}
(gdb) p *p
$3 = {queue = 0x566c9590, next = {tqe_next = 0x5676aca0, tqe_prev =
0x566c9600}, qtd = {next = 915964288, altnext = 1, token = 2147683712,
bufptr = {865509232, 0, 0, 0, 0}}, qtdaddr = 915964480, packet = {pid =
105, ep = 0x56711f08, iov = {iov = 0x5676a960, niov = 1, nalloc =
1, size = 3}, parameter = 0, result = -3, state = USB_PACKET_COMPLETE,
queue = {tqe_next = 0x5676ace0, tqe_prev = 0x56711f20}}, sgl = {
sg = 0x56769940, nsg = 1, nalloc = 5, size = 3, dma = 0x0}, pid = 105,
tbytes = 3, async = EHCI_ASYNC_FINISHED, usb_status = -3}
Ok, I've managed to significantly narrow this down, this is caused by
ehci_fill_queue() adding packets to the queue with different qtdaddr values
then the first one already queued up, this is of course more or less fully
expected, but does trigger the assert in question ...
I can get things working by turning ehci_fill_queue() into a nop...
Investigating
this further. But if you've any insights they would be appreciated. I'm thinking
this may be caused by packets completing out of order, which could be caused
by the special handling of some ctrl commands ...
Regards,
Hans
[Qemu-devel] [PATCH 2/3] pxa2xx: Get BlockDriverState* in mmc controller init, not board init
Instead of getting the BlockDriverState* in the pxa2xx board init
and passing it to the mmc controller's init function, have the
mmc controller get the next IF_SD device and use it if present.
This brings us into line with other SD controller models and
means that we correctly emulate an SD controller with no card
present if the user didn't ask for an SD card.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/pxa.h |2 +-
hw/pxa2xx.c | 16 ++--
hw/pxa2xx_mmci.c |7 +--
3 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/hw/pxa.h b/hw/pxa.h
index 6a21205..569994b 100644
--- a/hw/pxa.h
+++ b/hw/pxa.h
@@ -87,7 +87,7 @@ void pxa2xx_lcdc_oritentation(void *opaque, int angle);
typedef struct PXA2xxMMCIState PXA2xxMMCIState;
PXA2xxMMCIState *pxa2xx_mmci_init(MemoryRegion *sysmem,
target_phys_addr_t base,
-BlockDriverState *bd, qemu_irq irq,
+qemu_irq irq,
qemu_irq rx_dma, qemu_irq tx_dma);
void pxa2xx_mmci_handlers(PXA2xxMMCIState *s, qemu_irq readonly,
qemu_irq coverswitch);
diff --git a/hw/pxa2xx.c b/hw/pxa2xx.c
index d5f1420..2c3ef1f 100644
--- a/hw/pxa2xx.c
+++ b/hw/pxa2xx.c
@@ -2006,7 +2006,6 @@ PXA2xxState *pxa270_init(MemoryRegion *address_space,
{
PXA2xxState *s;
int i;
-DriveInfo *dinfo;
s = (PXA2xxState *) g_malloc0(sizeof(PXA2xxState));
if (revision strncmp(revision, pxa27, 5)) {
@@ -2047,12 +2046,7 @@ PXA2xxState *pxa270_init(MemoryRegion *address_space,
s-gpio = pxa2xx_gpio_init(0x40e0, s-cpu-env, s-pic, 121);
-dinfo = drive_get(IF_SD, 0, 0);
-if (!dinfo) {
-fprintf(stderr, qemu: missing SecureDigital device\n);
-exit(1);
-}
-s-mmc = pxa2xx_mmci_init(address_space, 0x4110, dinfo-bdrv,
+s-mmc = pxa2xx_mmci_init(address_space, 0x4110,
qdev_get_gpio_in(s-pic, PXA2XX_PIC_MMC),
qdev_get_gpio_in(s-dma, PXA2XX_RX_RQ_MMCI),
qdev_get_gpio_in(s-dma, PXA2XX_TX_RQ_MMCI));
@@ -2143,7 +2137,6 @@ PXA2xxState *pxa255_init(MemoryRegion *address_space,
unsigned int sdram_size)
{
PXA2xxState *s;
int i;
-DriveInfo *dinfo;
s = (PXA2xxState *) g_malloc0(sizeof(PXA2xxState));
@@ -2178,12 +2171,7 @@ PXA2xxState *pxa255_init(MemoryRegion *address_space,
unsigned int sdram_size)
s-gpio = pxa2xx_gpio_init(0x40e0, s-cpu-env, s-pic, 85);
-dinfo = drive_get(IF_SD, 0, 0);
-if (!dinfo) {
-fprintf(stderr, qemu: missing SecureDigital device\n);
-exit(1);
-}
-s-mmc = pxa2xx_mmci_init(address_space, 0x4110, dinfo-bdrv,
+s-mmc = pxa2xx_mmci_init(address_space, 0x4110,
qdev_get_gpio_in(s-pic, PXA2XX_PIC_MMC),
qdev_get_gpio_in(s-dma, PXA2XX_RX_RQ_MMCI),
qdev_get_gpio_in(s-dma, PXA2XX_TX_RQ_MMCI));
diff --git a/hw/pxa2xx_mmci.c b/hw/pxa2xx_mmci.c
index b505a4c..f645773 100644
--- a/hw/pxa2xx_mmci.c
+++ b/hw/pxa2xx_mmci.c
@@ -14,6 +14,7 @@
#include pxa.h
#include sd.h
#include qdev.h
+#include blockdev.h
struct PXA2xxMMCIState {
MemoryRegion iomem;
@@ -523,10 +524,11 @@ static int pxa2xx_mmci_load(QEMUFile *f, void *opaque,
int version_id)
PXA2xxMMCIState *pxa2xx_mmci_init(MemoryRegion *sysmem,
target_phys_addr_t base,
-BlockDriverState *bd, qemu_irq irq,
+qemu_irq irq,
qemu_irq rx_dma, qemu_irq tx_dma)
{
PXA2xxMMCIState *s;
+DriveInfo *dinfo;
s = (PXA2xxMMCIState *) g_malloc0(sizeof(PXA2xxMMCIState));
s-irq = irq;
@@ -538,7 +540,8 @@ PXA2xxMMCIState *pxa2xx_mmci_init(MemoryRegion *sysmem,
memory_region_add_subregion(sysmem, base, s-iomem);
/* Instantiate the actual storage */
-s-card = sd_init(bd, 0);
+dinfo = drive_get_next(IF_SD);
+s-card = sd_init(dinfo ? dinfo-bdrv : NULL, 0);
register_savevm(NULL, pxa2xx_mmci, 0, 0,
pxa2xx_mmci_save, pxa2xx_mmci_load, s);
--
1.7.9.5
[Qemu-devel] [PATCH] ehci: Remove unnecessary ehci_flush_qh call
ehci_qh_do_overlay() already calls ehci_flush_qh() before it returns, calling
it twice is useless.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hw/usb/hcd-ehci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/hw/usb/hcd-ehci.c b/hw/usb/hcd-ehci.c
index 8b94b17..41d663d 100644
--- a/hw/usb/hcd-ehci.c
+++ b/hw/usb/hcd-ehci.c
@@ -1956,7 +1956,6 @@ static int ehci_state_fetchqtd(EHCIQueue *q)
}
if (p != NULL) {
ehci_qh_do_overlay(q);
-ehci_flush_qh(q);
if (p-async == EHCI_ASYNC_INFLIGHT) {
ehci_set_state(q-ehci, q-async, EST_HORIZONTALQH);
} else {
--
1.7.11.4
Re: [Qemu-devel] [PATCH] Documentation: Warn against qemu-img on active image
On 08/16/2012 07:35 AM, Kevin Wolf wrote: Am 16.08.2012 14:56, schrieb Eric Blake: On 08/16/2012 04:00 AM, Peter Maydell wrote: On 16 August 2012 10:00, Kevin Wolf kw...@redhat.com wrote: People have repeatedly expected that you can do things like snapshotting an image with qemu-img while a qemu instance is running. Maybe we need to consider locking the files while they are in use, Sounds like a nice feature bit to add to qcow2v3, where both qemu-img and qemu check if the locking feature is enabled for an image, as well as maintain a header bit that is set when the image is open read-write and refuse to use the image if the lock bit is set. I thought the same. However, then you need some way to override this mechanism when recovering from a crash etc., so it's not a trivial addition and it would be user-visible. Good point. With fcntl() locking, the lock goes away on crash; but with file modification locking, the lock can get stuck so you have to provide overrides; and once you provide overrides, the lock is not quite as powerful. So maybe it's best to just leave locking up to management apps (after all, libvirt already has a lock protocol support, currently built on sanlock but also with a patch proposed for using fcntl()). Is this strong enough? Remember, with qcow2v3 and qed, the mere act of opening an image will perform refcount checks that modify the image, unless you explicitly request otherwise, which means even a query of the file metadata may result in modifying the image as part of the default open. Not for read-only opens. I think qemu-img gets this right meanwhile, so that images are opened read-only when they are only queried. Then it might also be worth documenting which actions are read-only queries vs. potential modifications, in the docs for each action. (For example, 'info' is read-only, 'convert' is read-only when creating a copy although consistency is essential for it to be useful, 'check' is readonly while 'check -r' is read-write,...) -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 1/2] pc_sysfw: Check for qemu_find_file() failure
Luiz Capitulino lcapitul...@redhat.com writes:
On Thu, 16 Aug 2012 13:41:12 +0200
Markus Armbruster arm...@redhat.com wrote:
pc_fw_add_pflash_drv() ignores qemu_find_file() failure, and happily
creates a drive without a medium.
When pc_system_flash_init() asks for its size, bdrv_getlength() fails
with -ENOMEDIUM, which isn't checked either. It fails relatively
cleanly only because -ENOMEDIUM isn't a multiple of 4096:
$ qemu-system-x86_64 -S -vnc :0 -bios nonexistant
qemu: PC system firmware (pflash) must be a multiple of 0x1000
[Exit 1 ]
Fix by handling the qemu_find_file() failure.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/pc_sysfw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/pc_sysfw.c b/hw/pc_sysfw.c
index b45f0ac..fd22154 100644
--- a/hw/pc_sysfw.c
+++ b/hw/pc_sysfw.c
@@ -84,6 +84,11 @@ static void pc_fw_add_pflash_drv(void)
bios_name = BIOS_FILENAME;
}
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (!filename) {
+error_report(Can't open BIOS image %s: %s,
+ bios_name, strerror(errno));
Why not use plain fprintf()? This is called from machine init time, I
don't think this is ever called in monitor context.
error_report() makes the fact that's an error message obvious and
greppable. It also prepends the message with PROGNAME:, which is better
than literal qemu: when the executable isn't called qemu. It would
even point to -bios nicely if we bothered to preserve that information
(we lose it by storing the option argument as naked char * without the
location).
Also, maybe you could add the following patch to this series?
http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg04686.html
Can do in case I need to respin anyway.
Although I'm not sure it qualifies for hard-freeze...
I didn't tag my series for-1.2. I understand that fixes to
not-so-important stuff aren't welcome at this time even when they're
really simple.
+exit(1);
+}
opts = drive_add(IF_PFLASH, -1, filename, readonly=on);
[Qemu-devel] [PATCH 3/3] Drop default SD card creation
Now that all users of IF_SD drives can cope with there being
no drive present (ie controller exists but there is no card in it)
we can drop the creation of the default IF_SD card in vl.c and
the no_sdcard field in the QEMUMachine struct.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/boards.h |3 +--
hw/s390-virtio.c |1 -
hw/xilinx_zynq.c |1 -
vl.c |7 ---
4 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/hw/boards.h b/hw/boards.h
index 59c01d0..af4c019 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -23,8 +23,7 @@ typedef struct QEMUMachine {
no_parallel:1,
use_virtcon:1,
no_floppy:1,
-no_cdrom:1,
-no_sdcard:1;
+no_cdrom:1;
int is_default;
const char *default_machine_opts;
GlobalProperty *compat_props;
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 47eed35..560393f 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -338,7 +338,6 @@ static QEMUMachine s390_machine = {
.no_floppy = 1,
.no_serial = 1,
.no_parallel = 1,
-.no_sdcard = 1,
.use_virtcon = 1,
.max_cpus = 255,
.is_default = 1,
diff --git a/hw/xilinx_zynq.c b/hw/xilinx_zynq.c
index 7e6c273..b532953 100644
--- a/hw/xilinx_zynq.c
+++ b/hw/xilinx_zynq.c
@@ -146,7 +146,6 @@ static QEMUMachine zynq_machine = {
.init = zynq_init,
.use_scsi = 1,
.max_cpus = 1,
-.no_sdcard = 1
};
static void zynq_machine_init(void)
diff --git a/vl.c b/vl.c
index d01256a..ba1953c 100644
--- a/vl.c
+++ b/vl.c
@@ -268,7 +268,6 @@ static int default_virtcon = 1;
static int default_monitor = 1;
static int default_floppy = 1;
static int default_cdrom = 1;
-static int default_sdcard = 1;
static int default_vga = 1;
static struct {
@@ -3169,7 +3168,6 @@ int main(int argc, char **argv, char **envp)
default_net = 0;
default_floppy = 0;
default_cdrom = 0;
-default_sdcard = 0;
default_vga = 0;
break;
case QEMU_OPTION_xen_domid:
@@ -3343,9 +3341,6 @@ int main(int argc, char **argv, char **envp)
if (machine-no_cdrom) {
default_cdrom = 0;
}
-if (machine-no_sdcard) {
-default_sdcard = 0;
-}
if (display_type == DT_NOGRAPHIC) {
if (default_parallel)
@@ -3488,8 +3483,6 @@ int main(int argc, char **argv, char **envp)
IF_DEFAULT, 2, CDROM_OPTS);
default_drive(default_floppy, snapshot, machine-use_scsi,
IF_FLOPPY, 0, FD_OPTS);
-default_drive(default_sdcard, snapshot, machine-use_scsi,
- IF_SD, 0, SD_OPTS);
register_savevm_live(NULL, ram, 0, 4, savevm_ram_handlers, NULL);
--
1.7.9.5
[Qemu-devel] [PATCH 0/3] Drop default SD card creation
As suggested in the recent discussion on Marcks' patchset to suppress unused default drives, this patchset cleans up the omap and pxa2xx SD card controllers to behave like the other controllers: * the init function looks for the next IF_SD drive * if there isn't one, we start up as a controller with no card present This then allows us to drop the QEMUMachine no_sdcard flag and the vl.c code which creates a dummy IF_SD drive. Not intended for 1.2, obviously. Peter Maydell (3): omap: Get BlockDriverState* in mmc controller init, not board init pxa2xx: Get BlockDriverState* in mmc controller init, not board init Drop default SD card creation hw/boards.h |3 +-- hw/omap.h|3 +-- hw/omap1.c |8 +--- hw/omap2.c |8 +--- hw/omap_mmc.c| 12 hw/pxa.h |2 +- hw/pxa2xx.c | 16 ++-- hw/pxa2xx_mmci.c |7 +-- hw/s390-virtio.c |1 - hw/xilinx_zynq.c |1 - vl.c |7 --- 11 files changed, 20 insertions(+), 48 deletions(-) -- 1.7.9.5
[Qemu-devel] [PATCH 1/3] omap: Get BlockDriverState* in mmc controller init, not board init
Instead of getting the BlockDriverState* in the omap board init
and passing it to the mmc controller's init function, have the
mmc controller get the next IF_SD device and use it if present.
This brings us into line with other SD controller models and
means that we correctly emulate an SD controller with no card
present if the user didn't ask for an SD card.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/omap.h |3 +--
hw/omap1.c|8 +---
hw/omap2.c|8 +---
hw/omap_mmc.c | 12
4 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/hw/omap.h b/hw/omap.h
index 413851b..de5ec8c 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -754,10 +754,9 @@ void omap_rfbi_attach(struct omap_dss_s *s, int cs, struct
rfbi_chip_s *chip);
struct omap_mmc_s;
struct omap_mmc_s *omap_mmc_init(target_phys_addr_t base,
MemoryRegion *sysmem,
-BlockDriverState *bd,
qemu_irq irq, qemu_irq dma[], omap_clk clk);
struct omap_mmc_s *omap2_mmc_init(struct omap_target_agent_s *ta,
-BlockDriverState *bd, qemu_irq irq, qemu_irq dma[],
+qemu_irq irq, qemu_irq dma[],
omap_clk fclk, omap_clk iclk);
void omap_mmc_reset(struct omap_mmc_s *s);
void omap_mmc_handlers(struct omap_mmc_s *s, qemu_irq ro, qemu_irq cover);
diff --git a/hw/omap1.c b/hw/omap1.c
index ad60cc4..641e260 100644
--- a/hw/omap1.c
+++ b/hw/omap1.c
@@ -3823,7 +3823,6 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion
*system_memory,
g_malloc0(sizeof(struct omap_mpu_state_s));
qemu_irq *cpu_irq;
qemu_irq dma_irqs[6];
-DriveInfo *dinfo;
SysBusDevice *busdev;
if (!core)
@@ -3961,12 +3960,7 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion
*system_memory,
s-dpll[2] = omap_dpll_init(system_memory, 0xfffed100,
omap_findclk(s, dpll3));
-dinfo = drive_get(IF_SD, 0, 0);
-if (!dinfo) {
-fprintf(stderr, qemu: missing SecureDigital device\n);
-exit(1);
-}
-s-mmc = omap_mmc_init(0xfffb7800, system_memory, dinfo-bdrv,
+s-mmc = omap_mmc_init(0xfffb7800, system_memory,
qdev_get_gpio_in(s-ih[1], OMAP_INT_OQN),
s-drq[OMAP_DMA_MMC_TX],
omap_findclk(s, mmc_ck));
diff --git a/hw/omap2.c b/hw/omap2.c
index 4278dd1..28178dd 100644
--- a/hw/omap2.c
+++ b/hw/omap2.c
@@ -2246,7 +2246,6 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion
*sysmem,
g_malloc0(sizeof(struct omap_mpu_state_s));
qemu_irq *cpu_irq;
qemu_irq dma_irqs[4];
-DriveInfo *dinfo;
int i;
SysBusDevice *busdev;
struct omap_target_agent_s *ta;
@@ -2454,12 +2453,7 @@ struct omap_mpu_state_s *omap2420_mpu_init(MemoryRegion
*sysmem,
qdev_get_gpio_in(s-ih[0],
OMAP_INT_24XX_GPMC_IRQ),
s-drq[OMAP24XX_DMA_GPMC]);
-dinfo = drive_get(IF_SD, 0, 0);
-if (!dinfo) {
-fprintf(stderr, qemu: missing SecureDigital device\n);
-exit(1);
-}
-s-mmc = omap2_mmc_init(omap_l4tao(s-l4, 9), dinfo-bdrv,
+s-mmc = omap2_mmc_init(omap_l4tao(s-l4, 9),
qdev_get_gpio_in(s-ih[0], OMAP_INT_24XX_MMC_IRQ),
s-drq[OMAP24XX_DMA_MMC1_TX],
omap_findclk(s, mmc_fclk), omap_findclk(s, mmc_iclk));
diff --git a/hw/omap_mmc.c b/hw/omap_mmc.c
index aec0285..eada07d 100644
--- a/hw/omap_mmc.c
+++ b/hw/omap_mmc.c
@@ -19,6 +19,7 @@
#include hw.h
#include omap.h
#include sd.h
+#include blockdev.h
struct omap_mmc_s {
qemu_irq irq;
@@ -574,9 +575,9 @@ static void omap_mmc_cover_cb(void *opaque, int line, int
level)
struct omap_mmc_s *omap_mmc_init(target_phys_addr_t base,
MemoryRegion *sysmem,
-BlockDriverState *bd,
qemu_irq irq, qemu_irq dma[], omap_clk clk)
{
+DriveInfo *dinfo;
struct omap_mmc_s *s = (struct omap_mmc_s *)
g_malloc0(sizeof(struct omap_mmc_s));
@@ -592,15 +593,17 @@ struct omap_mmc_s *omap_mmc_init(target_phys_addr_t base,
memory_region_add_subregion(sysmem, base, s-iomem);
/* Instantiate the storage */
-s-card = sd_init(bd, 0);
+dinfo = drive_get_next(IF_SD);
+s-card = sd_init(dinfo ? dinfo-bdrv : NULL, 0);
return s;
}
struct omap_mmc_s *omap2_mmc_init(struct omap_target_agent_s *ta,
-BlockDriverState *bd, qemu_irq irq, qemu_irq dma[],
+qemu_irq irq, qemu_irq dma[],
omap_clk fclk, omap_clk iclk)
{
+DriveInfo *dinfo;
struct omap_mmc_s *s = (struct omap_mmc_s *)
g_malloc0(sizeof(struct omap_mmc_s));
@@ -617,7 +620,8 @@ struct omap_mmc_s *omap2_mmc_init(struct
omap_target_agent_s *ta,
omap_l4_attach(ta, 0, s-iomem);
/* Instantiate the storage */
-s-card = sd_init(bd, 0);
+dinfo =
Re: [Qemu-devel] [PATCH 1/2] pc_sysfw: Check for qemu_find_file() failure
Am 16.08.2012 15:50, schrieb Markus Armbruster: Although I'm not sure it qualifies for hard-freeze... I didn't tag my series for-1.2. I understand that fixes to not-so-important stuff aren't welcome at this time even when they're really simple. It's a clear bug fix, easy to understand and low risk, and even rc0 isn't out yet. I think this would still be fine for 1.2. Kevin
Re: [Qemu-devel] [PATCH 1/2] pc_sysfw: Check for qemu_find_file() failure
On Thu, 16 Aug 2012 15:50:51 +0200
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
On Thu, 16 Aug 2012 13:41:12 +0200
Markus Armbruster arm...@redhat.com wrote:
pc_fw_add_pflash_drv() ignores qemu_find_file() failure, and happily
creates a drive without a medium.
When pc_system_flash_init() asks for its size, bdrv_getlength() fails
with -ENOMEDIUM, which isn't checked either. It fails relatively
cleanly only because -ENOMEDIUM isn't a multiple of 4096:
$ qemu-system-x86_64 -S -vnc :0 -bios nonexistant
qemu: PC system firmware (pflash) must be a multiple of 0x1000
[Exit 1 ]
Fix by handling the qemu_find_file() failure.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/pc_sysfw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/pc_sysfw.c b/hw/pc_sysfw.c
index b45f0ac..fd22154 100644
--- a/hw/pc_sysfw.c
+++ b/hw/pc_sysfw.c
@@ -84,6 +84,11 @@ static void pc_fw_add_pflash_drv(void)
bios_name = BIOS_FILENAME;
}
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (!filename) {
+error_report(Can't open BIOS image %s: %s,
+ bios_name, strerror(errno));
Why not use plain fprintf()? This is called from machine init time, I
don't think this is ever called in monitor context.
error_report() makes the fact that's an error message obvious and
greppable.
fprintf(stderr, ...) too.
It also prepends the message with PROGNAME:, which is better
than literal qemu: when the executable isn't called qemu.
We can't spread error_report() usage just because of that. I mean, we're not
going to replace every usage of fprintf(stderr, ...) with error_report() just
because of that, right?
For this fix, I suggest calling fprintf() plus abort(), which is what is
done by the caller and several functions in the call chain.
For the long term, I suggest adding:
o error_printf() prepend PROGNAME and calls fprintf()
o die(): calls error_printf() and exit(1)
It would
even point to -bios nicely if we bothered to preserve that information
(we lose it by storing the option argument as naked char * without the
location).
Also, maybe you could add the following patch to this series?
http://lists.gnu.org/archive/html/qemu-devel/2012-06/msg04686.html
Can do in case I need to respin anyway.
Although I'm not sure it qualifies for hard-freeze...
I didn't tag my series for-1.2. I understand that fixes to
not-so-important stuff aren't welcome at this time even when they're
really simple.
+exit(1);
+}
opts = drive_add(IF_PFLASH, -1, filename, readonly=on);
Re: [Qemu-devel] [PATCH] Spelling fixes in comments and macro names (ressource - resource)
Am 16.08.2012 15:32, schrieb Stefan Hajnoczi: On Thu, Aug 16, 2012 at 03:12:21PM +0200, Stefan Weil wrote: Macro XEN_HOST_PCI_RESOURCE_BUFFER_SIZE is only used locally, so the change should be safe. Signed-off-by: Stefan Weil s...@weilnetz.de --- hw/xen-host-pci-device.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches CC'ing the Xen folks. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for-1.2 v3 2/3] json-parser: don't replicate tokens at each level of recursion
On Wed, 15 Aug 2012 13:45:43 -0500
Michael Roth mdr...@linux.vnet.ibm.com wrote:
Currently, when parsing a stream of tokens we make a copy of the token
list at the beginning of each level of recursion so that we do not
modify the original list in cases where we need to fall back to an
earlier state.
In the worst case, we will only read 1 or 2 tokens off the list before
recursing again, which means an upper bound of roughly N^2 token allocations.
For a reasonably sized QMP request (in this a QMP representation of
cirrus_vga's device state, generated via QIDL, being passed in via
qom-set), this caused my 16GB's of memory to be exhausted before any
noticeable progress was made by the parser.
This patch works around the issue by using single copy of the token list
in the form of an indexable array so that we can save/restore state by
manipulating indices.
A subsequent commit adds a large_dict test case which exhibits the
same behavior as above. With this patch applied the test case successfully
completes in under a second.
Tested with valgrind, make check, and QMP.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
json-parser.c | 230
+++--
1 file changed, 142 insertions(+), 88 deletions(-)
diff --git a/json-parser.c b/json-parser.c
index 849e215..457291b 100644
--- a/json-parser.c
+++ b/json-parser.c
@@ -27,6 +27,11 @@
typedef struct JSONParserContext
{
Error *err;
+struct {
+QObject **buf;
+size_t pos;
+size_t count;
+} tokens;
} JSONParserContext;
#define BUG_ON(cond) assert(!(cond))
@@ -40,7 +45,7 @@ typedef struct JSONParserContext
* 4) deal with premature EOI
*/
-static QObject *parse_value(JSONParserContext *ctxt, QList **tokens, va_list
*ap);
+static QObject *parse_value(JSONParserContext *ctxt, va_list *ap);
/**
* Token manipulators
@@ -270,27 +275,111 @@ out:
return NULL;
}
+static QObject *parser_context_pop_token(JSONParserContext *ctxt)
+{
+QObject *token;
+g_assert(ctxt-tokens.pos ctxt-tokens.count);
+token = ctxt-tokens.buf[ctxt-tokens.pos];
+ctxt-tokens.pos++;
Shouldn't pos be decremented instead? Haven't tried it yet to confirm, but
if I'm right I can fix it myself (unless this requires fixes in other areas).
+return token;
+}
+
+/* Note: parser_context_{peek|pop}_token do not increment the
+ * token object's refcount. In both cases the references will continue
+ * to be tracked and cleaned up in parser_context_free(), so do not
+ * attempt to free the token object.
+ */
+static QObject *parser_context_peek_token(JSONParserContext *ctxt)
+{
+QObject *token;
+g_assert(ctxt-tokens.pos ctxt-tokens.count);
+token = ctxt-tokens.buf[ctxt-tokens.pos];
+return token;
+}
+
+static JSONParserContext parser_context_save(JSONParserContext *ctxt)
+{
+JSONParserContext saved_ctxt = {0};
+saved_ctxt.tokens.pos = ctxt-tokens.pos;
+saved_ctxt.tokens.count = ctxt-tokens.count;
+saved_ctxt.tokens.buf = ctxt-tokens.buf;
+return saved_ctxt;
+}
+
+static void parser_context_restore(JSONParserContext *ctxt,
+ JSONParserContext saved_ctxt)
+{
+ctxt-tokens.pos = saved_ctxt.tokens.pos;
+ctxt-tokens.count = saved_ctxt.tokens.count;
+ctxt-tokens.buf = saved_ctxt.tokens.buf;
+}
+
+static void tokens_append_from_iter(QObject *obj, void *opaque)
+{
+JSONParserContext *ctxt = opaque;
+g_assert(ctxt-tokens.pos ctxt-tokens.count);
+ctxt-tokens.buf[ctxt-tokens.pos++] = obj;
+qobject_incref(obj);
+}
+
+static JSONParserContext *parser_context_new(QList *tokens)
+{
+JSONParserContext *ctxt;
+size_t count;
+
+if (!tokens) {
+return NULL;
+}
+
+count = qlist_size(tokens);
+if (count == 0) {
+return NULL;
+}
+
+ctxt = g_malloc0(sizeof(JSONParserContext));
+ctxt-tokens.pos = 0;
+ctxt-tokens.count = count;
+ctxt-tokens.buf = g_malloc(count * sizeof(QObject *));
+qlist_iter(tokens, tokens_append_from_iter, ctxt);
+ctxt-tokens.pos = 0;
+
+return ctxt;
+}
+
+/* to support error propagation, ctxt-err must be freed separately */
+static void parser_context_free(JSONParserContext *ctxt)
+{
+int i;
+if (ctxt) {
+for (i = 0; i ctxt-tokens.count; i++) {
+qobject_decref(ctxt-tokens.buf[i]);
+}
+g_free(ctxt-tokens.buf);
+g_free(ctxt);
+}
+}
+
/**
* Parsing rules
*/
-static int parse_pair(JSONParserContext *ctxt, QDict *dict, QList **tokens,
va_list *ap)
+static int parse_pair(JSONParserContext *ctxt, QDict *dict, va_list *ap)
{
QObject *key = NULL, *token = NULL, *value, *peek;
-QList *working = qlist_copy(*tokens);
+JSONParserContext saved_ctxt = parser_context_save(ctxt);
-peek =
Re: [Qemu-devel] Windows slow boot: contractor wanted
Le Thursday 16 Aug 2012 à 11:47:27 (+0100), Richard Davies a écrit : Hi, We run a cloud hosting provider using qemu-kvm 1.1, and are keen to find a contractor to track down and fix problems we have with large memory Windows guests booting very slowly - they can take several hours. We previously reported these problems in July (copied below) and they are still present with Linux kernel 3.5.1 and qemu-kvm 1.1.1. This is a serious issue for us which is causing significant pain to our larger Windows VM customers when their servers are offline for many hours during boot. If anyone knowledgeable in the area would be interested in being paid to work on this, or if you know someone who might be, I would be delighted to hear from you. Cheers, Richard. = Previous bug report http://marc.info/?l=qemu-develm=134304194329745 We have been experiencing this problem for a while now too, using qemu-kvm (currently at 1.1.1). Unfortunately, hv_relaxed doesn't seem to fix it. The following command line produces the issue: qemu-kvm -nodefaults -m 4096 -smp 8 -cpu host,hv_relaxed -vga cirrus -usbdevice tablet -vnc :99 -monitor stdio -hda test.img The hardware consists of dual AMD Opteron 6128 processors (16 cores in total) and 64GB of memory. This command line was tested on kernel 3.1.4. I've also tested with -no-hpet. What I have seen is much as described: the memory fills out slowly, and top on the host will show the process using 100% on all allocated CPU cores. The most extreme case was a machine which took something between 6 and 8 hours to boot. This seems to be related to the assigned memory, as described, but also the number of processor cores (which makes sense if we believe it's a timing issue?). I have seen slow-booting guests improved by switching down to a single or even two cores. Matthew, I agree that this seems to be linked to the number of VMs running - in fact, shutting down other VMs on a dedicated test host caused the machine to start booting at a normal speed (with no reboot required). However, the level of contention is never such that this could be explained by the host simply being overcommitted. If it helps anyone, there's an image of the hard drive I've been using to test at: http://46.20.114.253/ It's 5G of gzip file containing a fairly standard Windows 2008 trial installation. Since it's in the trial period, anyone who wants to use it may have to re-arm the trial: http://support.microsoft.com/kb/948472 Please let me know if I can provide any more information, or test anything. For info the image boot pretty fast with qemu-kvm 1.1.1 and a 3.2.0-29 ubuntu kernel on a core i7 with these parameters. Benoît Best wishes, Owen Tuz
Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation
Peter Maydell peter.mayd...@linaro.org writes: As suggested in the recent discussion on Marcks' patchset to suppress unused default drives, this patchset cleans up the omap and pxa2xx SD card controllers to behave like the other controllers: * the init function looks for the next IF_SD drive * if there isn't one, we start up as a controller with no card present This then allows us to drop the QEMUMachine no_sdcard flag and the vl.c code which creates a dummy IF_SD drive. Not intended for 1.2, obviously. Isn't this an incompatible change? Before, you get an SD card reader backed by an empty BDS default. You can load/unload cards in the monitor. After, you get an SD card reader that isn't backed by a BDS by default. Device models prepared for that can treat it as permanently empty.
