[Qemu-devel] [PATCH 2/2] rdma: Fix incorrect description in comments
Since we have supported memory hotplug, VM's ram include pc.ram
and hotplug-memory.
Fix the confused description for rdma migration: pc.ram - VM's ram
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
---
docs/rdma.txt| 6 +++---
migration-rdma.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/rdma.txt b/docs/rdma.txt
index 1f5d9e9..2bdd0a5 100644
--- a/docs/rdma.txt
+++ b/docs/rdma.txt
@@ -18,7 +18,7 @@ Contents:
* RDMA Migration Protocol Description
* Versioning and Capabilities
* QEMUFileRDMA Interface
-* Migration of pc.ram
+* Migration of VM's ram
* Error handling
* TODO
@@ -149,7 +149,7 @@ The only difference between a SEND message and an RDMA
message is that SEND messages cause notifications
to be posted to the completion queue (CQ) on the
infiniband receiver side, whereas RDMA messages (used
-for pc.ram) do not (to behave like an actual DMA).
+for VM's ram) do not (to behave like an actual DMA).
Messages in infiniband require two things:
@@ -355,7 +355,7 @@ If the buffer is empty, then we follow the same steps
listed above and issue another QEMU File protocol command,
asking for a new SEND message to re-fill the buffer.
-Migration of pc.ram:
+Migration of VM's ram:
At the beginning of the migration, (migration-rdma.c),
diff --git a/migration-rdma.c b/migration-rdma.c
index d99812c..b32dbdf 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -2523,7 +2523,7 @@ static void *qemu_rdma_data_init(const char *host_port,
Error **errp)
/*
* QEMUFile interface to the control channel.
* SEND messages for control only.
- * pc.ram is handled with regular RDMA messages.
+ * VM's ram is handled with regular RDMA messages.
*/
static int qemu_rdma_put_buffer(void *opaque, const uint8_t *buf,
int64_t pos, int size)
@@ -2539,7 +2539,7 @@ static int qemu_rdma_put_buffer(void *opaque, const
uint8_t *buf,
/*
* Push out any writes that
- * we're queued up for pc.ram.
+ * we're queued up for VM's ram.
*/
ret = qemu_rdma_write_flush(f, rdma);
if (ret 0) {
--
1.7.12.4
[Qemu-devel] [PATCH 1/2] vl: Fix the confused logic for '-m' option
It should be valid for the follow configure:
-m 256,slots=0
-m 256,maxmem=256M
-m 256,slots=0,maxmem=256M
-m 256,slots=x,maxmem=y where x 0 and y 256M
Fix the confused code logic and use error_report instead of fprintf.
Printing the maxmem in hex, same with ram_size.
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
---
vl.c | 46 +++---
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/vl.c b/vl.c
index 9c9acf5..f547405 100644
--- a/vl.c
+++ b/vl.c
@@ -3306,6 +3306,7 @@ int main(int argc, char **argv, char **envp)
break;
case QEMU_OPTION_m: {
uint64_t sz;
+uint64_t slots;
const char *mem_str;
const char *maxmem_str, *slots_str;
@@ -3353,40 +3354,47 @@ int main(int argc, char **argv, char **envp)
maxmem_str = qemu_opt_get(opts, maxmem);
slots_str = qemu_opt_get(opts, slots);
-if (maxmem_str slots_str) {
-uint64_t slots;
-
+if (maxmem_str) {
sz = qemu_opt_get_size(opts, maxmem, 0);
+}
+if (slots_str) {
+slots = qemu_opt_get_number(opts, slots, 0);
+}
+if (maxmem_str slots_str) {
if (sz ram_size) {
-fprintf(stderr, qemu: invalid -m option value: maxmem
-(% PRIu64 ) = initial memory (
+error_report(qemu: invalid -m option value: maxmem
+(% PRIx64 ) initial memory (
RAM_ADDR_FMT )\n, sz, ram_size);
exit(EXIT_FAILURE);
}
-
-slots = qemu_opt_get_number(opts, slots, 0);
-if ((sz ram_size) !slots) {
-fprintf(stderr, qemu: invalid -m option value: maxmem
-(% PRIu64 ) more than initial memory (
+if (!slots (sz != ram_size)) {
+error_report(qemu: invalid -m option value: maxmem
+(% PRIx64 ) more than initial memory (
RAM_ADDR_FMT ) but no hotplug slots where
specified\n, sz, ram_size);
exit(EXIT_FAILURE);
}
-
-if ((sz = ram_size) slots) {
-fprintf(stderr, qemu: invalid -m option value: %
+if (slots (sz == ram_size)) {
+error_report(qemu: invalid -m option value: %
PRIu64 hotplug slots where specified but
-maxmem (% PRIu64 ) = initial memory (
+maxmem (% PRIx64 ) = initial memory (
RAM_ADDR_FMT )\n, slots, sz, ram_size);
exit(EXIT_FAILURE);
}
maxram_size = sz;
ram_slots = slots;
-} else if ((!maxmem_str slots_str) ||
- (maxmem_str !slots_str)) {
-fprintf(stderr, qemu: invalid -m option value: missing
-'%s' option\n, slots_str ? maxmem : slots);
-exit(EXIT_FAILURE);
+} else if (!maxmem_str slots_str) {
+if (slots 0) {
+error_report(qemu: invalid -m option value: missing
+'maxmem' option\n);
+exit(EXIT_FAILURE);
+}
+} else if (maxmem_str !slots_str) {
+if (sz != ram_size) {
+error_report(qemu: invalid -m option value: missing
+'slot' option\n);
+exit(EXIT_FAILURE);
+}
}
break;
}
--
1.7.12.4
Re: [Qemu-devel] [RFC PATCH 11/17] COLO ctl: implement colo checkpoint protocol
在 08/01/2014 11:03 PM, Dr. David Alan Gilbert 写道:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
implement colo checkpoint protocol.
Checkpoint synchronzing points.
Primary Secondary
NEW @
Suspend
SUSPENDED @
SuspendSave state
SEND@
Send state Receive state
RECEIVED@
Flush network Load state
LOADED @
Resume Resume
Start Comparing
NOTE:
1) '@' who sends the message
2) Every sync-point is synchronized by two sides with only
one handshake(single direction) for low-latency.
If more strict synchronization is required, a opposite direction
sync-point should be added.
3) Since sync-points are single direction, the remote side may
go forward a lot when this side just receives the sync-point.
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
---
migration-colo.c | 268 +--
1 file changed, 262 insertions(+), 6 deletions(-)
diff --git a/migration-colo.c b/migration-colo.c
index 2699e77..a708872 100644
--- a/migration-colo.c
+++ b/migration-colo.c
@@ -24,6 +24,41 @@
*/
#define CHKPOINT_TIMER 1
+enum {
+COLO_READY = 0x46,
+
+/*
+ * Checkpoint synchronzing points.
+ *
+ * Primary Secondary
+ * NEW @
+ * Suspend
+ * SUSPENDED @
+ * SuspendSave state
+ * SEND@
+ * Send state Receive state
+ * RECEIVED@
+ * Flush network Load state
+ * LOADED @
+ * Resume Resume
+ *
+ * Start Comparing
+ * NOTE:
+ * 1) '@' who sends the message
+ * 2) Every sync-point is synchronized by two sides with only
+ *one handshake(single direction) for low-latency.
+ *If more strict synchronization is required, a opposite direction
+ *sync-point should be added.
+ * 3) Since sync-points are single direction, the remote side may
+ *go forward a lot when this side just receives the sync-point.
+ */
+COLO_CHECKPOINT_NEW,
+COLO_CHECKPOINT_SUSPENDED,
+COLO_CHECKPOINT_SEND,
+COLO_CHECKPOINT_RECEIVED,
+COLO_CHECKPOINT_LOADED,
+};
+
static QEMUBH *colo_bh;
bool colo_supported(void)
@@ -185,30 +220,161 @@ static const QEMUFileOps colo_read_ops = {
.close = colo_close,
};
+/* colo checkpoint control helper */
+static bool is_master(void);
+static bool is_slave(void);
+
+static void ctl_error_handler(void *opaque, int err)
+{
+if (is_slave()) {
+/* TODO: determine whether we need to failover */
+/* FIXME: we will not failover currently, just kill slave */
+error_report(error: colo transmission failed!\n);
+exit(1);
+} else if (is_master()) {
+/* Master still alive, do not failover */
+error_report(error: colo transmission failed!\n);
+return;
+} else {
+error_report(COLO: Unexpected error happend!\n);
+exit(EXIT_FAILURE);
+}
+}
+
+static int colo_ctl_put(QEMUFile *f, uint64_t request)
+{
+int ret = 0;
+
+qemu_put_be64(f, request);
+qemu_fflush(f);
+
+ret = qemu_file_get_error(f);
+if (ret 0) {
+ctl_error_handler(f, ret);
+return 1;
+}
+
+return ret;
+}
+
+static int colo_ctl_get_value(QEMUFile *f, uint64_t *value)
+{
+int ret = 0;
+uint64_t temp;
+
+temp = qemu_get_be64(f);
+
+ret = qemu_file_get_error(f);
+if (ret 0) {
+ctl_error_handler(f, ret);
+return 1;
+}
+
+*value = temp;
+return 0;
+}
+
+static int colo_ctl_get(QEMUFile *f, uint64_t require)
+{
+int ret;
+uint64_t value;
+
+ret = colo_ctl_get_value(f, value);
+if (ret) {
+return ret;
+}
+
+if (value != require) {
+error_report(unexpected state received!\n);
I find it useful to print the expected/received state to
be able to figure out what went wrong.
Good idea!
+exit(1);
+}
+
+return ret;
+}
+
/* save */
-static __attribute__((unused)) bool is_master(void)
+static bool is_master(void)
{
MigrationState *s = migrate_get_current();
return (s-state == MIG_STATE_COLO);
}
+static int do_colo_transaction(MigrationState *s, QEMUFile *control,
+ QEMUFile *trans)
+{
+int ret;
+
+ret = colo_ctl_put(s-file, COLO_CHECKPOINT_NEW);
+if (ret) {
+goto out;
+}
+
+ret = colo_ctl_get(control,
Re: [Qemu-devel] [RFC PATCH 16/17] COLO ram cache: implement colo ram cache on slaver
在 08/01/2014 11:10 PM, Dr. David Alan Gilbert 写道:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
The ram cache was initially the same as PVM's memory. At
checkpoint, we cache the dirty memory of PVM into ram cache
(so that ram cache always the same as PVM's memory at every
checkpoint), flush cached memory to SVM after we received
all PVM dirty memory(only needed to flush memory that was
both dirty on PVM and SVM since last checkpoint).
(Typo: 'r' on the end of the title)
I think I understand the need for the cache, to be able to restore pages
that the SVM has modified that the PVM hadn't; however, if I understand
the change here, (to host_from_stream_offset) the SVM will load the
snapshot into the ram_cache rather than directly into host memory - why
is this necessary? If the SVMs CPU is stopped at this point couldn't
it load snapshot pages directly into host memory, clearing pages in the SVMs
bitmap, so that the only pages that then get copied in flush_cache are
the pages that the SVM modified but the PVM *didn't* include in the snapshot?
I can see that you would need to do it the way you've done it if the
snapshot-load could fail (at the sametime the PVM failed) and thus the old SVM
state would be the surviving state, but how could it fail at this point
given the whole stream is in the colo-buffer?
I can see your confusion. Yes, you are right, we can do as what you said, but
at last, we still need to copy the dirty pages into ram cache as well (because
the ram cache is a snapshot and we need to keep this updated). So the question
is whether we load the dirty pages into snapshot first or into host memory
first. I think both methods can work and make no difference...
+static void ram_flush_cache(void);
static int ram_load(QEMUFile *f, void *opaque, int version_id)
{
ram_addr_t addr;
int flags, ret = 0;
static uint64_t seq_iter;
+bool need_flush = false;
Probably better as 'ram_cache_needs_flush'
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
.
--
Thanks,
Yang.
Re: [Qemu-devel] ui causes latest master build failure on rhel6
pixman-0.21.8 is the oldest release which has PIXMAN_TYPE_RGBA. We don't check for a minimum version. RHEL-6 is probably older. Uhm, well, it isn't (any more): [root@rhel6 ~]# rpm -q pixman pixman-0.26.2-5.1.el6_5.x86_64 Seems to be rebased somewhen (used to be 0.16 for RHEL-6.0 IIRC). Looks like you should simply update your RHEL-6 machine. Try 'configure --without-system-pixman' as workaround (after checking out the pixman submodule). I guess but is it a must? We used to have this within an ifdef: +#if PIXMAN_VERSION = PIXMAN_VERSION_ENCODE(0, 21, 8) +type = PIXMAN_TYPE_RGBA; +#endif +} That ifdef is still there, we got new PIXMAN_TYPE_RGBA references though. can't we keep system pixman working a bit longer? I'd much prefer to raise the minimum pixman version and ditch the #ifdefs. The common kvm case will work fine without RGBA, you may run into trouble though when emulating bigendian guests on a little endian host (or visa versa), because pixman will have to deal with uncommon pixel formats then. cheers, Gerd
Re: [Qemu-devel] [RFC PATCH 04/17] COLO info: use colo info to tell migration target colo is enabled
在 08/01/2014 10:43 PM, Dr. David Alan Gilbert 写道:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
migrate colo info to migration target to tell the target colo is
enabled.
If I understand this correctly this means that you send a 'colo info' device
information for migrations that don't have COLO enabled; that's bad because
it breaks migration unless the destination has it; I guess it's OK if you
were to guard it with a thing so it didn't do it for old machine-types.
You could use the QEMU_VM_COMMAND sections I've created for postcopy;
( http://lists.gnu.org/archive/html/qemu-devel/2014-07/msg00889.html ) and
add a QEMU_VM_CMD_COLO to indicate you want the destination to become an SVM,
then check the capability near the start of migration and send the command.
Thank you for the reference, I've read part of your Postcopy patches, but
haven't into detailed implementation. I will use QEMUSizedBuffer/QEMUFile in
next version. For QEMU_VM_COMMAND sections, can you separate it out so that I
can make use of it? Do you have a public git tree or something?
Or perhaps there's a way to add the colo-info device on the command line so it's
not always there.
Dave
Signed-off-by: Yang Hongyang yan...@cn.fujitsu.com
---
Makefile.objs | 1 +
include/migration/migration-colo.h | 3 ++
migration-colo-comm.c | 68 ++
vl.c | 4 +++
4 files changed, 76 insertions(+)
create mode 100644 migration-colo-comm.c
diff --git a/Makefile.objs b/Makefile.objs
index cab5824..1836a68 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -50,6 +50,7 @@ common-obj-$(CONFIG_POSIX) += os-posix.o
common-obj-$(CONFIG_LINUX) += fsdev/
common-obj-y += migration.o migration-tcp.o
+common-obj-y += migration-colo-comm.o
common-obj-$(CONFIG_COLO) += migration-colo.o
common-obj-y += vmstate.o
common-obj-y += qemu-file.o
diff --git a/include/migration/migration-colo.h
b/include/migration/migration-colo.h
index 35b384c..e3735d8 100644
--- a/include/migration/migration-colo.h
+++ b/include/migration/migration-colo.h
@@ -12,6 +12,9 @@
#define QEMU_MIGRATION_COLO_H
#include qemu-common.h
+#include migration/migration.h
+
+void colo_info_mig_init(void);
bool colo_supported(void);
diff --git a/migration-colo-comm.c b/migration-colo-comm.c
new file mode 100644
index 000..ccbc246
--- /dev/null
+++ b/migration-colo-comm.c
@@ -0,0 +1,68 @@
+/*
+ * COarse-grain LOck-stepping Virtual Machines for Non-stop Service (COLO)
+ * (a.k.a. Fault Tolerance or Continuous Replication)
+ *
+ * Copyright (C) 2014 FUJITSU LIMITED
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ *
+ */
+
+#include migration/migration-colo.h
+
+#define DEBUG_COLO
+
+#ifdef DEBUG_COLO
+#define DPRINTF(fmt, ...) \
+do { fprintf(stdout, COLO: fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+static bool colo_requested;
+
+/* save */
+
+static bool migrate_use_colo(void)
+{
+MigrationState *s = migrate_get_current();
+return s-enabled_capabilities[MIGRATION_CAPABILITY_COLO];
+}
+
+static void colo_info_save(QEMUFile *f, void *opaque)
+{
+qemu_put_byte(f, migrate_use_colo());
+}
+
+/* restore */
+
+static int colo_info_load(QEMUFile *f, void *opaque, int version_id)
+{
+int value = qemu_get_byte(f);
+
+if (value !colo_supported()) {
+fprintf(stderr, COLO is not supported\n);
+return -EINVAL;
+}
+
+if (value !colo_requested) {
+DPRINTF(COLO requested!\n);
+}
+
+colo_requested = value;
+
+return 0;
+}
+
+static SaveVMHandlers savevm_colo_info_handlers = {
+.save_state = colo_info_save,
+.load_state = colo_info_load,
+};
+
+void colo_info_mig_init(void)
+{
+register_savevm_live(NULL, colo info, -1, 1,
+ savevm_colo_info_handlers, NULL);
+}
diff --git a/vl.c b/vl.c
index fe451aa..1a282d8 100644
--- a/vl.c
+++ b/vl.c
@@ -89,6 +89,7 @@ int main(int argc, char **argv)
#include sysemu/dma.h
#include audio/audio.h
#include migration/migration.h
+#include migration/migration-colo.h
#include sysemu/kvm.h
#include qapi/qmp/qjson.h
#include qemu/option.h
@@ -4339,6 +4340,9 @@ int main(int argc, char **argv, char **envp)
blk_mig_init();
ram_mig_init();
+if (colo_supported()) {
+colo_info_mig_init();
+}
/* open the virtual block devices */
if (snapshot)
--
1.9.1
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
.
--
Thanks,
Yang.
Re: [Qemu-devel] [PATCH 10/23] block: Eliminate DriveInfo member bdrv, use blk_by_legacy_dinfo()
Eric Blake ebl...@redhat.com writes: On 09/11/2014 01:34 PM, Benoît Canet wrote: The Thursday 11 Sep 2014 à 21:12:44 (+0200), Markus Armbruster wrote : Benoît Canet benoit.ca...@irqsave.net writes: + blk_bs(blk_by_legacy_dinfo(dinfo))); This seems to be a fairly common pattern: blk_bs(blk_by_legacy_dinfo()). How about a helper function ? Yes, except the pattern is going to evaporate in patch 14 :) haha Still, worth mentioning this fact in the commit message, rather than making reviewers guess at it (that is, add a sentence something like: This commit mechanically introduces long lines via repetitive pattern replacement that will be shortened in a later patch I can do that.
Re: [Qemu-devel] New requirement for getting block layer patches merged
Benoît Canet benoit.ca...@irqsave.net writes: EOF --- If you have feedback or questions, let us know. The process can be tweaked as time goes on so we can continue to improve. Great mail. Yup. Let's see how it works out. Now we need a wiki entry describing the process. Also we need something reminding who is the maintainer of the current week. Usually obvious from the applied to my tree messages.
Re: [Qemu-devel] [PATCH v8 00/30] modify boot order of guest, and take effect after rebooting
Subject: Re: [Qemu-devel] [PATCH v8 00/30] modify boot order of guest, and take effect after rebooting Am 11.09.2014 um 07:58 schrieb Gonglei (Arei): ./qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -name redhat6.2 -drive \ file=/home/win7_32_2U,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,\ unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive \ file=/home/rhel-server-7.0-x86_64-dvd.iso,if=none,id=drive-ide0-0-1 \ -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=4 \ -vnc 0.0.0.0:10 -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=3,id=nic1 \ -drive file=/mnt/sdb/gonglei/image/virtio-win-1.5.3.vfd,if=none,id=drive-fdc0-0-0,for mat=raw \ -device isa-fdc,driveA=drive-fdc0-0-0,bootindexA=5,id=floppy1 -qmp unix:/tmp/qmp,server,nowait \ -monitor stdio -netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=2,id=nic \ -boot menu=on -device virtio-scsi-pci,id=scsi0 -drive file=/home/suse11_sp3_32,if=none,\ id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native \ -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0- 0-0-0,bootindex=8 QEMU 2.1.50 monitor - type 'help' for more information (qemu) qom-get nic1 bootindex 3 (0x3) (qemu) qom-set nic1 bootindex 3 The bootindex 3 has already been used (qemu) qom-set nic1 bootindex 0 (qemu) qom-set floppy1 bootindexA 3 (qemu) system_reset (qemu) qom-get nic1 bootindex 0 (0x0) (qemu) qom-get scsi0-0-0-0 bootindex 8 (0x8) (qemu) qom-set scsi0-0-0-0 bootindex 0 The bootindex 0 has already been used (qemu) qom-set nic1 bootindex -1 (qemu) qom-set scsi0-0-0-0 bootindex 0 (qemu) qom-get scsi0-0-0-0 bootindex 0 (0x0) (qemu) Hmm..., seems we also need something like this: (qemu) qom-get bootindex dev0 bootindex 0 dev1 bootindex 1 dev2 bootindex 2 ... I don't think so. Qom-get interface is ready-to-wear, we must provide both QOM path and QOM property name. This interface is not added by me. Thanks. :) Yeah, I don't think we need wildcards for qom-get here. I wouldn't oppose a new HMP command though if someone really sees a need. BTW, you can look at with Andreas's patch series: http://thread.gmane.org/gmane.comp.emulators.qemu/271513 which haven't applied in mater tree. Sigh, many things on the to-do list... :( Looking forward to your news about this series. :) Best regards, -Gonglei Regards, 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] OVMF, Q35 and USB keyboard/mouse
Hi, With OVMF, I have EHCI with the high-speed (and working) keyboard+mouse, but ONLY ONE UHCI device (UHCI3). UHCI1 UHCI2 do not get detected. Now *that* is really strange, especially as UHCI1 is pci function 0, without probing that successfully you wouldn't see the other pci functions (1+2+7 for uhci2+uhci3+ehci) in the same slot in the first place. Obviously, since QEMU was routing the slow keyboard+mouse to UHCI1, which for some reason gets masked when OVMF is used, things weren't working. Try '-device usb-mouse,port=5 -device usb-kbd,port=6'. That links mouse +kbd to the ports which are routed to uhci3. Which of course also only papers over the root cause. But should do as workaround for the time being and is also a useful data point. cheers, Gerd
Re: [Qemu-devel] [PATCH 1/2] vl: Fix the confused logic for '-m' option
On 2014/9/12 13:58, zhanghailiang wrote:
It should be valid for the follow configure:
-m 256,slots=0
-m 256,maxmem=256M
-m 256,slots=0,maxmem=256M
-m 256,slots=x,maxmem=y where x 0 and y 256M
Fix the confused code logic and use error_report instead of fprintf.
Printing the maxmem in hex, same with ram_size.
Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
---
vl.c | 46 +++---
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/vl.c b/vl.c
index 9c9acf5..f547405 100644
--- a/vl.c
+++ b/vl.c
@@ -3306,6 +3306,7 @@ int main(int argc, char **argv, char **envp)
break;
case QEMU_OPTION_m: {
uint64_t sz;
+uint64_t slots;
const char *mem_str;
const char *maxmem_str, *slots_str;
@@ -3353,40 +3354,47 @@ int main(int argc, char **argv, char **envp)
maxmem_str = qemu_opt_get(opts, maxmem);
slots_str = qemu_opt_get(opts, slots);
-if (maxmem_str slots_str) {
-uint64_t slots;
-
+if (maxmem_str) {
sz = qemu_opt_get_size(opts, maxmem, 0);
+}
+if (slots_str) {
+slots = qemu_opt_get_number(opts, slots, 0);
+}
+if (maxmem_str slots_str) {
if (sz ram_size) {
-fprintf(stderr, qemu: invalid -m option value:
maxmem
-(% PRIu64 ) = initial memory (
+error_report(qemu: invalid -m option value: maxmem
+(% PRIx64 ) initial memory (
RAM_ADDR_FMT )\n, sz, ram_size);
error_report will add a '\n' automatically. Below lines have the same issue.
exit(EXIT_FAILURE);
}
-
-slots = qemu_opt_get_number(opts, slots, 0);
-if ((sz ram_size) !slots) {
-fprintf(stderr, qemu: invalid -m option value:
maxmem
-(% PRIu64 ) more than initial memory (
+if (!slots (sz != ram_size)) {
+error_report(qemu: invalid -m option value: maxmem
+(% PRIx64 ) more than initial memory (
RAM_ADDR_FMT ) but no hotplug slots where
specified\n, sz, ram_size);
exit(EXIT_FAILURE);
}
-
-if ((sz = ram_size) slots) {
-fprintf(stderr, qemu: invalid -m option value: %
+if (slots (sz == ram_size)) {
+error_report(qemu: invalid -m option value: %
PRIu64 hotplug slots where specified but
-maxmem (% PRIu64 ) = initial memory (
+maxmem (% PRIx64 ) = initial memory (
RAM_ADDR_FMT )\n, slots, sz, ram_size);
exit(EXIT_FAILURE);
}
maxram_size = sz;
ram_slots = slots;
-} else if ((!maxmem_str slots_str) ||
- (maxmem_str !slots_str)) {
-fprintf(stderr, qemu: invalid -m option value: missing
-'%s' option\n, slots_str ? maxmem : slots);
-exit(EXIT_FAILURE);
+} else if (!maxmem_str slots_str) {
+if (slots 0) {
+error_report(qemu: invalid -m option value: missing
+'maxmem' option\n);
+exit(EXIT_FAILURE);
+}
+} else if (maxmem_str !slots_str) {
+if (sz != ram_size) {
+error_report(qemu: invalid -m option value: missing
+'slot' option\n);
+exit(EXIT_FAILURE);
+}
}
break;
}
Re: [Qemu-devel] [PATCH 0/2] Monitor-related fixes
You neglected to cc maintainers. Stratos Psomadakis pso...@grnet.gr writes: Hi, the first patch fixes an issue with HMP monitors, which was exposed with v2.1.0 (commits cdaa86a and 812c10). Copying Luiz. The second one fixes a typo in a helper C program used in qemu-iotests. Copying Kevin and Stefan. We think that they should be cherry-picked for the next stable release. Copying qemu-sta...@nongnu.org.
Re: [Qemu-devel] [PATCH 1/2] monitor: Reset HMP mon-rs on CHR_EVENT_CLOSED
Stratos Psomadakis pso...@grnet.gr writes: Commit cdaa86a54 (Add G_IO_HUP handler for socket chardev) exposed a bug in the way the HMP monitor handles its input. When a client closes the connection to the monitor, tcp_chr_read() will catch the HUP 'signal' and call tcp_chr_disconnect() to close the server-side connection too. Your wording suggests SIGUP, but that's misleading. Suggest tcp_chr_read() will detect the G_IO_HUP condition, and call. Due to the fact that monitor reads 1 byte at a time (for each tcp_chr_read()), the monitor readline state / buffers can be left in an inconsistent state (i.e. a half-finished command). The state is not really inconsistent, there's just junk left in rs-cmd_buf[]. Thus, without calling readline_restart() on mon-rs upon CHR_EVENT_CLOSED, future HMP commands will fail. To make sure I understand you correctly: when you connect again, any leftover junk is prepended to your input, which messes up your first command. Correct? Signed-off-by: Stratos Psomadakis pso...@grnet.gr Signed-off-by: Dimitris Aragiorgis dim...@grnet.gr --- monitor.c |1 + 1 file changed, 1 insertion(+) diff --git a/monitor.c b/monitor.c index 34cee74..7857300 100644 --- a/monitor.c +++ b/monitor.c @@ -5252,6 +5252,7 @@ static void monitor_event(void *opaque, int event) break; case CHR_EVENT_CLOSED: +readline_restart(mon-rs); mon_refcount--; monitor_fdsets_cleanup(); break; Patch looks good to me.
Re: [Qemu-devel] New requirement for getting block layer patches merged
Hi, Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Benoît Canet benoit.ca...@irqsave.net writes: EOF --- If you have feedback or questions, let us know. The process can be tweaked as time goes on so we can continue to improve. Great mail. Yup. Let's see how it works out. Yes. I can't agree more with you. Recently I posted some patch series, but I can't get maintainer's feedback in time. That make me feel soulless TBH. I know maintainers are very busy usually. They need to develop their own code and also need review the contributors' code. If some other peoples can spread the load of patch review, that's a great thing IMHO. Now we need a wiki entry describing the process. Also we need something reminding who is the maintainer of the current week. Usually obvious from the applied to my tree messages. Some exciting words! :) Best regards, -Gonglei
Re: [Qemu-devel] [PATCH 2/2] iotests: Send the correct fd in socket_scm_helper
Stratos Psomadakis pso...@grnet.gr writes:
Make sure to pass the correct fd via SCM_RIGHTS in socket_scm_helper.c
(i.e. fd_to_send, not socket-fd).
Signed-off-by: Stratos Psomadakis pso...@grnet.gr
Signed-off-by: Dimitris Aragiorgis dim...@grnet.gr
---
tests/qemu-iotests/socket_scm_helper.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/socket_scm_helper.c
b/tests/qemu-iotests/socket_scm_helper.c
index 0e2b285..8195983 100644
--- a/tests/qemu-iotests/socket_scm_helper.c
+++ b/tests/qemu-iotests/socket_scm_helper.c
@@ -52,7 +52,7 @@ static int send_fd(int fd, int fd_to_send)
cmsg-cmsg_len = CMSG_LEN(sizeof(int));
cmsg-cmsg_level = SOL_SOCKET;
cmsg-cmsg_type = SCM_RIGHTS;
-memcpy(CMSG_DATA(cmsg), fd, sizeof(int));
+memcpy(CMSG_DATA(cmsg), fd_to_send, sizeof(int));
do {
ret = sendmsg(fd, msg, 0);
Ouch. Do you have an idea what's broken without this fix?
[Qemu-devel] [PATCH] virtio-balloon: Add some trace events
Add some trace events for easier debugging Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com --- hw/virtio/virtio-balloon.c | 6 ++ trace-events | 4 2 files changed, 10 insertions(+) diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c index 2c30b3d..112f97c 100644 --- a/hw/virtio/virtio-balloon.c +++ b/hw/virtio/virtio-balloon.c @@ -25,6 +25,7 @@ #include exec/address-spaces.h #include qapi/visitor.h #include qapi-event.h +#include trace.h #if defined(__linux__) #include sys/mman.h @@ -217,6 +218,8 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq) if (!int128_nz(section.size) || !memory_region_is_ram(section.mr)) continue; +trace_virtio_balloon_handle_output(memory_region_name(section.mr), + pa); /* Using memory_region_get_ram_ptr is bending the rules a bit, but should be OK because we only want a single page. */ addr = section.offset_within_region; @@ -280,6 +283,7 @@ static void virtio_balloon_get_config(VirtIODevice *vdev, uint8_t *config_data) config.num_pages = cpu_to_le32(dev-num_pages); config.actual = cpu_to_le32(dev-actual); +trace_virtio_balloon_get_config(config.num_pages, config.actual); memcpy(config_data, config, sizeof(struct virtio_balloon_config)); } @@ -296,6 +300,7 @@ static void virtio_balloon_set_config(VirtIODevice *vdev, ((ram_addr_t) dev-actual VIRTIO_BALLOON_PFN_SHIFT), error_abort); } +trace_virtio_balloon_set_config(dev-actual, oldactual); } static uint32_t virtio_balloon_get_features(VirtIODevice *vdev, uint32_t f) @@ -323,6 +328,7 @@ static void virtio_balloon_to_target(void *opaque, ram_addr_t target) dev-num_pages = (ram_size - target) VIRTIO_BALLOON_PFN_SHIFT; virtio_notify_config(vdev); } +trace_virtio_balloon_to_target(target, dev-num_pages); } static void virtio_balloon_save(QEMUFile *f, void *opaque) diff --git a/trace-events b/trace-events index fb58963..fedd7e7 100644 --- a/trace-events +++ b/trace-events @@ -143,6 +143,10 @@ cpu_out(unsigned int addr, unsigned int val) addr %#x value %u # balloon.c # Since requests are raised via monitor, not many tracepoints are needed. balloon_event(void *opaque, unsigned long addr) opaque %p addr %lu +virtio_balloon_handle_output(const char *name, uint64_t gpa) setion name: %s gpa: %PRIx64 +virtio_balloon_get_config(uint32_t num_pages, uint32_t acutal) num_pages: %d acutal: %d +virtio_balloon_set_config(uint32_t acutal, uint32_t oldacutal) acutal: %d oldacutal: %d +virtio_balloon_to_target(uint64_t target, uint32_t num_pages) balloon target: %PRIx64 num_pages: %d # hw/intc/apic_common.c cpu_set_apic_base(uint64_t val) %016PRIx64 -- 1.7.12.4
Re: [Qemu-devel] [PATCH 0/2] usb: Don't use qerror_report
arei.gong...@huawei.com writes: From: Gonglei arei.gong...@huawei.com qerror_report() is a transitional interface to help with converting existing HMP commands to QMP. It should not be used elsewhere. Gonglei (2): redirect.c: Don't use qerror_report() dev-network: Don't use qerror_report_err() hw/usb/dev-network.c | 2 +- hw/usb/redirect.c| 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) Thanks for helping with getting rid of qerror.h. Squash in the appended two hunks and you can add my R-by. diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c index 0bf78d8..429ff58 100644 --- a/hw/usb/dev-network.c +++ b/hw/usb/dev-network.c @@ -27,7 +27,7 @@ #include hw/usb.h #include hw/usb/desc.h #include net/net.h -#include qapi/qmp/qerror.h +#include qemu/error-report.h #include qemu/queue.h #include qemu/config-file.h #include sysemu/sysemu.h diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c index e852741..959a43c 100644 --- a/hw/usb/redirect.c +++ b/hw/usb/redirect.c @@ -27,7 +27,7 @@ #include qemu-common.h #include qemu/timer.h -#include monitor/monitor.h +#include qemu/error-report.h #include sysemu/sysemu.h #include qemu/iov.h #include sysemu/char.h
Re: [Qemu-devel] [PATCH 0/2] usb: Don't use qerror_report
From: Markus Armbruster [mailto:arm...@redhat.com] Sent: Friday, September 12, 2014 3:11 PM To: Gonglei (Arei) Cc: qemu-devel@nongnu.org; Huangweidong (C); kra...@redhat.com Subject: Re: [Qemu-devel] [PATCH 0/2] usb: Don't use qerror_report arei.gong...@huawei.com writes: From: Gonglei arei.gong...@huawei.com qerror_report() is a transitional interface to help with converting existing HMP commands to QMP. It should not be used elsewhere. Gonglei (2): redirect.c: Don't use qerror_report() dev-network: Don't use qerror_report_err() hw/usb/dev-network.c | 2 +- hw/usb/redirect.c| 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) Thanks for helping with getting rid of qerror.h. Squash in the appended two hunks and you can add my R-by. Got it. Thanks! Best regards, -Gonglei diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c index 0bf78d8..429ff58 100644 --- a/hw/usb/dev-network.c +++ b/hw/usb/dev-network.c @@ -27,7 +27,7 @@ #include hw/usb.h #include hw/usb/desc.h #include net/net.h -#include qapi/qmp/qerror.h +#include qemu/error-report.h #include qemu/queue.h #include qemu/config-file.h #include sysemu/sysemu.h diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c index e852741..959a43c 100644 --- a/hw/usb/redirect.c +++ b/hw/usb/redirect.c @@ -27,7 +27,7 @@ #include qemu-common.h #include qemu/timer.h -#include monitor/monitor.h +#include qemu/error-report.h #include sysemu/sysemu.h #include qemu/iov.h #include sysemu/char.h
[Qemu-devel] [PATCH v2 1/2] redirect.c: Don't use qerror_report()
From: Gonglei arei.gong...@huawei.com
qerror_report() is a transitional interface to help with converting
existing HMP commands to QMP. It should not be used elsewhere.
Replace by error_report().
Signed-off-by: Gonglei arei.gong...@huawei.com
Reviewed-by: Markus Armbruster arm...@redhat.com
---
hw/usb/redirect.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 44522d9..959a43c 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -27,7 +27,7 @@
#include qemu-common.h
#include qemu/timer.h
-#include monitor/monitor.h
+#include qemu/error-report.h
#include sysemu/sysemu.h
#include qemu/iov.h
#include sysemu/char.h
@@ -1363,7 +1363,7 @@ static int usbredir_initfn(USBDevice *udev)
int i;
if (dev-cs == NULL) {
-qerror_report(QERR_MISSING_PARAMETER, chardev);
+error_report(Parameter 'chardev' is missing);
return -1;
}
@@ -1372,8 +1372,8 @@ static int usbredir_initfn(USBDevice *udev)
dev-filter_rules,
dev-filter_rules_count);
if (i) {
-qerror_report(QERR_INVALID_PARAMETER_VALUE, filter,
- a usb device filter string);
+error_report(Parameter 'filter' expects
+ a usb device filter string);
return -1;
}
}
--
1.7.12.4
[Qemu-devel] [PATCH v2 0/2] usb: Don't use qerror_report
From: Gonglei arei.gong...@huawei.com qerror_report() is a transitional interface to help with converting existing HMP commands to QMP. It should not be used elsewhere. v2 - v1: - update including head files, remove qerror.h and monitor.h, add error-report.h (Markus) - add 'Reviewed-by' tag. Gonglei (2): redirect.c: Don't use qerror_report() dev-network: Don't use qerror_report_err() hw/usb/dev-network.c | 4 ++-- hw/usb/redirect.c| 8 2 files changed, 6 insertions(+), 6 deletions(-) -- 1.7.12.4
[Qemu-devel] [PATCH v2 2/2] dev-network: Don't use qerror_report_err()
From: Gonglei arei.gong...@huawei.com
qerror_report_err() is a transitional interface to help with
converting existing HMP commands to QMP. It should not be used
elsewhere.
Signed-off-by: Gonglei arei.gong...@huawei.com
Reviewed-by: Markus Armbruster arm...@redhat.com
---
hw/usb/dev-network.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 518d536..429ff58 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -27,7 +27,7 @@
#include hw/usb.h
#include hw/usb/desc.h
#include net/net.h
-#include qapi/qmp/qerror.h
+#include qemu/error-report.h
#include qemu/queue.h
#include qemu/config-file.h
#include sysemu/sysemu.h
@@ -1392,7 +1392,7 @@ static USBDevice *usb_net_init(USBBus *bus, const char
*cmdline)
idx = net_client_init(opts, 0, local_err);
if (local_err) {
-qerror_report_err(local_err);
+error_report(%s, error_get_pretty(local_err));
error_free(local_err);
return NULL;
}
--
1.7.12.4
[Qemu-devel] [RFC PATCH v3] Add HMP command info memory-devices
Provides HMP equivalent of QMP query-memory-devices command.
Signed-off-by: Zhu Guihua zhugh.f...@cn.fujitsu.com
---
Changes since v2:
- print address in hex.
- change the loop control from while to for.
- modify some variables' name.
- optimize the time to print memory devices' kind.
Changes since v1:
- fix bug that accessing info-dimm when MemoryDeviceInfo is not PCDIMMDevice.
- use enum to replace dimm, and lookup typename in
MemoryDeviceInfoKind_lookup[] instead of opencodding it.
hmp-commands.hx | 2 ++
hmp.c | 41 +
hmp.h | 1 +
monitor.c | 7 +++
4 files changed, 51 insertions(+)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index f859f8d..0b1a4f7 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1778,6 +1778,8 @@ show qdev device model list
show roms
@item info tpm
show the TPM device
+@item info memory-devices
+show the memory devices
@end table
ETEXI
diff --git a/hmp.c b/hmp.c
index 40a90da..bbeb8be 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1718,3 +1718,44 @@ void hmp_info_memdev(Monitor *mon, const QDict *qdict)
qapi_free_MemdevList(memdev_list);
}
+
+void hmp_info_memory_devices(Monitor *mon, const QDict *qdict)
+{
+Error *err = NULL;
+MemoryDeviceInfoList *info_list = qmp_query_memory_devices(err);
+MemoryDeviceInfoList *info;
+MemoryDeviceInfo *value;
+PCDIMMDeviceInfo *di;
+int i = 0;
+
+for (info = info_list; info; info = info-next) {
+value = info-value;
+
+if (value) {
+monitor_printf(mon, Memory device %d\n, i++);
+monitor_printf(mon, %s\n,
+ MemoryDeviceInfoKind_lookup[value-kind]);
+
+switch (value-kind) {
+case MEMORY_DEVICE_INFO_KIND_DIMM:
+di = value-dimm;
+
+monitor_printf(mon, id: %s\n, di-id);
+monitor_printf(mon, addr: 0x%lx\n, di-addr);
+monitor_printf(mon, slot: % PRId64 \n, di-slot);
+monitor_printf(mon, node: % PRId64 \n, di-node);
+monitor_printf(mon, size: % PRId64 \n, di-size);
+monitor_printf(mon, memdev: %s\n, di-memdev);
+monitor_printf(mon, hotplugged: %s\n,
+ di-hotplugged ? true : false);
+monitor_printf(mon, hotpluggable: %s\n,
+ di-hotpluggable ? true : false);
+break;
+default:
+break;
+}
+}
+}
+
+qapi_free_MemoryDeviceInfoList(info_list);
+}
diff --git a/hmp.h b/hmp.h
index 4fd3c4a..4bb5dca 100644
--- a/hmp.h
+++ b/hmp.h
@@ -94,6 +94,7 @@ void hmp_cpu_add(Monitor *mon, const QDict *qdict);
void hmp_object_add(Monitor *mon, const QDict *qdict);
void hmp_object_del(Monitor *mon, const QDict *qdict);
void hmp_info_memdev(Monitor *mon, const QDict *qdict);
+void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
void object_add_completion(ReadLineState *rs, int nb_args, const char *str);
void object_del_completion(ReadLineState *rs, int nb_args, const char *str);
void device_add_completion(ReadLineState *rs, int nb_args, const char *str);
diff --git a/monitor.c b/monitor.c
index 34cee74..fe88e0d 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2921,6 +2921,13 @@ static mon_cmd_t info_cmds[] = {
.mhandler.cmd = hmp_info_memdev,
},
{
+.name = memory-devices,
+.args_type = ,
+.params = ,
+.help = show memory devices,
+.mhandler.cmd = hmp_info_memory_devices,
+},
+{
.name = NULL,
},
};
--
1.9.3
Re: [Qemu-devel] [RFC V2 10/10] cpus: reclaim allocated vCPU objects
On Fri, Sep 12, 2014 at 6:54 AM, Gu Zheng guz.f...@cn.fujitsu.com wrote: Is guest os enabled acpi cpu hotplug? What's the guest's cpu info? Please try latest QEMU, and any feedback is welcome. Tried with latest QEMU git + your patchset and Fedora 20 guest, but QEMU monitor still shows the removed CPU. Guest kernel messages during hotplug: [root@localhost cpu]# echo 1 cpu8/online [ 72.936069] smpboot: Booting Node 0 Processor 8 APIC 0x8 [0.003000] kvm-clock: cpu 8, msr 0:7ffc9201, secondary cpu clock [ 72.950003] TSC synchronization [CPU#0 - CPU#8]: [ 72.950003] Measured 199886723309 cycles TSC warp between CPUs, turning off TSC clock. [ 72.950003] tsc: Marking TSC unstable due to check_tsc_sync_source failed [ 72.972976] KVM setup async PF for cpu 8 [ 72.973648] kvm-stealtime: cpu 8, msr 7d30df00 [ 72.974415] Will online and init hotplugged CPU: 8 [ 72.975307] microcode: CPU8 sig=0x663, pf=0x1, revision=0x1 Guest kernel messages during hotunplug: [root@localhost cpu]# [ 95.482172] Unregister pv shared memory for cpu 8 [ 95.487169] smpboot: CPU 8 is now offline [ 95.488667] ACPI: Device does not support D3cold Guest cpuinfo (showing for the last CPU only after adding and removing CPU 8) processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 6 model name: QEMU Virtual CPU version 2.1.50 stepping: 3 microcode: 0x1 cpu MHz: 2899.998 cache size: 4096 KB fpu: yes fpu_exception: yes cpuid level: 4 wp: yes flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni cx16 x2apic popcnt hypervisor lahf_lm bogomips: 5799.99 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: [root@localhost boot]# grep -ir hot config-3.11.10-301.fc20.x86_64 CONFIG_TICK_ONESHOT=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_HOTPLUG_CPU=y # CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set # CONFIG_DEBUG_HOTPLUG_CPU0 is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_HOTPLUG_PCI_ACPI_IBM=m # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_SHPC=m
Re: [Qemu-devel] New requirement for getting block layer patches merged
Am 12.09.2014 um 09:02 hat Gonglei (Arei) geschrieben: Hi, Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Benoît Canet benoit.ca...@irqsave.net writes: EOF --- If you have feedback or questions, let us know. The process can be tweaked as time goes on so we can continue to improve. Great mail. Yup. Let's see how it works out. Yes. I can't agree more with you. Recently I posted some patch series, but I can't get maintainer's feedback in time. That make me feel soulless TBH. I know maintainers are very busy usually. They need to develop their own code and also need review the contributors' code. If some other peoples can spread the load of patch review, that's a great thing IMHO. This is what Stefan's mail was actually for in some way: Letting you know that you should get a Reviewed-by first. At least for me, to be honest, this isn't a truly new process. I haven't been consistently requiring a Reviewed-by, but when I see someone else discuss a patch series and I don't have much time, I may scan the discussion to chime in if there is something fundamentally wrong, but otherwise let the author and the reviewer sort it out and wait until the discussion has settled. If I don't see a discussion, I might wait a few days for one. I'll probably keep reviewing paches without an R-b when they are simple or in my area of expertise (like qcow2), like any other reviewer should. The point is just that when I don't, before you ping us maintainers about a patch, try to get a good review from some other contributor. Now we need a wiki entry describing the process. Also we need something reminding who is the maintainer of the current week. Usually obvious from the applied to my tree messages. You should CC both of us anyway (the patch might not be merged in the same week), so it doesn't matter that much who'll be handling it. Kevin
Re: [Qemu-devel] [TRIVIAL][PATCH v2] libqos virtio: Increase ISR timeout
On Thu, Sep 11, 2014 at 11:40:16AM +0200, Marc Marí wrote: Increase the clock step to avoid Travis failure in some builds due to overagressive timeout. Signed-off-by: Marc Marí marc.mari.barc...@gmail.com --- tests/libqos/virtio.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@redhat.com pgpuol4O48fvh.pgp Description: PGP signature
Re: [Qemu-devel] [TRIVIAL][PATCH v2] libqos virtio: Increase ISR timeout
On 12 September 2014 09:27, Stefan Hajnoczi stefa...@redhat.com wrote: On Thu, Sep 11, 2014 at 11:40:16AM +0200, Marc Marí wrote: Increase the clock step to avoid Travis failure in some builds due to overagressive timeout. Signed-off-by: Marc Marí marc.mari.barc...@gmail.com --- tests/libqos/virtio.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@redhat.com Do you mind if I apply this directly to master to stop travis grumbling at us on irc? thanks -- PMM
Re: [Qemu-devel] [PATCH 2/2] iotests: Send the correct fd in socket_scm_helper
Am 12.09.2014 um 09:04 hat Markus Armbruster geschrieben:
Stratos Psomadakis pso...@grnet.gr writes:
Make sure to pass the correct fd via SCM_RIGHTS in socket_scm_helper.c
(i.e. fd_to_send, not socket-fd).
Signed-off-by: Stratos Psomadakis pso...@grnet.gr
Signed-off-by: Dimitris Aragiorgis dim...@grnet.gr
Thanks, applied to the block branch.
(Also thanks to Markus for copying me, would have missed the patch
otherwise.)
tests/qemu-iotests/socket_scm_helper.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/socket_scm_helper.c
b/tests/qemu-iotests/socket_scm_helper.c
index 0e2b285..8195983 100644
--- a/tests/qemu-iotests/socket_scm_helper.c
+++ b/tests/qemu-iotests/socket_scm_helper.c
@@ -52,7 +52,7 @@ static int send_fd(int fd, int fd_to_send)
cmsg-cmsg_len = CMSG_LEN(sizeof(int));
cmsg-cmsg_level = SOL_SOCKET;
cmsg-cmsg_type = SCM_RIGHTS;
-memcpy(CMSG_DATA(cmsg), fd, sizeof(int));
+memcpy(CMSG_DATA(cmsg), fd_to_send, sizeof(int));
do {
ret = sendmsg(fd, msg, 0);
Ouch. Do you have an idea what's broken without this fix?
As far as I can tell, nothing. Test case 045 will send a different file
descriptor than it intended to, but the file descriptors aren't used
other than checking whether qemu correctly reports their existence, so
it doesn't matter.
I'm not adding qemu-stable therefore. Please correct me if I'm missing
something.
Kevin
Re: [Qemu-devel] New requirement for getting block layer patches merged
From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Friday, September 12, 2014 4:14 PM Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Am 12.09.2014 um 09:02 hat Gonglei (Arei) geschrieben: Hi, Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Benoît Canet benoit.ca...@irqsave.net writes: EOF --- If you have feedback or questions, let us know. The process can be tweaked as time goes on so we can continue to improve. Great mail. Yup. Let's see how it works out. Yes. I can't agree more with you. Recently I posted some patch series, but I can't get maintainer's feedback in time. That make me feel soulless TBH. I know maintainers are very busy usually. They need to develop their own code and also need review the contributors' code. If some other peoples can spread the load of patch review, that's a great thing IMHO. This is what Stefan's mail was actually for in some way: Letting you know that you should get a Reviewed-by first. At least for me, to be honest, this isn't a truly new process. I haven't been consistently requiring a Reviewed-by, but when I see someone else discuss a patch series and I don't have much time, I may scan the discussion to chime in if there is something fundamentally wrong, but otherwise let the author and the reviewer sort it out and wait until the discussion has settled. If I don't see a discussion, I might wait a few days for one. Good method. :) I'll probably keep reviewing paches without an R-b when they are simple or in my area of expertise (like qcow2), like any other reviewer should. The point is just that when I don't, before you ping us maintainers about a patch, try to get a good review from some other contributor. But there's a problem that a patch may have not get a review from other contributors in some areas, maybe only few people worked on it. After a few weeks, maintainers can give some response to author if the author is pinging...? Best regards, -Gonglei Now we need a wiki entry describing the process. Also we need something reminding who is the maintainer of the current week. Usually obvious from the applied to my tree messages. You should CC both of us anyway (the patch might not be merged in the same week), so it doesn't matter that much who'll be handling it. Kevin
Re: [Qemu-devel] [PATCH v2 0/2] usb: Don't use qerror_report
Il 12/09/2014 09:30, arei.gong...@huawei.com ha scritto: From: Gonglei arei.gong...@huawei.com qerror_report() is a transitional interface to help with converting existing HMP commands to QMP. It should not be used elsewhere. v2 - v1: - update including head files, remove qerror.h and monitor.h, add error-report.h (Markus) - add 'Reviewed-by' tag. Gonglei (2): redirect.c: Don't use qerror_report() dev-network: Don't use qerror_report_err() hw/usb/dev-network.c | 4 ++-- hw/usb/redirect.c| 8 2 files changed, 6 insertions(+), 6 deletions(-) This is not an improvement I think; patch 1 especially for patch 2 where you are discarding the Error *. Any chance you could convert USB from init to realize, instead? Then you can remove the error printing altogether, and just the obsolete functions. Paolo
Re: [Qemu-devel] New requirement for getting block layer patches merged
Am 12.09.2014 um 10:32 hat Gonglei (Arei) geschrieben: From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Friday, September 12, 2014 4:14 PM Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Am 12.09.2014 um 09:02 hat Gonglei (Arei) geschrieben: Hi, Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Benoît Canet benoit.ca...@irqsave.net writes: EOF --- If you have feedback or questions, let us know. The process can be tweaked as time goes on so we can continue to improve. Great mail. Yup. Let's see how it works out. Yes. I can't agree more with you. Recently I posted some patch series, but I can't get maintainer's feedback in time. That make me feel soulless TBH. I know maintainers are very busy usually. They need to develop their own code and also need review the contributors' code. If some other peoples can spread the load of patch review, that's a great thing IMHO. This is what Stefan's mail was actually for in some way: Letting you know that you should get a Reviewed-by first. At least for me, to be honest, this isn't a truly new process. I haven't been consistently requiring a Reviewed-by, but when I see someone else discuss a patch series and I don't have much time, I may scan the discussion to chime in if there is something fundamentally wrong, but otherwise let the author and the reviewer sort it out and wait until the discussion has settled. If I don't see a discussion, I might wait a few days for one. Good method. :) I'll probably keep reviewing paches without an R-b when they are simple or in my area of expertise (like qcow2), like any other reviewer should. The point is just that when I don't, before you ping us maintainers about a patch, try to get a good review from some other contributor. But there's a problem that a patch may have not get a review from other contributors in some areas, maybe only few people worked on it. After a few weeks, maintainers can give some response to author if the author is pinging...? If you try and still fail to get review after a few weeks, sure, talk to us and we'll find a solution. But keep in mind that if only few people have worked on the code, Stefan and I probably haven't either. So automatically delegating all such cases for us to review isn't going to be helpful, because reviewing patches to code that you don't know is one of the most time consuming activities. Spreading them over more contributors is the goal of this change. Kevin
Re: [Qemu-devel] [PATCH v2 0/2] usb: Don't use qerror_report
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Friday, September 12, 2014 4:35 PM To: Gonglei (Arei); qemu-devel@nongnu.org Cc: Huangweidong (C); kra...@redhat.com; arm...@redhat.com Subject: Re: [PATCH v2 0/2] usb: Don't use qerror_report Il 12/09/2014 09:30, arei.gong...@huawei.com ha scritto: From: Gonglei arei.gong...@huawei.com qerror_report() is a transitional interface to help with converting existing HMP commands to QMP. It should not be used elsewhere. v2 - v1: - update including head files, remove qerror.h and monitor.h, add error-report.h (Markus) - add 'Reviewed-by' tag. Gonglei (2): redirect.c: Don't use qerror_report() dev-network: Don't use qerror_report_err() hw/usb/dev-network.c | 4 ++-- hw/usb/redirect.c| 8 2 files changed, 6 insertions(+), 6 deletions(-) This is not an improvement I think; patch 1 especially for patch 2 where you are discarding the Error *. Any chance you could convert USB from init to realize, instead? Then you can remove the error printing altogether, and just the obsolete functions. As far as I can tell, almost all devices belong to USB sub-system are using init method. It may be a big surgery if change all those devices from init to realize. :) Best regards, -Gonglei
Re: [Qemu-devel] New requirement for getting block layer patches merged
From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Friday, September 12, 2014 4:46 PM To: Gonglei (Arei) Cc: Markus Armbruster; Benoît Canet; qemu-devel@nongnu.org; Stefan Hajnoczi Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Am 12.09.2014 um 10:32 hat Gonglei (Arei) geschrieben: From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Friday, September 12, 2014 4:14 PM Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Am 12.09.2014 um 09:02 hat Gonglei (Arei) geschrieben: Hi, Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Benoît Canet benoit.ca...@irqsave.net writes: EOF --- If you have feedback or questions, let us know. The process can be tweaked as time goes on so we can continue to improve. Great mail. Yup. Let's see how it works out. Yes. I can't agree more with you. Recently I posted some patch series, but I can't get maintainer's feedback in time. That make me feel soulless TBH. I know maintainers are very busy usually. They need to develop their own code and also need review the contributors' code. If some other peoples can spread the load of patch review, that's a great thing IMHO. This is what Stefan's mail was actually for in some way: Letting you know that you should get a Reviewed-by first. At least for me, to be honest, this isn't a truly new process. I haven't been consistently requiring a Reviewed-by, but when I see someone else discuss a patch series and I don't have much time, I may scan the discussion to chime in if there is something fundamentally wrong, but otherwise let the author and the reviewer sort it out and wait until the discussion has settled. If I don't see a discussion, I might wait a few days for one. Good method. :) I'll probably keep reviewing paches without an R-b when they are simple or in my area of expertise (like qcow2), like any other reviewer should. The point is just that when I don't, before you ping us maintainers about a patch, try to get a good review from some other contributor. But there's a problem that a patch may have not get a review from other contributors in some areas, maybe only few people worked on it. After a few weeks, maintainers can give some response to author if the author is pinging...? If you try and still fail to get review after a few weeks, sure, talk to us and we'll find a solution. OK. But keep in mind that if only few people have worked on the code, Stefan and I probably haven't either. So automatically delegating all such cases for us to review isn't going to be helpful, because reviewing patches to code that you don't know is one of the most time consuming activities. Spreading them over more contributors is the goal of this change. Understand. Thanks for your patient answer! I think it is helpful for other contributors too. :) Best regards, -Gonglei
[Qemu-devel] [PATCH] ohci: Convert fprint/DPRINTF/print to traces
This converts many kinds of debug prints to traces.
This implements packets logging to avoid unnecessary calculations if
usb_ohci_td_pkt_short/usb_ohci_td_pkt_long is not enabled.
This makes OHCI errors (such as DMA error) invisible by default.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
First I wanted to hide DMA error and OHCI die but then decided do to
some housecleaning + community work :)
I could have chosen wrong names for some traces, please comment. Thanks!
---
hw/usb/hcd-ohci.c | 214 +++---
trace-events | 56 ++
2 files changed, 148 insertions(+), 122 deletions(-)
diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
index 83bec34..4a4dd02 100644
--- a/hw/usb/hcd-ohci.c
+++ b/hw/usb/hcd-ohci.c
@@ -31,20 +31,11 @@
#include hw/pci/pci.h
#include hw/sysbus.h
#include hw/qdev-dma.h
+#include trace.h
-//#define DEBUG_OHCI
-/* Dump packet contents. */
-//#define DEBUG_PACKET
-//#define DEBUG_ISOCH
/* This causes frames to occur 1000x slower */
//#define OHCI_TIME_WARP 1
-#ifdef DEBUG_OHCI
-#define DPRINTF printf
-#else
-#define DPRINTF(...)
-#endif
-
/* Number of Downstream Ports on the root hub. */
#define OHCI_MAX_PORTS 15
@@ -350,7 +341,7 @@ static void ohci_attach(USBPort *port1)
ohci_set_interrupt(s, OHCI_INTR_RD);
}
-DPRINTF(usb-ohci: Attached port %d\n, port1-index);
+trace_usb_ohci_port_attach(port1-index);
if (old_state != port-ctrl) {
ohci_set_interrupt(s, OHCI_INTR_RHSC);
@@ -375,7 +366,7 @@ static void ohci_detach(USBPort *port1)
port-ctrl = ~OHCI_PORT_PES;
port-ctrl |= OHCI_PORT_PESC;
}
-DPRINTF(usb-ohci: Detached port %d\n, port1-index);
+trace_usb_ohci_port_detach(port1-index);
if (old_state != port-ctrl) {
ohci_set_interrupt(s, OHCI_INTR_RHSC);
@@ -388,14 +379,14 @@ static void ohci_wakeup(USBPort *port1)
OHCIPort *port = s-rhport[port1-index];
uint32_t intr = 0;
if (port-ctrl OHCI_PORT_PSS) {
-DPRINTF(usb-ohci: port %d: wakeup\n, port1-index);
+trace_usb_ohci_port_wakeup(port1-index);
port-ctrl |= OHCI_PORT_PSSC;
port-ctrl = ~OHCI_PORT_PSS;
intr = OHCI_INTR_RHSC;
}
/* Note that the controller can be suspended even if this port is not */
if ((s-ctl OHCI_CTL_HCFS) == OHCI_USB_SUSPEND) {
-DPRINTF(usb-ohci: remote-wakeup: SUSPEND-RESUME\n);
+trace_usb_ohci_remote_wakeup(s-name);
/* This is the one state transition the controller can do by itself */
s-ctl = ~OHCI_CTL_HCFS;
s-ctl |= OHCI_USB_RESUME;
@@ -497,7 +488,7 @@ static void ohci_reset(void *opaque)
ohci-async_td = 0;
}
ohci_stop_endpoints(ohci);
-DPRINTF(usb-ohci: Reset %s\n, ohci-name);
+trace_usb_ohci_reset(ohci-name);
}
/* Get an array of dwords from main memory */
@@ -690,9 +681,8 @@ static void ohci_process_lists(OHCIState *ohci, int
completion);
static void ohci_async_complete_packet(USBPort *port, USBPacket *packet)
{
OHCIState *ohci = container_of(packet, OHCIState, usb_packet);
-#ifdef DEBUG_PACKET
-DPRINTF(Async packet complete\n);
-#endif
+
+trace_usb_ohci_async_complete();
ohci-async_complete = true;
ohci_process_lists(ohci, 1);
}
@@ -704,9 +694,7 @@ static int ohci_service_iso_td(OHCIState *ohci, struct
ohci_ed *ed,
{
int dir;
size_t len = 0;
-#ifdef DEBUG_ISOCH
const char *str = NULL;
-#endif
int pid;
int ret;
int i;
@@ -723,7 +711,7 @@ static int ohci_service_iso_td(OHCIState *ohci, struct
ohci_ed *ed,
addr = ed-head OHCI_DPTR_MASK;
if (ohci_read_iso_td(ohci, addr, iso_td)) {
-printf(usb-ohci: ISO_TD read error at %x\n, addr);
+trace_usb_ohci_iso_td_read_failed(addr);
ohci_die(ohci);
return 0;
}
@@ -732,14 +720,7 @@ static int ohci_service_iso_td(OHCIState *ohci, struct
ohci_ed *ed,
frame_count = OHCI_BM(iso_td.flags, TD_FC);
relative_frame_number = USUB(ohci-frame_number, starting_frame);
-#ifdef DEBUG_ISOCH
-printf(--- ISO_TD ED head 0x%.8x tailp 0x%.8x\n
- 0x%.8x 0x%.8x 0x%.8x 0x%.8x\n
- 0x%.8x 0x%.8x 0x%.8x 0x%.8x\n
- 0x%.8x 0x%.8x 0x%.8x 0x%.8x\n
- frame_number 0x%.8x starting_frame 0x%.8x\n
- frame_count 0x%.8x relative %d\n
- di 0x%.8x cc 0x%.8x\n,
+trace_usb_ohci_iso_td_head(
ed-head OHCI_DPTR_MASK, ed-tail OHCI_DPTR_MASK,
iso_td.flags, iso_td.bp, iso_td.next, iso_td.be,
iso_td.offset[0], iso_td.offset[1], iso_td.offset[2],
iso_td.offset[3],
@@ -747,16 +728,15 @@ static int ohci_service_iso_td(OHCIState *ohci, struct
ohci_ed *ed,
ohci-frame_number, starting_frame,
frame_count, relative_frame_number,
OHCI_BM(iso_td.flags, TD_DI), OHCI_BM(iso_td.flags, TD_CC));
-#endif
if (relative_frame_number 0) {
-
[Qemu-devel] qemu-img: unable to convert raw image 2GB with git master
Hi all, I've been trying to convert a raw disk partition from my laptop for use on VMWare player and I'm seeing the following error from qemu-img git master during conversion: # qemu-img convert -f raw -O vmdk /dev/mapper/vm-raw out.vmdk qemu-img: error while writing sector 4247552: Invalid argument A quick glance at the resulting output file makes me thing that an artificial 2GB limit has accidentally been introduced: # ls -l | grep out.vmdk -rw-r--r-- 1 root root 2147483648 Sep 12 09:49 out.vmdk Can anyone else reproduce this? The input /dev/mapper/vm-raw is simply a raw 4GB LVM partition on my local disk which is mapped through as a standard hard disk into QEMU. Many thanks, Mark.
Re: [Qemu-devel] [PATCH v2 0/2] usb: Don't use qerror_report
Il 12/09/2014 10:50, Gonglei (Arei) ha scritto: Any chance you could convert USB from init to realize, instead? Then you can remove the error printing altogether, and just the obsolete functions. As far as I can tell, almost all devices belong to USB sub-system are using init method. It may be a big surgery if change all those devices from init to realize. :) Yes, that would have to be done in the whole USB subsystem. I understand that you don't feel like doing that. :) Paolo
Re: [Qemu-devel] New requirement for getting block layer patches merged
Gonglei (Arei) arei.gong...@huawei.com writes: From: Kevin Wolf [mailto:kw...@redhat.com] [...] I'll probably keep reviewing paches without an R-b when they are simple or in my area of expertise (like qcow2), like any other reviewer should. The point is just that when I don't, before you ping us maintainers about a patch, try to get a good review from some other contributor. But there's a problem that a patch may have not get a review from other contributors in some areas, maybe only few people worked on it. After a few weeks, maintainers can give some response to author if the author is pinging...? If you're having difficulties getting a satisfactory review, and you don't know whom to ask for one, then asking for help is fair. I'd ask the list, cc'ing my best guess at who could be willing to help with finding reviewers. The guess generally include maintainers. [...]
Re: [Qemu-devel] New requirement for getting block layer patches merged
From: Markus Armbruster [mailto:arm...@redhat.com] Sent: Friday, September 12, 2014 5:02 PM To: Gonglei (Arei) Cc: Kevin Wolf; Benoît Canet; Stefan Hajnoczi; qemu-devel@nongnu.org Subject: Re: [Qemu-devel] New requirement for getting block layer patches merged Gonglei (Arei) arei.gong...@huawei.com writes: From: Kevin Wolf [mailto:kw...@redhat.com] [...] I'll probably keep reviewing paches without an R-b when they are simple or in my area of expertise (like qcow2), like any other reviewer should. The point is just that when I don't, before you ping us maintainers about a patch, try to get a good review from some other contributor. But there's a problem that a patch may have not get a review from other contributors in some areas, maybe only few people worked on it. After a few weeks, maintainers can give some response to author if the author is pinging...? If you're having difficulties getting a satisfactory review, and you don't know whom to ask for one, then asking for help is fair. I'd ask the list, cc'ing my best guess at who could be willing to help with finding reviewers. The guess generally include maintainers. Yes. Indeed! Best regards, -Gonglei
Re: [Qemu-devel] [PATCH v2 0/2] usb: Don't use qerror_report
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini Sent: Friday, September 12, 2014 4:59 PM Subject: Re: [PATCH v2 0/2] usb: Don't use qerror_report Il 12/09/2014 10:50, Gonglei (Arei) ha scritto: Any chance you could convert USB from init to realize, instead? Then you can remove the error printing altogether, and just the obsolete functions. As far as I can tell, almost all devices belong to USB sub-system are using init method. It may be a big surgery if change all those devices from init to realize. :) Yes, that would have to be done in the whole USB subsystem. I understand that you don't feel like doing that. :) Haw-haw, maybe Gerd has a plan in the future... Best regards, -Gonglei
Re: [Qemu-devel] [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt
On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt new file mode 100644 index 000..9455383 --- /dev/null +++ b/docs/specs/virtio-gpu.txt @@ -0,0 +1,165 @@ +virtio-gpu specification + This document refers to the implementation for structs and does not fully document the semantics of the virtqueue commands. Mixing the implementation and specification is risky since implementation changes cannot be checked against the specification. In order to make this document self-contained you need to define the struct layouts. Error conditions and corner cases are not documented for the virtqueue commands. I've asked about a few of them below, but there more are required to make this specification complete enough so someone else could write a compatible implementation. +drive virtio-gpu in 2D mode +--- + +The virtio-gpu is based around the concept of resources private to the +host, the guest must DMA transfer into these resources. This is a +design requirement in order to interface with future 3D rendering. In +the unaccelerated there is no support for DMA transfers from the unaccelerated case? +VIRTGPU_CMD_RESOURCE_CREATE_2D: + Command: struct virtgpu_resource_create_2d + + Create a 2D resource on the host. + + This creates a 2D resource on the host with the specified width, + height and format. Only a small subset of formats are support. The + resource ids are generated by the guest. Can the host refuse due to lack of resources? +VIRTGPU_CMD_SET_SCANOUT: + Command: struct virtgpu_set_scanout + + Set the scanout parameters for a single output. + + This sets the scanout parameters for a single scanout. The + resource_id is the resource to be scanned out from, along with a + rectangle specified by x, y, width and height. What if x, y, width, and height are out-of-range for the given resource? What if width and height exceed the scanout width and height? Is it possible to unset the scanout for a resource? Can a resource be set on multiple scanouts? Does VIRTGPU_CMD_SET_SCANOUT need to be called between every VIRTGPU_CMD_RESOURCE_FLUSH or is does the assignment persist? +VIRTGPU_CMD_RESOURCE_ATTACH_BACKING: + Command: struct virtgpu_resource_attach_backing + + Assign backing pages to a resource. + + This assign an array of guest pages (struct virtgpu_mem_entry) as assigns + the backing store for a resource. These pages are then used for the + transfer operations for that resource from that point on. + +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: + Command: struct virtgpu_resource_inval_backing Why is it called INVAL_BACKING instead of DETACH_BACKING? Detach is logical since there is also an attach command. pgpZkyqghIdCB.pgp Description: PGP signature
Re: [Qemu-devel] New requirement for getting block layer patches merged
On Fri, Sep 12, 2014 at 10:14:01AM +0200, Kevin Wolf wrote: Am 12.09.2014 um 09:02 hat Gonglei (Arei) geschrieben: Now we need a wiki entry describing the process. Also we need something reminding who is the maintainer of the current week. Usually obvious from the applied to my tree messages. You should CC both of us anyway (the patch might not be merged in the same week), so it doesn't matter that much who'll be handling it. This is also what the get_maintainer.pl script says: $ scripts/get_maintainer.pl -f block.c Kevin Wolf kw...@redhat.com (supporter:Block) Stefan Hajnoczi stefa...@redhat.com (supporter:Block) Please CC both of us. Stefan pgpYuTivXsTA1.pgp Description: PGP signature
[Qemu-devel] [PATCH V2 0/7] cpu/acpi: convert cpu hot plug to hotplug_handler API
Previously we use cpu_added_notifiers to register cpu hotplug notifier callback which is not able to pass/handle errors, so we switch it to unified hotplug handler API which allows to pass errors and would allow to cancel device_add in case of error. Thanks very much for Igor's review and suggestion. v2: -Add 3 new patches(5/7,6/7,7/7), delete original patch 5/5. 1/5--1/7 2/5--2/7 3/5--3/7 4/5--4/7 Patch 1/7: -add errp argument to catch error. -return error instead of aborting if cpu id is invalid. -make acpi_cpu_plug_cb as a wrapper around AcpiCpuHotplug_add. Patch 3/7: -remove unused AcpiCpuHotplug_add here directly. Patch 5/7: -switch the last user of cpu hotplug notifier to hotplug handler API, and remove the unused cpu hotplug notify. Patch 6/7: -split the function rename (just cleanup) into single patch. Patch 7/7: -introduce help function acpi_set_local_sts to keep the bit setting in one place. Gu Zheng (7): acpi/cpu: add cpu hotplug callback function to match hotplug_handler API acpi:ich9: convert cpu hotplug handle to hotplug_handler API acpi:piix4: convert cpu hotplug handle to hotplug_handler API pc: add cpu hotplug handler to PC_MACHINE pc: Update rtc_cmos in pc_cpu_plug cpu-hotplug: rename function for better readability acpi/cpu-hotplug: introduce help function to keep bit setting in one place hw/acpi/cpu_hotplug.c | 35 hw/acpi/ich9.c| 18 -- hw/acpi/piix4.c | 18 +++--- hw/i386/pc.c | 51 + include/hw/acpi/cpu_hotplug.h |7 +++-- include/hw/acpi/ich9.h|1 - include/sysemu/sysemu.h |3 -- qom/cpu.c | 10 8 files changed, 69 insertions(+), 74 deletions(-) -- 1.7.7
[Qemu-devel] [PATCH V2 1/7] acpi/cpu: add cpu hotplug callback function to match hotplug_handler API
---
v2:
-add errp argument to catch error.
-return error instead of aborting if cpu id is invalid.
-make acpi_cpu_plug_cb as a wrapper around AcpiCpuHotplug_add.
---
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
hw/acpi/cpu_hotplug.c | 17 +
include/hw/acpi/cpu_hotplug.h |3 +++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index 2ad83a0..dfd6de5 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -36,6 +36,23 @@ static const MemoryRegionOps AcpiCpuHotplug_ops = {
},
};
+void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
+ AcpiCpuHotplug *g, CPUState *cpu, Error **errp)
+{
+CPUClass *k = CPU_GET_CLASS(cpu);
+int64_t cpu_id;
+
+cpu_id = k-get_arch_id(cpu);
+if ((cpu_id / 8) = ACPI_GPE_PROC_LEN) {
+error_setg(errp, acpi: invalid cpu id: % PRIi64, cpu_id);
+return;
+}
+
+AcpiCpuHotplug_add(ar-gpe, g, cpu);
+
+acpi_update_sci(ar, irq);
+}
+
void AcpiCpuHotplug_add(ACPIGPE *gpe, AcpiCpuHotplug *g, CPUState *cpu)
{
CPUClass *k = CPU_GET_CLASS(cpu);
diff --git a/include/hw/acpi/cpu_hotplug.h b/include/hw/acpi/cpu_hotplug.h
index 9e5d30c..166edb0 100644
--- a/include/hw/acpi/cpu_hotplug.h
+++ b/include/hw/acpi/cpu_hotplug.h
@@ -20,6 +20,9 @@ typedef struct AcpiCpuHotplug {
uint8_t sts[ACPI_GPE_PROC_LEN];
} AcpiCpuHotplug;
+void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
+ AcpiCpuHotplug *g, CPUState *dev, Error **errp);
+
void AcpiCpuHotplug_add(ACPIGPE *gpe, AcpiCpuHotplug *g, CPUState *cpu);
void AcpiCpuHotplug_init(MemoryRegion *parent, Object *owner,
--
1.7.7
[Qemu-devel] [PATCH V2 2/7] acpi:ich9: convert cpu hotplug handle to hotplug_handler API
Convert notifier based hotplug handle to hotplug_handler API.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
hw/acpi/ich9.c | 14 +++---
include/hw/acpi/ich9.h |1 -
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index 7b14bbb..c53d4ab 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -209,15 +209,6 @@ static void pm_powerdown_req(Notifier *n, void *opaque)
acpi_pm1_evt_power_down(pm-acpi_regs);
}
-static void ich9_cpu_added_req(Notifier *n, void *opaque)
-{
-ICH9LPCPMRegs *pm = container_of(n, ICH9LPCPMRegs, cpu_added_notifier);
-
-assert(pm != NULL);
-AcpiCpuHotplug_add(pm-acpi_regs.gpe, pm-gpe_cpu, CPU(opaque));
-acpi_update_sci(pm-acpi_regs, pm-irq);
-}
-
void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
qemu_irq sci_irq)
{
@@ -246,8 +237,6 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
AcpiCpuHotplug_init(pci_address_space_io(lpc_pci), OBJECT(lpc_pci),
pm-gpe_cpu, ICH9_CPU_HOTPLUG_IO_BASE);
-pm-cpu_added_notifier.notify = ich9_cpu_added_req;
-qemu_register_cpu_added_notifier(pm-cpu_added_notifier);
if (pm-acpi_memory_hotplug.is_enabled) {
acpi_memory_hotplug_init(pci_address_space_io(lpc_pci),
OBJECT(lpc_pci),
@@ -304,6 +293,9 @@ void ich9_pm_device_plug_cb(ICH9LPCPMRegs *pm, DeviceState
*dev, Error **errp)
object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
acpi_memory_plug_cb(pm-acpi_regs, pm-irq, pm-acpi_memory_hotplug,
dev, errp);
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
+acpi_cpu_plug_cb(pm-acpi_regs, pm-irq, pm-gpe_cpu,
+ CPU(dev), errp);
} else {
error_setg(errp, acpi: device plug request for not supported device
type: %s, object_get_typename(OBJECT(dev)));
diff --git a/include/hw/acpi/ich9.h b/include/hw/acpi/ich9.h
index 7e42448..fe975e6 100644
--- a/include/hw/acpi/ich9.h
+++ b/include/hw/acpi/ich9.h
@@ -47,7 +47,6 @@ typedef struct ICH9LPCPMRegs {
Notifier powerdown_notifier;
AcpiCpuHotplug gpe_cpu;
-Notifier cpu_added_notifier;
MemHotplugState acpi_memory_hotplug;
} ICH9LPCPMRegs;
--
1.7.7
[Qemu-devel] [PATCH V2 3/7] acpi:piix4: convert cpu hotplug handle to hotplug_handler API
Convert notifier based hotplug handle to hotplug_handler API,
and remove the unused AcpiCpuHotplug_add().
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
hw/acpi/cpu_hotplug.c | 14 ++
hw/acpi/piix4.c | 14 ++
include/hw/acpi/cpu_hotplug.h |2 --
3 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index dfd6de5..0b9fa55 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -48,22 +48,12 @@ void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
return;
}
-AcpiCpuHotplug_add(ar-gpe, g, cpu);
+ar-gpe.sts[0] |= ACPI_CPU_HOTPLUG_STATUS;
+g-sts[cpu_id / 8] |= (1 (cpu_id % 8));
acpi_update_sci(ar, irq);
}
-void AcpiCpuHotplug_add(ACPIGPE *gpe, AcpiCpuHotplug *g, CPUState *cpu)
-{
-CPUClass *k = CPU_GET_CLASS(cpu);
-int64_t cpu_id;
-
-*gpe-sts = *gpe-sts | ACPI_CPU_HOTPLUG_STATUS;
-cpu_id = k-get_arch_id(CPU(cpu));
-g_assert((cpu_id / 8) ACPI_GPE_PROC_LEN);
-g-sts[cpu_id / 8] |= (1 (cpu_id % 8));
-}
-
void AcpiCpuHotplug_init(MemoryRegion *parent, Object *owner,
AcpiCpuHotplug *gpe_cpu, uint16_t base)
{
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b72b34e..b046cd3 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -83,7 +83,6 @@ typedef struct PIIX4PMState {
uint8_t s4_val;
AcpiCpuHotplug gpe_cpu;
-Notifier cpu_added_notifier;
MemHotplugState acpi_memory_hotplug;
} PIIX4PMState;
@@ -348,6 +347,8 @@ static void piix4_device_plug_cb(HotplugHandler
*hotplug_dev,
} else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
acpi_pcihp_device_plug_cb(s-ar, s-irq, s-acpi_pci_hotplug, dev,
errp);
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
+acpi_cpu_plug_cb(s-ar, s-irq, s-gpe_cpu, CPU(dev), errp);
} else {
error_setg(errp, acpi: device plug request for not supported device
type: %s, object_get_typename(OBJECT(dev)));
@@ -544,15 +545,6 @@ static const MemoryRegionOps piix4_gpe_ops = {
.endianness = DEVICE_LITTLE_ENDIAN,
};
-static void piix4_cpu_added_req(Notifier *n, void *opaque)
-{
-PIIX4PMState *s = container_of(n, PIIX4PMState, cpu_added_notifier);
-
-assert(s != NULL);
-AcpiCpuHotplug_add(s-ar.gpe, s-gpe_cpu, CPU(opaque));
-acpi_update_sci(s-ar, s-irq);
-}
-
static void piix4_acpi_system_hot_add_init(MemoryRegion *parent,
PCIBus *bus, PIIX4PMState *s)
{
@@ -565,8 +557,6 @@ static void piix4_acpi_system_hot_add_init(MemoryRegion
*parent,
AcpiCpuHotplug_init(parent, OBJECT(s), s-gpe_cpu,
PIIX4_CPU_HOTPLUG_IO_BASE);
-s-cpu_added_notifier.notify = piix4_cpu_added_req;
-qemu_register_cpu_added_notifier(s-cpu_added_notifier);
if (s-acpi_memory_hotplug.is_enabled) {
acpi_memory_hotplug_init(parent, OBJECT(s), s-acpi_memory_hotplug);
diff --git a/include/hw/acpi/cpu_hotplug.h b/include/hw/acpi/cpu_hotplug.h
index 166edb0..8188630 100644
--- a/include/hw/acpi/cpu_hotplug.h
+++ b/include/hw/acpi/cpu_hotplug.h
@@ -23,8 +23,6 @@ typedef struct AcpiCpuHotplug {
void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
AcpiCpuHotplug *g, CPUState *dev, Error **errp);
-void AcpiCpuHotplug_add(ACPIGPE *gpe, AcpiCpuHotplug *g, CPUState *cpu);
-
void AcpiCpuHotplug_init(MemoryRegion *parent, Object *owner,
AcpiCpuHotplug *gpe_cpu, uint16_t base);
#endif
--
1.7.7
[Qemu-devel] [PATCH V2 4/7] pc: add cpu hotplug handler to PC_MACHINE
Add cpu hotplug handler to PC_MACHINE, which will perform the acpi
cpu hotplug callback via hotplug_handler API.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
hw/i386/pc.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index b6c9b61..28fc66b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1613,11 +1613,34 @@ out:
error_propagate(errp, local_err);
}
+static void pc_cpu_plug(HotplugHandler *hotplug_dev,
+DeviceState *dev, Error **errp)
+{
+HotplugHandlerClass *hhc;
+Error *local_err = NULL;
+PCMachineState *pcms = PC_MACHINE(hotplug_dev);
+
+if (dev-hotplugged) {
+if (!pcms-acpi_dev) {
+error_setg(local_err,
+ cpu hotplug is not enabled: missing acpi device);
+goto out;
+}
+
+hhc = HOTPLUG_HANDLER_GET_CLASS(pcms-acpi_dev);
+hhc-plug(HOTPLUG_HANDLER(pcms-acpi_dev), dev, local_err);
+out:
+error_propagate(errp, local_err);
+}
+}
+
static void pc_machine_device_plug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp)
{
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
pc_dimm_plug(hotplug_dev, dev, errp);
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
+pc_cpu_plug(hotplug_dev, dev, errp);
}
}
@@ -1626,7 +1649,8 @@ static HotplugHandler *pc_get_hotpug_handler(MachineState
*machine,
{
PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(machine);
-if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
+if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) ||
+object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
return HOTPLUG_HANDLER(machine);
}
--
1.7.7
[Qemu-devel] [PATCH V2 5/7] pc: Update rtc_cmos in pc_cpu_plug
Update rtc_cmos in pc_cpu_plug directly instead of the notifier, with
this change, there will no user of CPU hot-plug notifier any more, so
remove it.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
hw/i386/pc.c| 25 ++---
include/sysemu/sysemu.h |3 ---
qom/cpu.c | 10 --
3 files changed, 6 insertions(+), 32 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 28fc66b..337d662 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -353,20 +353,7 @@ static void pc_cmos_init_late(void *opaque)
qemu_unregister_reset(pc_cmos_init_late, opaque);
}
-typedef struct RTCCPUHotplugArg {
-Notifier cpu_added_notifier;
-ISADevice *rtc_state;
-} RTCCPUHotplugArg;
-
-static void rtc_notify_cpu_added(Notifier *notifier, void *data)
-{
-RTCCPUHotplugArg *arg = container_of(notifier, RTCCPUHotplugArg,
- cpu_added_notifier);
-ISADevice *s = arg-rtc_state;
-
-/* increment the number of CPUs */
-rtc_set_memory(s, 0x5f, rtc_get_memory(s, 0x5f) + 1);
-}
+static ISADevice *rtc_state;
void pc_cmos_init(ram_addr_t ram_size, ram_addr_t above_4g_mem_size,
const char *boot_device,
@@ -376,7 +363,6 @@ void pc_cmos_init(ram_addr_t ram_size, ram_addr_t
above_4g_mem_size,
int val, nb, i;
FDriveType fd_type[2] = { FDRIVE_DRV_NONE, FDRIVE_DRV_NONE };
static pc_cmos_init_late_arg arg;
-static RTCCPUHotplugArg cpu_hotplug_cb;
/* various important CMOS locations needed by PC/Bochs bios */
@@ -415,10 +401,8 @@ void pc_cmos_init(ram_addr_t ram_size, ram_addr_t
above_4g_mem_size,
/* set the number of CPU */
rtc_set_memory(s, 0x5f, smp_cpus - 1);
-/* init CPU hotplug notifier */
-cpu_hotplug_cb.rtc_state = s;
-cpu_hotplug_cb.cpu_added_notifier.notify = rtc_notify_cpu_added;
-qemu_register_cpu_added_notifier(cpu_hotplug_cb.cpu_added_notifier);
+
+rtc_state = s;
if (set_boot_dev(s, boot_device)) {
exit(1);
@@ -1629,6 +1613,9 @@ static void pc_cpu_plug(HotplugHandler *hotplug_dev,
hhc = HOTPLUG_HANDLER_GET_CLASS(pcms-acpi_dev);
hhc-plug(HOTPLUG_HANDLER(pcms-acpi_dev), dev, local_err);
+
+/* increment the number of CPUs */
+rtc_set_memory(rtc_state, 0x5f, rtc_get_memory(rtc_state, 0x5f) + 1);
out:
error_propagate(errp, local_err);
}
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index d8539fd..acfe494 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -183,9 +183,6 @@ void do_pci_device_hot_remove(Monitor *mon, const QDict
*qdict);
/* generic hotplug */
void drive_hot_add(Monitor *mon, const QDict *qdict);
-/* CPU hotplug */
-void qemu_register_cpu_added_notifier(Notifier *notifier);
-
/* pcie aer error injection */
void pcie_aer_inject_error_print(Monitor *mon, const QObject *data);
int do_pcie_aer_inject_error(Monitor *mon,
diff --git a/qom/cpu.c b/qom/cpu.c
index b32dd0a..19c5de5 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -107,15 +107,6 @@ static void cpu_common_get_memory_mapping(CPUState *cpu,
error_setg(errp, Obtaining memory mappings is unsupported on this CPU.);
}
-/* CPU hot-plug notifiers */
-static NotifierList cpu_added_notifiers =
-NOTIFIER_LIST_INITIALIZER(cpu_add_notifiers);
-
-void qemu_register_cpu_added_notifier(Notifier *notifier)
-{
-notifier_list_add(cpu_added_notifiers, notifier);
-}
-
void cpu_reset_interrupt(CPUState *cpu, int mask)
{
cpu-interrupt_request = ~mask;
@@ -303,7 +294,6 @@ static void cpu_common_realizefn(DeviceState *dev, Error
**errp)
if (dev-hotplugged) {
cpu_synchronize_post_init(cpu);
-notifier_list_notify(cpu_added_notifiers, dev);
cpu_resume(cpu);
}
}
--
1.7.7
[Qemu-devel] [PATCH V2 6/7] cpu-hotplug: rename function for better readability
Rename:
AcpiCpuHotplug_init -- acpi_cpu_hotplug_init
AcpiCpuHotplug_ops -- acpi_cpu_hotplug_ops
for better readability, just cleanup.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
hw/acpi/cpu_hotplug.c |4 ++--
hw/acpi/ich9.c|4 ++--
hw/acpi/piix4.c |4 ++--
include/hw/acpi/cpu_hotplug.h |4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index 0b9fa55..7629686 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -54,8 +54,8 @@ void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
acpi_update_sci(ar, irq);
}
-void AcpiCpuHotplug_init(MemoryRegion *parent, Object *owner,
- AcpiCpuHotplug *gpe_cpu, uint16_t base)
+void acpi_cpu_hotplug_init(MemoryRegion *parent, Object *owner,
+ AcpiCpuHotplug *gpe_cpu, uint16_t base)
{
CPUState *cpu;
diff --git a/hw/acpi/ich9.c b/hw/acpi/ich9.c
index c53d4ab..42cf8fa 100644
--- a/hw/acpi/ich9.c
+++ b/hw/acpi/ich9.c
@@ -235,8 +235,8 @@ void ich9_pm_init(PCIDevice *lpc_pci, ICH9LPCPMRegs *pm,
pm-powerdown_notifier.notify = pm_powerdown_req;
qemu_register_powerdown_notifier(pm-powerdown_notifier);
-AcpiCpuHotplug_init(pci_address_space_io(lpc_pci), OBJECT(lpc_pci),
-pm-gpe_cpu, ICH9_CPU_HOTPLUG_IO_BASE);
+acpi_cpu_hotplug_init(pci_address_space_io(lpc_pci), OBJECT(lpc_pci),
+ pm-gpe_cpu, ICH9_CPU_HOTPLUG_IO_BASE);
if (pm-acpi_memory_hotplug.is_enabled) {
acpi_memory_hotplug_init(pci_address_space_io(lpc_pci),
OBJECT(lpc_pci),
diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index b046cd3..205ba66 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -555,8 +555,8 @@ static void piix4_acpi_system_hot_add_init(MemoryRegion
*parent,
acpi_pcihp_init(s-acpi_pci_hotplug, bus, parent,
s-use_acpi_pci_hotplug);
-AcpiCpuHotplug_init(parent, OBJECT(s), s-gpe_cpu,
-PIIX4_CPU_HOTPLUG_IO_BASE);
+acpi_cpu_hotplug_init(parent, OBJECT(s), s-gpe_cpu,
+ PIIX4_CPU_HOTPLUG_IO_BASE);
if (s-acpi_memory_hotplug.is_enabled) {
acpi_memory_hotplug_init(parent, OBJECT(s), s-acpi_memory_hotplug);
diff --git a/include/hw/acpi/cpu_hotplug.h b/include/hw/acpi/cpu_hotplug.h
index 8188630..d015bef 100644
--- a/include/hw/acpi/cpu_hotplug.h
+++ b/include/hw/acpi/cpu_hotplug.h
@@ -23,6 +23,6 @@ typedef struct AcpiCpuHotplug {
void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
AcpiCpuHotplug *g, CPUState *dev, Error **errp);
-void AcpiCpuHotplug_init(MemoryRegion *parent, Object *owner,
- AcpiCpuHotplug *gpe_cpu, uint16_t base);
+void acpi_cpu_hotplug_init(MemoryRegion *parent, Object *owner,
+ AcpiCpuHotplug *gpe_cpu, uint16_t base);
#endif
--
1.7.7
[Qemu-devel] [PATCH V2 7/7] acpi/cpu-hotplug: introduce help function to keep bit setting in one place
Introduce help function acpi_set_local_sts() to simplify acpi_cpu_plug_cb
and acpi_cpu_hotplug_init, so that we can keep bit setting in one place.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
hw/acpi/cpu_hotplug.c | 22 +++---
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
index 7629686..5d62218 100644
--- a/hw/acpi/cpu_hotplug.c
+++ b/hw/acpi/cpu_hotplug.c
@@ -36,8 +36,8 @@ static const MemoryRegionOps AcpiCpuHotplug_ops = {
},
};
-void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
- AcpiCpuHotplug *g, CPUState *cpu, Error **errp)
+static void acpi_set_local_sts(AcpiCpuHotplug *g, CPUState *cpu,
+ Error **errp)
{
CPUClass *k = CPU_GET_CLASS(cpu);
int64_t cpu_id;
@@ -48,9 +48,18 @@ void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
return;
}
-ar-gpe.sts[0] |= ACPI_CPU_HOTPLUG_STATUS;
g-sts[cpu_id / 8] |= (1 (cpu_id % 8));
+}
+void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
+ AcpiCpuHotplug *g, CPUState *cpu, Error **errp)
+{
+acpi_set_local_sts(g, cpu, errp);
+if (*errp != NULL) {
+return;
+}
+
+ar-gpe.sts[0] |= ACPI_CPU_HOTPLUG_STATUS;
acpi_update_sci(ar, irq);
}
@@ -60,11 +69,10 @@ void acpi_cpu_hotplug_init(MemoryRegion *parent, Object
*owner,
CPUState *cpu;
CPU_FOREACH(cpu) {
-CPUClass *cc = CPU_GET_CLASS(cpu);
-int64_t id = cc-get_arch_id(cpu);
+Error *local_err = NULL;
-g_assert((id / 8) ACPI_GPE_PROC_LEN);
-gpe_cpu-sts[id / 8] |= (1 (id % 8));
+acpi_set_local_sts(gpe_cpu, cpu, local_err);
+g_assert(local_err == NULL);
}
memory_region_init_io(gpe_cpu-io, owner, AcpiCpuHotplug_ops,
gpe_cpu, acpi-cpu-hotplug, ACPI_GPE_PROC_LEN);
--
1.7.7
Re: [Qemu-devel] [PATCH v15 0/5] qcow2, raw: add preallocation=full and preallocation=falloc
ping? On Wed, Sep 10, 2014 at 05:05:44PM +0800, Hu Tao wrote: This series adds two preallocation mode to qcow2 and raw: Option preallocation=full preallocates disk space for image by writing zeros to disk, this ensures disk space in any cases. Option preallocation=falloc preallocates disk space by calling posix_fallocate(). This is faster than preallocation=full. Note: there is a false positive reported by checkpatch.pl to patch 1. changes to v14: - add detailed commit message to patch 1 - change the coding style as Eric and Benoît suggested (patch 3) - use break as Benoît suggested (patch 4) changes to v13: - rebase (patch 3 in v13 is already in) - don't convert file size to sector size in hdev_create(), too (patch 2) - reintroduce preallocation=falloc. (patch 3) - split the implementation of preallocation=full in v13 into preallocation=falloc and preallocation=full (patch 4) changes to v12: - remove dependence on minimal_blob_size() (patch 6) - remove preallocation=falloc. (patch 4) - preallocation=full tries posix_fallocate() first then writing zeros (patch 5) - round up file size for all formats (patch 1) - avoid converting file size for more formats (patch 2) changes to v11: - fix test case 049 (patch 4) - unsigned nl2e - uint64_t nl2e (patch 6) - use instead of / (patch 6) changes to v10: - PreallocMode is moved from file qapi-schema.json to qapi/block-core.json - introdues preallocation=falloc, no changes to preallocation=metadata - using minimal_blob_size() to calculate metadata size for qcow2 - indentation fix in file blockdev.c changes to v9: - use ROUND_UP to do round up - split the round up into its own patch and add test case - new patch rename parse_enum_option to qapi_enum_parse and make it public - reuse qapi_enum_parse changes to v8: - round up image file size to nearest sector size - dont' blindly lose error info - target for 2.1 rather than 2.0 - and, rebase to latest git tree changes to v5: - add `Since 2.0' to PreallocMode - apply total_size change to raw-win32.c as well changes to v4: - fix wrong calculation of qcow2 metadata size in v4 - remove raw_preallocate2() - better error out path in raw_create() - fix coding style changes to v3: - remove bdrv_preallocate and make preallocation a bdrv_create_file option - prealloc_mode - PreallocMode and add it to QAPI - fix return value in raw_preallocate2 changes to v2: - Fix comments to v2 by Fam. - qcow2: first fallocate disk space, then allocate metadata. This avoids the problem in v2 that bdrv_preallocate may clear all information in metadata. This does not necessarily map all data clusters sequentially but does keep information in metadata. Peter, is this acceptable? Hu Tao (5): block: round up file size to nearest sector block: don't convert file size to sector size qapi: introduce PreallocMode and new PreallocModes full and falloc. raw-posix: Add falloc and full preallocation option qcow2: Add falloc and full preallocation option block/archipelago.c | 3 +- block/cow.c | 3 +- block/gluster.c | 9 ++-- block/iscsi.c| 4 +- block/nfs.c | 3 +- block/qcow.c | 7 +-- block/qcow2.c| 82 +-- block/qed.c | 3 +- block/raw-posix.c| 102 ++- block/raw-win32.c| 6 +-- block/rbd.c | 3 +- block/sheepdog.c | 3 +- block/ssh.c | 3 +- block/vdi.c | 3 +- block/vhdx.c | 3 +- block/vmdk.c | 3 +- block/vpc.c | 3 +- qapi/block-core.json | 17 +++ qemu-doc.texi| 17 +-- qemu-img.texi| 17 +-- tests/qemu-iotests/049.out | 2 +- tests/qemu-iotests/082.out | 54 ++--- tests/qemu-iotests/104 | 57 ++ tests/qemu-iotests/104.out | 12 + tests/qemu-iotests/common.filter | 21 tests/qemu-iotests/group | 1 + 26 files changed, 344 insertions(+), 97 deletions(-) create mode 100755 tests/qemu-iotests/104 create mode 100644 tests/qemu-iotests/104.out -- 1.9.3
Re: [Qemu-devel] OVMF, Q35 and USB keyboard/mouse
On Thu, 11 Sep 2014, Gabriel L. Somlo wrote: On Thu, Sep 11, 2014 at 11:34:03PM +0200, Alexander Graf wrote: XNU also populates its device tree based on the DSDT. Maybe there's a subtle difference there? This was the low hanging fruit, so I checked it first :) Pulled the DSDT using the OS X version of DSDTEditor (found on insanelymac) on both the Chameleon q35 version which had all three UHCIs and from the OVMF q35 version which only showed UHCI3. The two DSDTs looked absolutely identical (no output from diff)... You may also look for differences in USB devices in the ouput of ioreg. Maybe that shows something. (It's basically what you can see in System Profiler but easier to compare with diff and may have additional data.) Regards, BALATON Zoltan
Re: [Qemu-devel] qemu-img: unable to convert raw image 2GB with git master
On Fri, 09/12 09:57, Mark Cave-Ayland wrote: Hi all, I've been trying to convert a raw disk partition from my laptop for use on VMWare player and I'm seeing the following error from qemu-img git master during conversion: # qemu-img convert -f raw -O vmdk /dev/mapper/vm-raw out.vmdk qemu-img: error while writing sector 4247552: Invalid argument A quick glance at the resulting output file makes me thing that an artificial 2GB limit has accidentally been introduced: # ls -l | grep out.vmdk -rw-r--r-- 1 root root 2147483648 Sep 12 09:49 out.vmdk Can anyone else reproduce this? The input /dev/mapper/vm-raw is simply a raw 4GB LVM partition on my local disk which is mapped through as a standard hard disk into QEMU. Yes, I can reproduce it easily: $ ~/build/master/qemu-io /stor/vm/arch.vmdk -c 'write 2G 1k' write failed: Invalid argument This is a regression, I'll send a patch to fix it shortly. Thanks, Fam
[Qemu-devel] [PATCH v10 04/30] fw_cfg: add fw_cfg_machine_reset function
From: Gonglei arei.gong...@huawei.com
We must assure that the changed bootindex can take effect
when guest is rebooted. So we introduce fw_cfg_machine_reset(),
which change the fw_cfg file's bootindex data using the new
global fw_boot_order list.
Signed-off-by: Chenliang chenlian...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/nvram/fw_cfg.c | 55 ---
include/hw/nvram/fw_cfg.h | 2 ++
2 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index b71d251..e7ed27e 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -402,6 +402,26 @@ static void fw_cfg_add_bytes_read_callback(FWCfgState *s,
uint16_t key,
s-entries[arch][key].callback_opaque = callback_opaque;
}
+static void *fw_cfg_modify_bytes_read(FWCfgState *s, uint16_t key,
+ void *data, size_t len)
+{
+void *ptr;
+int arch = !!(key FW_CFG_ARCH_LOCAL);
+
+key = FW_CFG_ENTRY_MASK;
+
+assert(key FW_CFG_MAX_ENTRY len UINT32_MAX);
+
+/* return the old data to the function caller, avoid memory leak */
+ptr = s-entries[arch][key].data;
+s-entries[arch][key].data = data;
+s-entries[arch][key].len = len;
+s-entries[arch][key].callback_opaque = NULL;
+s-entries[arch][key].callback = NULL;
+
+return ptr;
+}
+
void fw_cfg_add_bytes(FWCfgState *s, uint16_t key, void *data, size_t len)
{
fw_cfg_add_bytes_read_callback(s, key, NULL, NULL, data, len);
@@ -499,13 +519,42 @@ void fw_cfg_add_file(FWCfgState *s, const char *filename,
fw_cfg_add_file_callback(s, filename, NULL, NULL, data, len);
}
-static void fw_cfg_machine_ready(struct Notifier *n, void *data)
+void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
+void *data, size_t len)
+{
+int i, index;
+
+assert(s-files);
+
+index = be32_to_cpu(s-files-count);
+assert(index FW_CFG_FILE_SLOTS);
+
+for (i = 0; i index; i++) {
+if (strcmp(filename, s-files-f[i].name) == 0) {
+return fw_cfg_modify_bytes_read(s, FW_CFG_FILE_FIRST + i,
+ data, len);
+}
+}
+/* add new one */
+fw_cfg_add_file_callback(s, filename, NULL, NULL, data, len);
+return NULL;
+}
+
+static void fw_cfg_machine_reset(void *opaque)
{
+void *ptr;
size_t len;
-FWCfgState *s = container_of(n, FWCfgState, machine_ready);
+FWCfgState *s = opaque;
char *bootindex = get_boot_devices_list(len, false);
-fw_cfg_add_file(s, bootorder, (uint8_t*)bootindex, len);
+ptr = fw_cfg_modify_file(s, bootorder, (uint8_t *)bootindex, len);
+g_free(ptr);
+}
+
+static void fw_cfg_machine_ready(struct Notifier *n, void *data)
+{
+FWCfgState *s = container_of(n, FWCfgState, machine_ready);
+qemu_register_reset(fw_cfg_machine_reset, s);
}
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index 72b1549..56e1ed7 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -76,6 +76,8 @@ void fw_cfg_add_file(FWCfgState *s, const char *filename,
void *data,
void fw_cfg_add_file_callback(FWCfgState *s, const char *filename,
FWCfgReadCallback callback, void
*callback_opaque,
void *data, size_t len);
+void *fw_cfg_modify_file(FWCfgState *s, const char *filename, void *data,
+ size_t len);
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
hwaddr crl_addr, hwaddr data_addr);
--
1.7.12.4
[Qemu-devel] [PATCH v10 09/30] e1000: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/net/e1000.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 272df00..0edbfa6 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -1621,10 +1621,19 @@ static void e1000_class_init(ObjectClass *klass, void
*data)
dc-props = e1000_properties;
}
+static void e1000_instance_init(Object *obj)
+{
+E1000State *n = E1000(obj);
+device_add_bootindex_property(obj, n-conf.bootindex,
+ bootindex, /ethernet-phy@0,
+ DEVICE(n), NULL);
+}
+
static const TypeInfo e1000_base_info = {
.name = TYPE_E1000_BASE,
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(E1000State),
+.instance_init = e1000_instance_init,
.class_size= sizeof(E1000BaseClass),
.abstract = true,
};
@@ -1668,6 +1677,7 @@ static void e1000_register_types(void)
type_info.parent = TYPE_E1000_BASE;
type_info.class_data = (void *)info;
type_info.class_init = e1000_class_init;
+type_info.instance_init = e1000_instance_init;
type_register(type_info);
}
--
1.7.12.4
[Qemu-devel] [PATCH v10 00/30] modify boot order of guest, and take effect after rebooting
From: Gonglei arei.gong...@huawei.com Sometimes, we want to modify boot order of a guest, but no need to shutdown it. We can call dynamic changing bootindex of a guest, which can be assured taking effect just after the guest rebooting. For example, in P2V scene, we boot a guest and then attach a new system disk, for copying some thing. We want to assign the new disk as the booting disk, which means its bootindex=1. Different nics can be assigen different bootindex dynamically also make sense. This patch series do belows works: 1. add an fw_cfg_machine_reset() assure re-read global fw_boot_order list during vm rebooting. 2. switch the property from qdev to qom, then use the set callback to also update the fw_cfg file. Note: - Do not support change pci option rom's bootindex. - Do not handle those devices which don't have use the bootindex property. changes since v9: - rework del_boot_device_path() for code sharing more better.(Gerd) Now, it has only one delete funciton, which work for update fw_cfg list both setting bootindex and hot-unplugging devices. changes since v8: - fix wrong rebase on PATCH 14/30 and 15/30. changes since v7: - IDE unit's value is set too later, so change IDE to not use device_add_bootindex_property(). IDE has its own getter/setter and a call to add_boot_device_path() on realize(). PATCH 25/30, 28/30 (Eduardo) - rewrite PATCH 5/30 using g_strcmp0. (Eduardo) - set 'ide_device_type_info.instance_init = ide_dev_instance_init' for all ide devices. PATCH 25/30 (Eduardo) - set 'scsi_device_type_info.instance_init = scsi_dev_instance_init' for all scsi devices. PATCH 24/30 - initialize bootindex property to -1 in device_add_bootindex_property, so there is no need to duplicate the call to init bootindex with -1 in all devices. (Gerd) Thanks for review! changes since v6: - move all bootindex/boot-device code to a new file, named bootdevice.c. - introduce a getter/setter wrapper for all device. - call add_boot_device_path in setter bootindx callback function. - call del_boot_device_path in finalize bootindex qom callback function. - other bugfixes. Thanks for Eduardo's good suggestion! And other guys, thanks too! changes since v5: rework by Gerd and Markus's suggestion(Thanks a lot): - Set/update bootindex on reset instead of realize/init. - Switch the property from qdev to qom, then use the set callback to also update the fw_cfg file. - using qom-set instead of 'set-bootindex' qmp interface, remove it. This is a huge change relative to the previous version. Changes since v4: - using error_setg() instead of qerror_report() in patch 1/8. - call del_boot_device_path() from device_finalize() instead of placing it into each individual device in patch 4/8. Changes since v3: - rework del_* and modify_* function, because of virtio devices' specialation. For example, virtio-net's id is NULL, and its parent virtio-net-pci's id was assigned. Though the global fw_boot_order stored the virtio-net device. - call dell_boot_device_path in each individual device avoiding waste resouce. - introduce qmp query-bootindex command - introcude hmp info bootindex command - Fixes by Eric's reviewing comments, thanks. Changes since v2: *address Gerd's reviewing suggestion: - use the old entry's suffix, if the caller do not pass it in. - call del_boot_device_path() from device_finalize() instead of placing it into each individual device. Changes since v1: *rework by Gerd's suggestion: - split modify and del fw_boot_order for single function. - change modify bootindex's realization which simply lookup the device and modify the bootindex. if the new bootindex has already used by another device just throw an error. - change to del_boot_device_path(DeviceState *dev) and simply delete all entries belonging to the device. For Convenience of testing, my test case based on Andreas's patch series: [PATCH qom-next 0/4] qom: HMP commands to replace info qtree http://thread.gmane.org/gmane.comp.emulators.qemu/271513 However, there is no direct relation with this bootindex patch series. This series based on my patch series (Welcome to reviewing!): [PATCH v2 0/9] virtio: fix virtio child recount in transports http://lists.gnu.org/archive/html/qemu-devel/2014-09/msg01601.html ./qemu-system-x86_64 -enable-kvm -m 4096 -smp 4 -name redhat6.2 -drive \ file=/home/win7_32_2U,if=none,id=drive-ide0-0-0 -device ide-hd,bus=ide.0,\ unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive \ file=/home/rhel-server-7.0-x86_64-dvd.iso,if=none,id=drive-ide0-0-1 \ -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=4 \ -vnc 0.0.0.0:10 -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=3,id=nic1 \ -drive file=/mnt/sdb/gonglei/image/virtio-win-1.5.3.vfd,if=none,id=drive-fdc0-0-0,format=raw \ -device isa-fdc,driveA=drive-fdc0-0-0,bootindexA=5,id=floppy1 -qmp unix:/tmp/qmp,server,nowait \
[Qemu-devel] [PATCH v10 13/30] rtl8139: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/net/rtl8139.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
index 6e59f38..138a03a 100644
--- a/hw/net/rtl8139.c
+++ b/hw/net/rtl8139.c
@@ -3543,6 +3543,15 @@ static int pci_rtl8139_init(PCIDevice *dev)
return 0;
}
+static void rtl8139_instance_init(Object *obj)
+{
+RTL8139State *s = RTL8139(obj);
+
+device_add_bootindex_property(obj, s-conf.bootindex,
+ bootindex, /ethernet-phy@0,
+ DEVICE(obj), NULL);
+}
+
static Property rtl8139_properties[] = {
DEFINE_NIC_PROPERTIES(RTL8139State, conf),
DEFINE_PROP_END_OF_LIST(),
@@ -3571,6 +3580,7 @@ static const TypeInfo rtl8139_info = {
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(RTL8139State),
.class_init= rtl8139_class_init,
+.instance_init = rtl8139_instance_init,
};
static void rtl8139_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 05/30] bootindex: rework add_boot_device_path function
From: Gonglei arei.gong...@huawei.com Add the function of updating bootindex about fw_boot_order list in add_boot_device_path(). We should delete the old one if a device has existed in global fw_boot_order list. Signed-off-by: Gonglei arei.gong...@huawei.com --- bootdevice.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/bootdevice.c b/bootdevice.c index 7167fbc..aac0ffb 100644 --- a/bootdevice.c +++ b/bootdevice.c @@ -82,6 +82,8 @@ void add_boot_device_path(int32_t bootindex, DeviceState *dev, assert(dev != NULL || suffix != NULL); +del_boot_device_path(dev, suffix); + node = g_malloc0(sizeof(FWBootEntry)); node-bootindex = bootindex; node-suffix = g_strdup(suffix); -- 1.7.12.4
[Qemu-devel] [PATCH v10 02/30] bootindex: add check bootindex function
From: Gonglei arei.gong...@huawei.com
Determine whether a given bootindex exists or not.
If exists, we report an error.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
bootdevice.c| 15 +++
include/sysemu/sysemu.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/bootdevice.c b/bootdevice.c
index d5b8789..f5399df 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -36,6 +36,21 @@ struct FWBootEntry {
static QTAILQ_HEAD(, FWBootEntry) fw_boot_order =
QTAILQ_HEAD_INITIALIZER(fw_boot_order);
+void check_boot_index(int32_t bootindex, Error **errp)
+{
+FWBootEntry *i;
+
+if (bootindex = 0) {
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (i-bootindex == bootindex) {
+error_setg(errp, The bootindex %d has already been used,
+ bootindex);
+return;
+}
+}
+}
+}
+
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix)
{
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 8de5100..72463de 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -213,6 +213,7 @@ void add_boot_device_path(int32_t bootindex, DeviceState
*dev,
char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
DeviceState *get_boot_device(uint32_t position);
+void check_boot_index(int32_t bootindex, Error **errp);
QemuOpts *qemu_get_machine_opts(void);
--
1.7.12.4
[Qemu-devel] [PATCH v10 01/30] bootdevice: move bootdevice related code to new file bootdevice.c
From: Gonglei arei.gong...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
---
Makefile.target | 2 +-
bootdevice.c| 142
include/sysemu/sysemu.h | 1 +
vl.c| 118 +---
4 files changed, 145 insertions(+), 118 deletions(-)
create mode 100644 bootdevice.c
diff --git a/Makefile.target b/Makefile.target
index 1e8d7ab..e9ff1ee 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -127,7 +127,7 @@ endif #CONFIG_BSD_USER
# System emulator target
ifdef CONFIG_SOFTMMU
obj-y += arch_init.o cpus.o monitor.o gdbstub.o balloon.o ioport.o numa.o
-obj-y += qtest.o
+obj-y += qtest.o bootdevice.o
obj-y += hw/
obj-$(CONFIG_FDT) += device_tree.o
obj-$(CONFIG_KVM) += kvm-all.o
diff --git a/bootdevice.c b/bootdevice.c
new file mode 100644
index 000..d5b8789
--- /dev/null
+++ b/bootdevice.c
@@ -0,0 +1,142 @@
+/*
+ * QEMU Boot Device Implement
+ *
+ * Copyright (c) 2014 HUAWEI TECHNOLOGIES CO.,LTD.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include sysemu/sysemu.h
+
+typedef struct FWBootEntry FWBootEntry;
+
+struct FWBootEntry {
+QTAILQ_ENTRY(FWBootEntry) link;
+int32_t bootindex;
+DeviceState *dev;
+char *suffix;
+};
+
+static QTAILQ_HEAD(, FWBootEntry) fw_boot_order =
+QTAILQ_HEAD_INITIALIZER(fw_boot_order);
+
+void add_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+FWBootEntry *node, *i;
+
+if (bootindex 0) {
+return;
+}
+
+assert(dev != NULL || suffix != NULL);
+
+node = g_malloc0(sizeof(FWBootEntry));
+node-bootindex = bootindex;
+node-suffix = g_strdup(suffix);
+node-dev = dev;
+
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (i-bootindex == bootindex) {
+fprintf(stderr, Two devices with same boot index %d\n,
bootindex);
+exit(1);
+} else if (i-bootindex bootindex) {
+continue;
+}
+QTAILQ_INSERT_BEFORE(i, node, link);
+return;
+}
+QTAILQ_INSERT_TAIL(fw_boot_order, node, link);
+}
+
+DeviceState *get_boot_device(uint32_t position)
+{
+uint32_t counter = 0;
+FWBootEntry *i = NULL;
+DeviceState *res = NULL;
+
+if (!QTAILQ_EMPTY(fw_boot_order)) {
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (counter == position) {
+res = i-dev;
+break;
+}
+counter++;
+}
+}
+return res;
+}
+
+/*
+ * This function returns null terminated string that consist of new line
+ * separated device paths.
+ *
+ * memory pointed by size is assigned total length of the array in bytes
+ *
+ */
+char *get_boot_devices_list(size_t *size, bool ignore_suffixes)
+{
+FWBootEntry *i;
+size_t total = 0;
+char *list = NULL;
+
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+char *devpath = NULL, *bootpath;
+size_t len;
+
+if (i-dev) {
+devpath = qdev_get_fw_dev_path(i-dev);
+assert(devpath);
+}
+
+if (i-suffix !ignore_suffixes devpath) {
+size_t bootpathlen = strlen(devpath) + strlen(i-suffix) + 1;
+
+bootpath = g_malloc(bootpathlen);
+snprintf(bootpath, bootpathlen, %s%s, devpath, i-suffix);
+g_free(devpath);
+} else if (devpath) {
+bootpath = devpath;
+} else if (!ignore_suffixes) {
+assert(i-suffix);
+bootpath = g_strdup(i-suffix);
+} else {
+bootpath = g_strdup();
+}
+
+if (total) {
+list[total-1] = '\n';
+}
+len = strlen(bootpath) + 1;
+list = g_realloc(list, total + len);
+memcpy(list[total], bootpath, len);
+total += len;
+g_free(bootpath);
+}
+
+*size = total;
+
+if (boot_strict
[Qemu-devel] [PATCH v10 15/30] vmxnet3: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/net/vmxnet3.c | 8
1 file changed, 8 insertions(+)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index f246fa1..88e9d9c 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2177,6 +2177,13 @@ static int vmxnet3_pci_init(PCIDevice *pci_dev)
return 0;
}
+static void vmxnet3_instance_init(Object *obj)
+{
+VMXNET3State *s = VMXNET3(obj);
+device_add_bootindex_property(obj, s-conf.bootindex,
+ bootindex, /ethernet-phy@0,
+ DEVICE(obj), NULL);
+}
static void vmxnet3_pci_uninit(PCIDevice *pci_dev)
{
@@ -2524,6 +2531,7 @@ static const TypeInfo vmxnet3_info = {
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(VMXNET3State),
.class_init= vmxnet3_class_init,
+.instance_init = vmxnet3_instance_init,
};
static void vmxnet3_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 08/30] virtio-net: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/net/virtio-net.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 826a2a5..f5f6bf7 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1716,6 +1716,9 @@ static void virtio_net_instance_init(Object *obj)
* Can be overriden with virtio_net_set_config_size.
*/
n-config_size = sizeof(struct virtio_net_config);
+device_add_bootindex_property(obj, n-nic_conf.bootindex,
+ bootindex, /ethernet-phy@0,
+ DEVICE(n), NULL);
}
static Property virtio_net_properties[] = {
--
1.7.12.4
[Qemu-devel] [PATCH v10 11/30] ne2000: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/net/ne2000.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/net/ne2000.c b/hw/net/ne2000.c
index a62d12d..62b86af 100644
--- a/hw/net/ne2000.c
+++ b/hw/net/ne2000.c
@@ -752,6 +752,17 @@ static void pci_ne2000_exit(PCIDevice *pci_dev)
qemu_free_irq(s-irq);
}
+static void ne2000_instance_init(Object *obj)
+{
+PCIDevice *pci_dev = PCI_DEVICE(obj);
+PCINE2000State *d = DO_UPCAST(PCINE2000State, dev, pci_dev);
+NE2000State *s = d-ne2000;
+
+device_add_bootindex_property(obj, s-c.bootindex,
+ bootindex, /ethernet-phy@0,
+ pci_dev-qdev, NULL);
+}
+
static Property ne2000_properties[] = {
DEFINE_NIC_PROPERTIES(PCINE2000State, ne2000.c),
DEFINE_PROP_END_OF_LIST(),
@@ -778,6 +789,7 @@ static const TypeInfo ne2000_info = {
.parent= TYPE_PCI_DEVICE,
.instance_size = sizeof(PCINE2000State),
.class_init= ne2000_class_init,
+.instance_init = ne2000_instance_init,
};
static void ne2000_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 26/30] virtio-blk: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/block/virtio-blk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index a7f2827..9d04590 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -805,6 +805,9 @@ static void virtio_blk_instance_init(Object *obj)
(Object **)s-blk.iothread,
qdev_prop_allow_set_link_before_realize,
OBJ_PROP_LINK_UNREF_ON_RELEASE, NULL);
+device_add_bootindex_property(obj, s-conf-bootindex,
+ bootindex, /disk@0,0,
+ DEVICE(obj), NULL);
}
static Property virtio_blk_properties[] = {
--
1.7.12.4
[Qemu-devel] [PATCH v10 14/30] spapr_lian: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/net/spapr_llan.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
index 23c47d3..0ff159b 100644
--- a/hw/net/spapr_llan.c
+++ b/hw/net/spapr_llan.c
@@ -226,6 +226,15 @@ static int spapr_vlan_init(VIOsPAPRDevice *sdev)
return 0;
}
+static void spapr_vlan_instance_init(Object *obj)
+{
+VIOsPAPRVLANDevice *dev = VIO_SPAPR_VLAN_DEVICE(obj);
+
+device_add_bootindex_property(obj, dev-nicconf.bootindex,
+ bootindex, ,
+ DEVICE(dev), NULL);
+}
+
void spapr_vlan_create(VIOsPAPRBus *bus, NICInfo *nd)
{
DeviceState *dev;
@@ -553,6 +562,7 @@ static const TypeInfo spapr_vlan_info = {
.parent= TYPE_VIO_SPAPR_DEVICE,
.instance_size = sizeof(VIOsPAPRVLANDevice),
.class_init= spapr_vlan_class_init,
+.instance_init = spapr_vlan_instance_init,
};
static void spapr_vlan_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 19/30] host-libusb: remove bootindex property from qdev to qom
From: Gonglei arei.gong...@huawei.com
Remove bootindex form qdev property to qom, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/usb/host-libusb.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
index c189147..dff86ac 100644
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -980,6 +980,16 @@ static int usb_host_initfn(USBDevice *udev)
return 0;
}
+static void usb_host_instance_init(Object *obj)
+{
+USBDevice *udev = USB_DEVICE(obj);
+USBHostDevice *s = USB_HOST_DEVICE(udev);
+
+device_add_bootindex_property(obj, s-bootindex,
+ bootindex, NULL,
+ udev-qdev, NULL);
+}
+
static void usb_host_handle_destroy(USBDevice *udev)
{
USBHostDevice *s = USB_HOST_DEVICE(udev);
@@ -1464,7 +1474,6 @@ static Property usb_host_dev_properties[] = {
DEFINE_PROP_UINT32(productid, USBHostDevice, match.product_id, 0),
DEFINE_PROP_UINT32(isobufs, USBHostDevice, iso_urb_count,4),
DEFINE_PROP_UINT32(isobsize, USBHostDevice, iso_urb_frames, 32),
-DEFINE_PROP_INT32(bootindex, USBHostDevice, bootindex,-1),
DEFINE_PROP_UINT32(loglevel, USBHostDevice, loglevel,
LIBUSB_LOG_LEVEL_WARNING),
DEFINE_PROP_BIT(pipeline,USBHostDevice, options,
@@ -1497,6 +1506,7 @@ static TypeInfo usb_host_dev_info = {
.parent= TYPE_USB_DEVICE,
.instance_size = sizeof(USBHostDevice),
.class_init= usb_host_class_initfn,
+.instance_init = usb_host_instance_init,
};
static void usb_host_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 16/30] usb-net: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/usb/dev-network.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 518d536..0dd4df7 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -1376,6 +1376,16 @@ static int usb_net_initfn(USBDevice *dev)
return 0;
}
+static void usb_net_instance_init(Object *obj)
+{
+USBDevice *dev = USB_DEVICE(obj);
+USBNetState *s = DO_UPCAST(USBNetState, dev, dev);
+
+device_add_bootindex_property(obj, s-conf.bootindex,
+ bootindex, /ethernet-phy@0,
+ dev-qdev, NULL);
+}
+
static USBDevice *usb_net_init(USBBus *bus, const char *cmdline)
{
Error *local_err = NULL;
@@ -1439,6 +1449,7 @@ static const TypeInfo net_info = {
.parent= TYPE_USB_DEVICE,
.instance_size = sizeof(USBNetState),
.class_init= usb_net_class_initfn,
+.instance_init = usb_net_instance_init,
};
static void usb_net_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 24/30] scsi: add bootindex to qom property
From: Gonglei arei.gong...@huawei.com
Add a qom property with the same name 'bootindex',
when we remove it form qdev property, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/scsi/scsi-bus.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 954c607..2a37d78 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -1997,6 +1997,16 @@ static void scsi_device_class_init(ObjectClass *klass,
void *data)
k-props = scsi_props;
}
+static void scsi_dev_instance_init(Object *obj)
+{
+DeviceState *dev = DEVICE(obj);
+SCSIDevice *s = DO_UPCAST(SCSIDevice, qdev, dev);
+
+device_add_bootindex_property(obj, s-conf.bootindex,
+ bootindex, NULL,
+ s-qdev, NULL);
+}
+
static const TypeInfo scsi_device_type_info = {
.name = TYPE_SCSI_DEVICE,
.parent = TYPE_DEVICE,
@@ -2004,6 +2014,7 @@ static const TypeInfo scsi_device_type_info = {
.abstract = true,
.class_size = sizeof(SCSIDeviceClass),
.class_init = scsi_device_class_init,
+.instance_init = scsi_dev_instance_init,
};
static void scsi_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 18/30] virtio-net: alias bootindex property explicitly for virt-net-pci/ccw/s390
From: Gonglei arei.gong...@huawei.com
Since the bootindex property is a QOM property and not a qdev property
now, we must alias it explicitly for virtio-net-pci, as well as CCW and
s390-virtio.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/s390x/s390-virtio-bus.c | 2 ++
hw/s390x/virtio-ccw.c | 2 ++
hw/virtio/virtio-pci.c | 2 ++
3 files changed, 6 insertions(+)
diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index ca682bb..35498d0 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -163,6 +163,8 @@ static void s390_virtio_net_instance_init(Object *obj)
object_property_add_child(obj, virtio-backend, OBJECT(dev-vdev), NULL);
object_unref(OBJECT(dev-vdev));
qdev_alias_all_properties(DEVICE(dev-vdev), obj);
+object_property_add_alias(obj, bootindex, OBJECT(dev-vdev),
+ bootindex, error_abort);
}
static int s390_virtio_blk_init(VirtIOS390Device *s390_dev)
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index c074f64..5c53121 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -796,6 +796,8 @@ static void virtio_ccw_net_instance_init(Object *obj)
object_property_add_child(obj, virtio-backend, OBJECT(dev-vdev), NULL);
object_unref(OBJECT(dev-vdev));
qdev_alias_all_properties(DEVICE(dev-vdev), obj);
+object_property_add_alias(obj, bootindex, OBJECT(dev-vdev),
+ bootindex, error_abort);
}
static int virtio_ccw_blk_init(VirtioCcwDevice *ccw_dev)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index e6cdaca..2c4f7e8 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1459,6 +1459,8 @@ static void virtio_net_pci_instance_init(Object *obj)
object_property_add_child(obj, virtio-backend, OBJECT(dev-vdev), NULL);
object_unref(OBJECT(dev-vdev));
qdev_alias_all_properties(DEVICE(dev-vdev), obj);
+object_property_add_alias(obj, bootindex, OBJECT(dev-vdev),
+ bootindex, error_abort);
}
static const TypeInfo virtio_net_pci_info = {
--
1.7.12.4
[Qemu-devel] [PATCH v10 17/30] net: remove bootindex property from qdev to qom
From: Gonglei arei.gong...@huawei.com
Remove bootindex form qdev property to qom, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
include/net/net.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/net/net.h b/include/net/net.h
index ed594f9..008d610 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -36,8 +36,7 @@ typedef struct NICConf {
#define DEFINE_NIC_PROPERTIES(_state, _conf)\
DEFINE_PROP_MACADDR(mac, _state, _conf.macaddr),\
DEFINE_PROP_VLAN(vlan, _state, _conf.peers), \
-DEFINE_PROP_NETDEV(netdev, _state, _conf.peers), \
-DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1)
+DEFINE_PROP_NETDEV(netdev, _state, _conf.peers)
/* Net clients */
--
1.7.12.4
[Qemu-devel] [PATCH v10 27/30] block: remove bootindex property from qdev to qom
From: Gonglei arei.gong...@huawei.com
Remove bootindex form qdev property to qom, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/scsi/scsi-disk.c | 1 -
hw/scsi/scsi-generic.c | 1 -
include/hw/block/block.h | 1 -
3 files changed, 3 deletions(-)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index e34a544..893e186 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -2680,7 +2680,6 @@ static const TypeInfo scsi_cd_info = {
#ifdef __linux__
static Property scsi_block_properties[] = {
DEFINE_PROP_DRIVE(drive, SCSIDiskState, qdev.conf.bs),
-DEFINE_PROP_INT32(bootindex, SCSIDiskState, qdev.conf.bootindex, -1),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/scsi/scsi-generic.c b/hw/scsi/scsi-generic.c
index 20587b4..a95f53e 100644
--- a/hw/scsi/scsi-generic.c
+++ b/hw/scsi/scsi-generic.c
@@ -482,7 +482,6 @@ static SCSIRequest *scsi_new_request(SCSIDevice *d,
uint32_t tag, uint32_t lun,
static Property scsi_generic_properties[] = {
DEFINE_PROP_DRIVE(drive, SCSIDevice, conf.bs),
-DEFINE_PROP_INT32(bootindex, SCSIDevice, conf.bootindex, -1),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/include/hw/block/block.h b/include/hw/block/block.h
index 3a01488..867a226 100644
--- a/include/hw/block/block.h
+++ b/include/hw/block/block.h
@@ -49,7 +49,6 @@ static inline unsigned int get_physical_block_exp(BlockConf
*conf)
_conf.physical_block_size, 512), \
DEFINE_PROP_UINT16(min_io_size, _state, _conf.min_io_size, 0), \
DEFINE_PROP_UINT32(opt_io_size, _state, _conf.opt_io_size, 0),\
-DEFINE_PROP_INT32(bootindex, _state, _conf.bootindex, -1),\
DEFINE_PROP_UINT32(discard_granularity, _state, \
_conf.discard_granularity, -1)
--
1.7.12.4
[Qemu-devel] [PATCH v10 20/30] pci-assign: remove bootindex property from qdev to qom
From: Gonglei arei.gong...@huawei.com
Remove bootindex form qdev property to qom, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/i386/kvm/pci-assign.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index 17c7d6dc..bf59caf 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -1850,13 +1850,22 @@ static void assigned_exitfn(struct PCIDevice *pci_dev)
free_assigned_device(dev);
}
+static void assigned_dev_instance_init(Object *obj)
+{
+PCIDevice *pci_dev = PCI_DEVICE(obj);
+AssignedDevice *d = DO_UPCAST(AssignedDevice, dev, PCI_DEVICE(obj));
+
+device_add_bootindex_property(obj, d-bootindex,
+ bootindex, NULL,
+ pci_dev-qdev, NULL);
+}
+
static Property assigned_dev_properties[] = {
DEFINE_PROP_PCI_HOST_DEVADDR(host, AssignedDevice, host),
DEFINE_PROP_BIT(prefer_msi, AssignedDevice, features,
ASSIGNED_DEVICE_PREFER_MSI_BIT, false),
DEFINE_PROP_BIT(share_intx, AssignedDevice, features,
ASSIGNED_DEVICE_SHARE_INTX_BIT, true),
-DEFINE_PROP_INT32(bootindex, AssignedDevice, bootindex, -1),
DEFINE_PROP_STRING(configfd, AssignedDevice, configfd_name),
DEFINE_PROP_END_OF_LIST(),
};
@@ -1882,6 +1891,7 @@ static const TypeInfo assign_info = {
.parent = TYPE_PCI_DEVICE,
.instance_size = sizeof(AssignedDevice),
.class_init = assign_class_init,
+.instance_init = assigned_dev_instance_init,
};
static void assign_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 23/30] isa-fdc: remove bootindexA/B property from qdev to qom
From: Gonglei arei.gong...@huawei.com
Remove bootindexA/B form qdev property to qom, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/block/fdc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/hw/block/fdc.c b/hw/block/fdc.c
index 490d127..cb31cf7 100644
--- a/hw/block/fdc.c
+++ b/hw/block/fdc.c
@@ -2217,8 +2217,6 @@ static Property isa_fdc_properties[] = {
DEFINE_PROP_UINT32(dma, FDCtrlISABus, dma, 2),
DEFINE_PROP_DRIVE(driveA, FDCtrlISABus, state.drives[0].bs),
DEFINE_PROP_DRIVE(driveB, FDCtrlISABus, state.drives[1].bs),
-DEFINE_PROP_INT32(bootindexA, FDCtrlISABus, bootindexA, -1),
-DEFINE_PROP_INT32(bootindexB, FDCtrlISABus, bootindexB, -1),
DEFINE_PROP_BIT(check_media_rate, FDCtrlISABus, state.check_media_rate,
0, true),
DEFINE_PROP_END_OF_LIST(),
@@ -2236,11 +2234,24 @@ static void isabus_fdc_class_init(ObjectClass *klass,
void *data)
set_bit(DEVICE_CATEGORY_STORAGE, dc-categories);
}
+static void isabus_fdc_instance_init(Object *obj)
+{
+FDCtrlISABus *isa = ISA_FDC(obj);
+
+device_add_bootindex_property(obj, isa-bootindexA,
+ bootindexA, /floppy@0,
+ DEVICE(obj), NULL);
+device_add_bootindex_property(obj, isa-bootindexB,
+ bootindexB, /floppy@1,
+ DEVICE(obj), NULL);
+}
+
static const TypeInfo isa_fdc_info = {
.name = TYPE_ISA_FDC,
.parent= TYPE_ISA_DEVICE,
.instance_size = sizeof(FDCtrlISABus),
.class_init= isabus_fdc_class_init,
+.instance_init = isabus_fdc_instance_init,
};
static const VMStateDescription vmstate_sysbus_fdc ={
--
1.7.12.4
[Qemu-devel] [PATCH v10 22/30] redirect: remove bootindex property from qdev to qom
From: Gonglei arei.gong...@huawei.com
Remove bootindex form qdev property to qom, things will
continue to work just fine, and we can use qom features
which are not supported by qdev property.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
hw/usb/redirect.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 44522d9..c1b685a 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -2468,7 +2468,6 @@ static Property usbredir_properties[] = {
DEFINE_PROP_CHR(chardev, USBRedirDevice, cs),
DEFINE_PROP_UINT8(debug, USBRedirDevice, debug, usbredirparser_warning),
DEFINE_PROP_STRING(filter, USBRedirDevice, filter_str),
-DEFINE_PROP_INT32(bootindex, USBRedirDevice, bootindex, -1),
DEFINE_PROP_END_OF_LIST(),
};
@@ -2493,11 +2492,22 @@ static void usbredir_class_initfn(ObjectClass *klass,
void *data)
set_bit(DEVICE_CATEGORY_MISC, dc-categories);
}
+static void usbredir_instance_init(Object *obj)
+{
+USBDevice *udev = USB_DEVICE(obj);
+USBRedirDevice *dev = DO_UPCAST(USBRedirDevice, dev, udev);
+
+device_add_bootindex_property(obj, dev-bootindex,
+ bootindex, NULL,
+ udev-qdev, NULL);
+}
+
static const TypeInfo usbredir_dev_info = {
.name = usb-redir,
.parent= TYPE_USB_DEVICE,
.instance_size = sizeof(USBRedirDevice),
.class_init= usbredir_class_initfn,
+.instance_init = usbredir_instance_init,
};
static void usbredir_register_types(void)
--
1.7.12.4
[Qemu-devel] [PATCH v10 30/30] bootindex: delete bootindex when device is removed
From: Gonglei arei.gong...@huawei.com
Device should be removed from global boot list when
it is hot-unplugged.
Signed-off-by: Gonglei arei.gong...@huawei.com
---
bootdevice.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/bootdevice.c b/bootdevice.c
index db72098..f816259 100644
--- a/bootdevice.c
+++ b/bootdevice.c
@@ -225,6 +225,8 @@ static void property_release_bootindex(Object *obj, const
char *name,
{
BootIndexProperty *prop = opaque;
+
+del_boot_device_path(prop-dev, prop-suffix);
g_free(prop);
}
--
1.7.12.4
[Qemu-devel] checkpatch.pl false positive
Hi,
Hooked up checkpatch to my testbuild-patch-series script.
Catched some issues, now trapped into what I think is a false positive:
ERROR: Macros with complex values should be enclosed in parenthesis
#995: FILE: include/hw/virtio/virtio-gpu.h:99:
+#define DEFINE_VIRTIO_GPU_PCI_PROPERTIES(_state) \
+DEFINE_PROP_BIT(ioeventfd, _state, flags,\
+VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, false), \
+DEFINE_PROP_UINT32(vectors, _state, nvectors, 4)
enclosing into parenthesis just isn't going to fly here as this is an
array snipped, not some piece of code we could wrap into the usual
{ $code } while (0).
cheers,
Gerd
Re: [Qemu-devel] checkpatch.pl false positive
On 12 September 2014 11:35, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
Hooked up checkpatch to my testbuild-patch-series script.
Catched some issues, now trapped into what I think is a false positive:
ERROR: Macros with complex values should be enclosed in parenthesis
#995: FILE: include/hw/virtio/virtio-gpu.h:99:
+#define DEFINE_VIRTIO_GPU_PCI_PROPERTIES(_state) \
+DEFINE_PROP_BIT(ioeventfd, _state, flags,\
+VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, false), \
+DEFINE_PROP_UINT32(vectors, _state, nvectors, 4)
enclosing into parenthesis just isn't going to fly here as this is an
array snipped, not some piece of code we could wrap into the usual
{ $code } while (0).
Yes, I think we should just expect that checkpatch is sometimes
going to get confused by complex macros. It's never going to
be 100% accurate.
-- PMM
Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file
Hi,
@@ -0,0 +1,158 @@
+#ifndef VIRTGPU_HW_H
+#define VIRTGPU_HW_H
Non-trivial file, deserves a copyright and license notice.
Added.
+
+enum virtgpu_ctrl_type {
+VIRTGPU_UNDEFINED = 0,
+
+/* 2d commands */
+VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100,
Please consider also adding:
#define VIRTGPU_CMD_GET_DISPLAY_INFO VIRTGPU_CMD_GET_DISPLAY_INFO
and friends. It makes it MUCH nicer for application software to probe
for later extensions if every member of the enum is also associated with
a preprocessor macro.
I don't think this will ever be shipped as library header for external
users ...
+struct virtgpu_ctrl_hdr {
+uint32_t type;
+uint32_t flags;
+uint64_t fence_id;
+uint32_t ctx_id;
+uint32_t padding;
+};
+
Is the padding to ensure that this is aligned regardless of 32-bit or
64-bit hosts?
Yes.
Is it worth adding a compile-time assertion about the
size of the struct to ensure the compiler doesn't add any additional
padding?
Makes sense. What is the usual trick to do that?
thanks,
Gerd
Re: [Qemu-devel] [RFC V2 10/10] cpus: reclaim allocated vCPU objects
During plugging we can see this event: echo 1 cpu8/online. But during unplugging , we can't see the event echo 0 cpu8/online. Just for additional check, in my code I have added following udev rule echo 0 cpu[0-9]*/online. May be this is of any help. Thanks Anshul Makkar On Fri, Sep 12, 2014 at 11:53 AM, Gu Zheng guz.f...@cn.fujitsu.com wrote: Hi Bharata, On 09/12/2014 04:09 PM, Bharata B Rao wrote: On Fri, Sep 12, 2014 at 6:54 AM, Gu Zheng guz.f...@cn.fujitsu.com wrote: Is guest os enabled acpi cpu hotplug? What's the guest's cpu info? Please try latest QEMU, and any feedback is welcome. Tried with latest QEMU git + your patchset and Fedora 20 guest, but QEMU monitor still shows the removed CPU. Guest kernel messages during hotplug: [root@localhost cpu]# echo 1 cpu8/online [ 72.936069] smpboot: Booting Node 0 Processor 8 APIC 0x8 [0.003000] kvm-clock: cpu 8, msr 0:7ffc9201, secondary cpu clock [ 72.950003] TSC synchronization [CPU#0 - CPU#8]: [ 72.950003] Measured 199886723309 cycles TSC warp between CPUs, turning off TSC clock. [ 72.950003] tsc: Marking TSC unstable due to check_tsc_sync_source failed [ 72.972976] KVM setup async PF for cpu 8 [ 72.973648] kvm-stealtime: cpu 8, msr 7d30df00 [ 72.974415] Will online and init hotplugged CPU: 8 [ 72.975307] microcode: CPU8 sig=0x663, pf=0x1, revision=0x1 Guest kernel messages during hotunplug: [root@localhost cpu]# [ 95.482172] Unregister pv shared memory for cpu 8 [ 95.487169] smpboot: CPU 8 is now offline [ 95.488667] ACPI: Device does not support D3cold Guest cpuinfo (showing for the last CPU only after adding and removing CPU 8) processor: 7 vendor_id: GenuineIntel cpu family: 6 model: 6 model name: QEMU Virtual CPU version 2.1.50 stepping: 3 microcode: 0x1 cpu MHz: 2899.998 cache size: 4096 KB fpu: yes fpu_exception: yes cpuid level: 4 wp: yes flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni cx16 x2apic popcnt hypervisor lahf_lm bogomips: 5799.99 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: Guest ejected CPU 8 successfully. I confirmed it with the same environment as yours, it works well. Could you please offer your QEMU config and the guest start cmd? It may help me to investigate the issue. Thanks, Gu [root@localhost boot]# grep -ir hot config-3.11.10-301.fc20.x86_64 CONFIG_TICK_ONESHOT=y # CONFIG_MEMORY_HOTPLUG is not set CONFIG_HOTPLUG_CPU=y # CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set # CONFIG_DEBUG_HOTPLUG_CPU0 is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_HOTPLUG_PCI_ACPI_IBM=m # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_SHPC=m .
[Qemu-devel] [PATCH v2] Add skip_dump flag to ignore memory region during dump
The PCI MMIO might be disabled or the device in the reset state.
Make sure we do not dump these memory regions.
Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com
---
V1:
* Make the flag generic in place of using vfio_mmap (Alex)
hw/misc/vfio.c| 1 +
include/exec/memory.h | 19 +++
memory.c | 11 +++
memory_mapping.c | 3 ++-
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
index d69bb29..c9c0398 100644
--- a/hw/misc/vfio.c
+++ b/hw/misc/vfio.c
@@ -2722,6 +2722,7 @@ static int vfio_mmap_bar(VFIODevice *vdev, VFIOBAR *bar,
}
memory_region_init_ram_ptr(submem, OBJECT(vdev), name, size, *map);
+memory_region_set_skip_dump(submem);
} else {
empty_region:
/* Create a zero sized sub-region to make cleanup easy. */
diff --git a/include/exec/memory.h b/include/exec/memory.h
index fc6e93d..2b5c1f2 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -144,6 +144,7 @@ struct MemoryRegion {
bool terminates;
bool romd_mode;
bool ram;
+bool skip_dump;
bool readonly; /* For RAM regions */
bool enabled;
bool rom_device;
@@ -434,6 +435,24 @@ uint64_t memory_region_size(MemoryRegion *mr);
bool memory_region_is_ram(MemoryRegion *mr);
/**
+ * memory_region_is_skip_dump: check whether a memory region should not be
+ * dumped
+ *
+ * Returns %true is a memory region should not be dumped(e.g. VFIO BAR MMAP).
+ *
+ * @mr: the memory region being queried
+ */
+bool memory_region_is_skip_dump(MemoryRegion *mr);
+
+/**
+ * memory_region_set_skip_dump: Set skip_dump flag, dump will ignore this
memory
+ * region
+ *
+ * @mr: the memory region being queried
+ */
+void memory_region_set_skip_dump(MemoryRegion *mr);
+
+/**
* memory_region_is_romd: check whether a memory region is in ROMD mode
*
* Returns %true if a memory region is a ROM device and currently set to allow
diff --git a/memory.c b/memory.c
index 664d3e6..cbd8cad 100644
--- a/memory.c
+++ b/memory.c
@@ -847,6 +847,7 @@ void memory_region_init(MemoryRegion *mr,
mr-enabled = true;
mr-terminates = false;
mr-ram = false;
+mr-skip_dump = false;
mr-romd_mode = true;
mr-readonly = false;
mr-rom_device = false;
@@ -1032,6 +1033,11 @@ void memory_region_init_ram_ptr(MemoryRegion *mr,
mr-ram_addr = qemu_ram_alloc_from_ptr(size, ptr, mr);
}
+void memory_region_set_skip_dump(MemoryRegion *mr)
+{
+mr-skip_dump = true;
+}
+
void memory_region_init_alias(MemoryRegion *mr,
Object *owner,
const char *name,
@@ -1129,6 +1135,11 @@ bool memory_region_is_ram(MemoryRegion *mr)
return mr-ram;
}
+bool memory_region_is_skip_dump(MemoryRegion *mr)
+{
+return mr-skip_dump;
+}
+
bool memory_region_is_logging(MemoryRegion *mr)
{
return mr-dirty_log_mask;
diff --git a/memory_mapping.c b/memory_mapping.c
index 87a6ed5..7b69801 100644
--- a/memory_mapping.c
+++ b/memory_mapping.c
@@ -203,7 +203,8 @@ static void guest_phys_blocks_region_add(MemoryListener
*listener,
GuestPhysBlock *predecessor;
/* we only care about RAM */
-if (!memory_region_is_ram(section-mr)) {
+if (!memory_region_is_ram(section-mr) ||
+memory_region_is_skip_dump(section-mr)) {
return;
}
--
1.8.3.1
Re: [Qemu-devel] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt
Hi, +++ b/docs/specs/virtio-gpu.txt @@ -0,0 +1,165 @@ +virtio-gpu specification I know you are just following existing bad practice in this directory, but it would be nice to declare copyright and license on this file. Added copyright for now. Dunno about license, IIRC GPLv2 isn't good for text, suggestions? + This creates a 2D resource on the host with the specified width, + height and format. Only a small subset of formats are support. The s/support/supported/ and can you delineate that subset? enum virtgpu_formats (text updated). + This sets the scanout parameters for a single scanout. The + resource_id is the resource to be scanned out from, along with a + rectangle specified by x, y, width and height. Is it worth a mention here or generically up front where 0,0 is in relation to the screen, and in which direction positive numbers move? I'm assuming 0,0 is top left, and larger x moves right, larger y moves down. Correct. Text updated. Are there restrictions against rectangles that overlap beyond screen boundaries? Backing resource must cover the scanout completely. With multiple heads (and therefore multiple scanouts) it is legal for the scanouts to overlap or even be identical (= screen mirroring). Text updated. thanks, Gerd
Re: [Qemu-devel] Microcheckpointing: Memory-VCPU / Disk State consistency
On Thu, Sep 11, 2014 at 06:44:08PM +0100, Dr. David Alan Gilbert wrote: (I've cc'd in Fam, Stefan, and Kevin for Block stuff, and Yang and Eddie for Colo) * Walid Nouri (walid.no...@gmail.com) wrote: Hello Michael, Hello Paolo i have ???studied??? the available documentation/Information and tried to get an idea of the QEMU live block operation possibilities. I think the MC protocol doesn???t need synchronous block device replication because primary and secondary VM are not synchronous. The state of the primary is allays ahead of the state of the secondary. When the primary is in epoch(n) the secondary is in epoch(n-1). Note that I haven't followed the microcheckpointing or COLO discussions so I'm not aware of those designs... What MC needs is a block device agnostic, controlled and asynchronous approach for replicating the contents of block devices and its state changes to the secondary VM while the primary VM is running. Asynchronous block transfer is important to allow maximum performance for the primary VM, while keeping the secondary VM updated with state changes. The block device replication should be possible in two stages or modes. The first stage is the live copy of all block devices of the primary to the secondary. This is necessary if the secondary doesn???t have an existing image which is in sync with the primary at the time MC has started. This is not very convenient but as far as I know actually there is no mechanism for persistent dirty bitmap in QEMU. I think you are trying to address the non-shared storage cause where the secondary needs to acquire the initial state of the primary. drive-mirror copies the contents of a source disk image to a destination. If the guest is running while copying takes place then new writes will also be mirrored. drive-mirror should be sufficient for the initial phase where primary and secondary get in sync. Fam Zheng sent a patch series earlier this year to add dirty bitmaps for block devices to QEMU. It only supported in-memory bitmaps but persistent bitmaps are fairly straightforward to implement. I'm interested in these patches for the incremental backup use case. https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg05250.html I guess the reason you mention persistent bitmaps is to save time when adding a host that previously participated and has an older version of the disk image? The second stage (mode) is the replication of block device state changes (modified blocks) to keep the image on the secondary in sync with the primary. The mirrored blocks must be buffered in ram (block buffer) until the complete Checkpoint (RAM, vCPU, device state) can be committed. For keeping the complete system state consistent on the secondary system there must be a possibility for MC to commit/discard block device state changes. In normal operation the mirrored block device state changes (block buffer) are committed to disk when the complete checkpoint is committed. In case of a crash of the primary system while transferring a checkpoint the data in the block buffer corresponding to the failed Checkpoint must be discarded. Thoughts: Writing data safely to disk can take milliseconds. Not sure how that figures into your commit step, but I guess commit needs to be fast. I/O requests happen in parallel with CPU execution, so could an I/O request be pending across a checkpoint commit? Live migration does not migrate inflight requests, although it has special case code for migration requests that have failed at the host level and need to be retried. Another way of putting this is that live migration uses bdrv_drain_all() to quiesce disks before migrating device state - I don't think you have that luxury since bdrv_drain_all() can take a long time and is not suitable for microcheckpointing. Block devices have the following semantics: 1. There is no ordering between parallel in-flight I/O requests. 2. The guest sees the disk state for completed writes but it may not see disk state of in-flight writes (due to #1). 3. Completed writes are only guaranteed to be persistent across power failure if a disk cache flush was submitted and completed after the writes completed. I think this can be achieved by drive-mirror and a filter block driver. Another approach could be to exploit the block migration functionality of live migration with a filter block driver. block-migration.c should be avoided because it may be dropped from QEMU. It is unloved code and has been replaced by drive-mirror. The drive-mirror (and live migration) does not rely on shared storage and allow live block device copy and incremental syncing. A block buffer can be implemented with a QEMU filter block driver. It should sit at the same position as the Quorum driver in the block driver hierarchy. When using block filter approach MC will be transparent and block device agnostic.
Re: [Qemu-devel] [RFC PATCH 11/17] COLO ctl: implement colo checkpoint protocol
* Hongyang Yang (yan...@cn.fujitsu.com) wrote:
??? 08/01/2014 11:03 PM, Dr. David Alan Gilbert ??:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
snip
+static int do_colo_transaction(MigrationState *s, QEMUFile *control,
+ QEMUFile *trans)
+{
+int ret;
+
+ret = colo_ctl_put(s-file, COLO_CHECKPOINT_NEW);
+if (ret) {
+goto out;
+}
+
+ret = colo_ctl_get(control, COLO_CHECKPOINT_SUSPENDED);
What happens at this point if the slave just doesn't respond?
(i.e. the socket doesn't drop - you just don't get the byte).
If the socket return bytes that were not expected, exit. If
socket return error, do some cleanup and quit COLO process.
refer to: colo_ctl_get() and colo_ctl_get_value()
But what happens if the slave just doesn't respond at all; e.g.
if the slave host loses power, it'll take a while (many seconds)
before the socket will timeout.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCHv2 1/4] BlockLimits: introduce max_transfer_length
Signed-off-by: Peter Lieven p...@kamp.de
Reviewed-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
block.c |4
include/block/block_int.h |3 +++
2 files changed, 7 insertions(+)
diff --git a/block.c b/block.c
index d06dd51..c87e9fd 100644
--- a/block.c
+++ b/block.c
@@ -529,6 +529,7 @@ void bdrv_refresh_limits(BlockDriverState *bs, Error **errp)
return;
}
bs-bl.opt_transfer_length = bs-file-bl.opt_transfer_length;
+bs-bl.max_transfer_length = bs-file-bl.max_transfer_length;
bs-bl.opt_mem_alignment = bs-file-bl.opt_mem_alignment;
} else {
bs-bl.opt_mem_alignment = 512;
@@ -543,6 +544,9 @@ void bdrv_refresh_limits(BlockDriverState *bs, Error **errp)
bs-bl.opt_transfer_length =
MAX(bs-bl.opt_transfer_length,
bs-backing_hd-bl.opt_transfer_length);
+bs-bl.max_transfer_length =
+MIN(bs-bl.max_transfer_length,
+bs-backing_hd-bl.max_transfer_length);
bs-bl.opt_mem_alignment =
MAX(bs-bl.opt_mem_alignment,
bs-backing_hd-bl.opt_mem_alignment);
diff --git a/include/block/block_int.h b/include/block/block_int.h
index 8a61215..e178782 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -288,6 +288,9 @@ typedef struct BlockLimits {
/* optimal transfer length in sectors */
int opt_transfer_length;
+/* maximal transfer length in sectors */
+int max_transfer_length;
+
/* memory alignment so that no bounce buffer is needed */
size_t opt_mem_alignment;
} BlockLimits;
--
1.7.9.5
[Qemu-devel] [PATCHv2 4/4] block: avoid creating oversized writes in multiwrite_merge
Signed-off-by: Peter Lieven p...@kamp.de
Reviewed-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
block.c |5 +
1 file changed, 5 insertions(+)
diff --git a/block.c b/block.c
index 965e9bc..2b9be99 100644
--- a/block.c
+++ b/block.c
@@ -4554,6 +4554,11 @@ static int multiwrite_merge(BlockDriverState *bs,
BlockRequest *reqs,
merge = 0;
}
+if (bs-bl.max_transfer_length reqs[outidx].nb_sectors +
+reqs[i].nb_sectors bs-bl.max_transfer_length) {
+merge = 0;
+}
+
if (merge) {
size_t size;
QEMUIOVector *qiov = g_malloc0(sizeof(*qiov));
--
1.7.9.5
[Qemu-devel] [PATCHv2 3/4] block/iscsi: set max_transfer_length
the limit of 0xff for 16 byte CDBs is intentional to
avoid overflows on 32-bit architectures.
Signed-off-by: Peter Lieven p...@kamp.de
Reviewed-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
block/iscsi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 3e19202..a4b625c 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1455,10 +1455,18 @@ static void iscsi_close(BlockDriverState *bs)
static void iscsi_refresh_limits(BlockDriverState *bs, Error **errp)
{
-IscsiLun *iscsilun = bs-opaque;
-
/* We don't actually refresh here, but just return data queried in
* iscsi_open(): iscsi targets don't change their limits. */
+
+IscsiLun *iscsilun = bs-opaque;
+uint32_t max_xfer_len = iscsilun-use_16_for_rw ? 0xff : 0x;
+
+if (iscsilun-bl.max_xfer_len) {
+max_xfer_len = MIN(max_xfer_len, iscsilun-bl.max_xfer_len);
+}
+
+bs-bl.max_transfer_length = sector_lun2qemu(max_xfer_len, iscsilun);
+
if (iscsilun-lbp.lbpu) {
if (iscsilun-bl.max_unmap 0x) {
bs-bl.max_discard = sector_lun2qemu(iscsilun-bl.max_unmap,
--
1.7.9.5
[Qemu-devel] [PATCHv2 0/4] introduce max_transfer_length
This series adds the basics for introducing a maximum transfer length to the block layer. Its main purpose is currently avoiding that a multiwrite_merge exceeds the max_xfer_len of an attached iSCSI LUN. This is a required bug fix. Discussed reporting of this maximum in the SCSI Disk Inquiry Emulation of the Block Limits VPD is currently not added as we do not import any of the other limits there. This has to be addresses in a seperate series. v1-v2: do not throw errors but generate trace events in Patch 2 [Paolo] Peter Lieven (4): BlockLimits: introduce max_transfer_length block: immediately cancel oversized read/write requests block/iscsi: set max_transfer_length block: avoid creating oversized writes in multiwrite_merge block.c | 23 +++ block/iscsi.c | 12 ++-- include/block/block_int.h |3 +++ trace-events |2 ++ 4 files changed, 38 insertions(+), 2 deletions(-) -- 1.7.9.5
[Qemu-devel] [PATCHv2 2/4] block: immediately cancel oversized read/write requests
Signed-off-by: Peter Lieven p...@kamp.de
---
block.c | 14 ++
trace-events |2 ++
2 files changed, 16 insertions(+)
diff --git a/block.c b/block.c
index c87e9fd..965e9bc 100644
--- a/block.c
+++ b/block.c
@@ -3215,6 +3215,13 @@ static int coroutine_fn
bdrv_co_do_readv(BlockDriverState *bs,
return -EINVAL;
}
+if (bs-bl.max_transfer_length
+nb_sectors bs-bl.max_transfer_length) {
+trace_bdrv_co_do_readv_toobig(bs, sector_num, nb_sectors,
+ bs-bl.max_transfer_length);
+return -EINVAL;
+}
+
return bdrv_co_do_preadv(bs, sector_num BDRV_SECTOR_BITS,
nb_sectors BDRV_SECTOR_BITS, qiov, flags);
}
@@ -3507,6 +3514,13 @@ static int coroutine_fn
bdrv_co_do_writev(BlockDriverState *bs,
return -EINVAL;
}
+if (bs-bl.max_transfer_length
+nb_sectors bs-bl.max_transfer_length) {
+trace_bdrv_co_do_writev_toobig(bs, sector_num, nb_sectors,
+ bs-bl.max_transfer_length);
+return -EINVAL;
+}
+
return bdrv_co_do_pwritev(bs, sector_num BDRV_SECTOR_BITS,
nb_sectors BDRV_SECTOR_BITS, qiov, flags);
}
diff --git a/trace-events b/trace-events
index fb58963..fe2c5d8 100644
--- a/trace-events
+++ b/trace-events
@@ -68,8 +68,10 @@ bdrv_aio_writev(void *bs, int64_t sector_num, int
nb_sectors, void *opaque) bs
bdrv_aio_write_zeroes(void *bs, int64_t sector_num, int nb_sectors, int flags,
void *opaque) bs %p sector_num %PRId64 nb_sectors %d flags %#x opaque %p
bdrv_lock_medium(void *bs, bool locked) bs %p locked %d
bdrv_co_readv(void *bs, int64_t sector_num, int nb_sector) bs %p sector_num
%PRId64 nb_sectors %d
+bdrv_co_do_readv_toobig(void *bs, int64_t sector_num, int nb_sector, int
max_transfer_length) bs %p sector_num %PRId64 nb_sectors %d
bs-bl.max_transfer_length %d
bdrv_co_copy_on_readv(void *bs, int64_t sector_num, int nb_sector) bs %p
sector_num %PRId64 nb_sectors %d
bdrv_co_writev(void *bs, int64_t sector_num, int nb_sector) bs %p sector_num
%PRId64 nb_sectors %d
+bdrv_co_do_writev_toobig(void *bs, int64_t sector_num, int nb_sector, int
max_transfer_length) bs %p sector_num %PRId64 nb_sectors %d
bs-bl.max_transfer_length %d
bdrv_co_write_zeroes(void *bs, int64_t sector_num, int nb_sector, int flags)
bs %p sector_num %PRId64 nb_sectors %d flags %#x
bdrv_co_io_em(void *bs, int64_t sector_num, int nb_sectors, int is_write, void
*acb) bs %p sector_num %PRId64 nb_sectors %d is_write %d acb %p
bdrv_co_do_copy_on_readv(void *bs, int64_t sector_num, int nb_sectors, int64_t
cluster_sector_num, int cluster_nb_sectors) bs %p sector_num %PRId64
nb_sectors %d cluster_sector_num %PRId64 cluster_nb_sectors %d
--
1.7.9.5
Re: [Qemu-devel] [PATCH v3 03/47] Start documenting how postcopy works.
* Hongyang Yang (yan...@cn.fujitsu.com) wrote: ??? 08/28/2014 11:03 PM, Dr. David Alan Gilbert (git) ??: From: Dr. David Alan Gilbert dgilb...@redhat.com Signed-off-by: Dr. David Alan Gilbert dgilb...@redhat.com --- +Postcopy can be combined with precopy (i.e. normal migration) so that if precopy +doesn't finish in a given time the switch is automatically made to precopy. I think you mean automatically made to postcopy here? Thanks! +Source behaviour + +Until postcopy is entered the migration stream is identical to normal postcopy, +except for the addition of a 'postcopy advise' command at the beginning to +let the destination know that postcopy might happen. When postcopy starts A comma here? Yes, thanks. Dave +the source sends the page discard data and then forms the 'package' containing: + + Command: 'postcopy ram listen' + The device state + A series of sections, identical to the precopy streams device state stream + containing everything except postcopiable devices (i.e. RAM) + Command: 'postcopy ram run' + +The 'package' is sent as the data part of a Command: 'CMD_PACKAGED', and the +contents are formatted in the same way as the main migration stream. + +Destination behaviour + +Initially the destination looks the same as precopy, with a single thread +reading the migration stream; the 'postcopy advise' and 'discard' commands +are processed to change the way RAM is managed, but don't affect the stream +processing. + +-- +1 2 3 4 5 6 7 +main -DISCARD-CMD_PACKAGED ( LISTEN DEVICE DEVICE DEVICE RUN ) +thread | | + | (page request) + |\___ + v\ +listen thread: --- page -- page -- page -- page -- page -- + + a bc +-- + +On receipt of CMD_PACKAGED (1) + All the data associated with the package - the ( ... ) section in the +diagram - is read into memory (into a QEMUSizedBuffer), and the main thread +recurses into qemu_loadvm_state_main to process the contents of the package (2) +which contains commands (3,6) and devices (4...) + +On receipt of 'postcopy ram listen' - 3 -(i.e. the 1st command in the package) +a new thread (a) is started that takes over servicing the migration stream, +while the main thread carries on loading the package. It loads normal +background page data (b) but if during a device load a fault happens (5) the +returned page (c) is loaded by the listen thread allowing the main threads +device load to carry on. + +The last thing in the CMD_PACKAGED is a 'RUN' command (6) letting the destination +CPUs start running. +At the end of the CMD_PACKAGED (7) the main thread returns to normal running behaviour +and is no longer used by migration, while the listen thread carries +on servicing page data until the end of migration. + +=== Postcopy states === + +Postcopy moves through a series of states (see postcopy_ram_state) +from ADVISE-LISTEN-RUNNING-END + + Advise: Set at the start of migration if postcopy is enabled, even + if it hasn't had the start command; here the destination + checks that its OS has the support needed for postcopy, and performs + setup to ensure the RAM mappings are suitable for later postcopy. + (Triggered by reception of POSTCOPY_RAM_ADVISE command) + + Listen: The first command in the package, POSTCOPY_RAM_LISTEN, switches + the destination state to Listen, and starts a new thread + (the 'listen thread') which takes over the job of receiving + pages off the migration stream, while the main thread carries + on processing the blob. With this thread able to process page + reception, the destination now 'sensitises' the RAM to detect + any access to missing pages (on Linux using the 'userfault' + system). + + Running: POSTCOPY_RAM_RUN causes the destination to synchronise all + state and start the CPUs and IO devices running. The main + thread now finishes processing the migration package and + now carries on as it would for normal precopy migration + (although it can't do the cleanup it would do as it + finishes a normal migration). + + End: The listen thread can now quit, and perform the cleanup of migration + state, the migration is now complete. + +=== Source side page maps === + +The source side keeps two bitmaps during postcopy; 'the migration bitmap' +and 'sent map'. The 'migration bitmap' is basically the same as in
Re: [Qemu-devel] [PATCH v10 00/30] modify boot order of guest, and take effect after rebooting
Subject: Re: [PATCH v10 00/30] modify boot order of guest, and take effect after rebooting On Fr, 2014-09-12 at 17:35 +0800, arei.gong...@huawei.com wrote: From: Gonglei arei.gong...@huawei.com Sometimes, we want to modify boot order of a guest, but no need to shutdown it. We can call dynamic changing bootindex of a guest, which can be assured taking effect just after the guest rebooting. For example, in P2V scene, we boot a guest and then attach a new system disk, for copying some thing. We want to assign the new disk as the booting disk, which means its bootindex=1. Looks fine to me. Reviewed-by: Gerd Hoffmann kra...@redhat.com Thanks a lot! :) Best regards, -Gonglei cheers, Gerd
Re: [Qemu-devel] [virtio-dev] [PATCH 2/2] virtio-gpu/2d: add docs/specs/virtio-gpu.txt
On Fr, 2014-09-12 at 10:10 +0100, Stefan Hajnoczi wrote: On Thu, Sep 11, 2014 at 05:09:33PM +0200, Gerd Hoffmann wrote: diff --git a/docs/specs/virtio-gpu.txt b/docs/specs/virtio-gpu.txt new file mode 100644 index 000..9455383 --- /dev/null +++ b/docs/specs/virtio-gpu.txt @@ -0,0 +1,165 @@ +virtio-gpu specification + This document refers to the implementation for structs and does not fully document the semantics of the virtqueue commands. Mixing the implementation and specification is risky since implementation changes cannot be checked against the specification. In order to make this document self-contained you need to define the struct layouts. Error conditions and corner cases are not documented for the virtqueue commands. I've asked about a few of them below, but there more are required to make this specification complete enough so someone else could write a compatible implementation. Ok. The short-term goal for this text is to help reviewing the code by documenting how the device is supposed to work. Being good enough for an independent implementation is the next level. I'll keep it on the radar though. +VIRTGPU_CMD_RESOURCE_CREATE_2D: + Command: struct virtgpu_resource_create_2d + + Create a 2D resource on the host. + + This creates a 2D resource on the host with the specified width, + height and format. Only a small subset of formats are support. The + resource ids are generated by the guest. Can the host refuse due to lack of resources? Yes. virtgpu_ctrl_hdr.type in the response will be set to VIRTGPU_RESP_ERR_* then. Current implementation does that only on malloc() failure, there is no accounting (yet) to limit the amout of memory the guest is allowed to allocate. /me notes to write a section on error handling. +VIRTGPU_CMD_SET_SCANOUT: + Command: struct virtgpu_set_scanout + + Set the scanout parameters for a single output. + + This sets the scanout parameters for a single scanout. The + resource_id is the resource to be scanned out from, along with a + rectangle specified by x, y, width and height. What if x, y, width, and height are out-of-range for the given resource? You'll get an error. What if width and height exceed the scanout width and height? Using only a subrectangle of the resource for the scanout is legal. Is it possible to unset the scanout for a resource? Yes, use resource_id 0. Can a resource be set on multiple scanouts? Yes. Does VIRTGPU_CMD_SET_SCANOUT need to be called between every VIRTGPU_CMD_RESOURCE_FLUSH or is does the assignment persist? Assignment is persistent. + the backing store for a resource. These pages are then used for the + transfer operations for that resource from that point on. + +VIRTGPU_CMD_RESOURCE_INVAL_BACKING: + Command: struct virtgpu_resource_inval_backing Why is it called INVAL_BACKING instead of DETACH_BACKING? Detach is logical since there is also an attach command. No particular reason I think. Dave? cheers, Gerd
Re: [Qemu-devel] [RFC PATCH 11/17] COLO ctl: implement colo checkpoint protocol
在 09/12/2014 07:17 PM, Dr. David Alan Gilbert 写道:
* Hongyang Yang (yan...@cn.fujitsu.com) wrote:
??? 08/01/2014 11:03 PM, Dr. David Alan Gilbert ??:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
snip
+static int do_colo_transaction(MigrationState *s, QEMUFile *control,
+ QEMUFile *trans)
+{
+int ret;
+
+ret = colo_ctl_put(s-file, COLO_CHECKPOINT_NEW);
+if (ret) {
+goto out;
+}
+
+ret = colo_ctl_get(control, COLO_CHECKPOINT_SUSPENDED);
What happens at this point if the slave just doesn't respond?
(i.e. the socket doesn't drop - you just don't get the byte).
If the socket return bytes that were not expected, exit. If
socket return error, do some cleanup and quit COLO process.
refer to: colo_ctl_get() and colo_ctl_get_value()
But what happens if the slave just doesn't respond at all; e.g.
if the slave host loses power, it'll take a while (many seconds)
before the socket will timeout.
It will wait until the call returns timeout error, and then do some
cleanup and quit COLO process. There may be better way to handle
this?
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
.
--
Thanks,
Yang.
Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests
Am 08.09.2014 um 18:29 schrieb Paolo Bonzini: Il 08/09/2014 18:18, Peter Lieven ha scritto: When copying data, gparted will try using very large I/O sizes. Of course if something breaks it will just use a smaller size, but it would make performance worse. I tried now (with local storage, not virtual---but with such large block sizes it's disk bound anyway, one request can take 0.1 seconds to execute) and a 2 MB block size is 20% slower than 16 MB block size on your usual 3.5 rotational SATA disk. can you share with what command exactly you ran these tests? i tried myself and found that without multiwrite_merge i was not able to create a request bigger than 0x sectors from inside linux. On a different machine: $ time dd if=/dev/zero of=test bs=16777216 count=30 oflag=direct real 0m13.497s user 0m0.001s sys 0m0.541s $ time dd if=/dev/zero of=test2 bs=1048576 count=480 oflag=direct real 0m15.835s user 0m0.005s sys 0m0.770s The bigger block size is 17% faster; for disk-to-disk copy: $ time dd if=test of=test3 bs=16777216 count=30 iflag=direct oflag=direct real 0m26.075s user 0m0.001s sys 0m0.678s $ time dd if=test2 of=test4 bs=1048576 count=480 iflag=direct oflag=direct real 0m45.210s user 0m0.005s sys 0m1.145s The bigger block size is 73% faster. I perfectly believe that 16MB blocksize is faster than 2MB. That is true for iSCSI as well. However, I do not see requests of this size coming in via virtio-blk when I ran: dd if=/dev/zero of=test bs=16777216 count=30 oflag=direct. As you can see from the multiwrite_merge trace the merging has never been stopped because of the max_transfer_length. The question is, why are the I/O requests not coming in as specified? multiwrite_merge: num_reqs 15 - 1 iscsi_co_writev: sector_num 0 nb_sectors 15360 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 17 - 1 iscsi_co_writev: sector_num 15360 nb_sectors 17408 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 11 - 1 iscsi_co_writev: sector_num 32768 nb_sectors 11264 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 19 - 1 iscsi_co_writev: sector_num 44032 nb_sectors 19456 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 2 - 1 iscsi_co_writev: sector_num 63488 nb_sectors 2048 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 12 - 1 iscsi_co_writev: sector_num 65536 nb_sectors 12288 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 18 - 1 iscsi_co_writev: sector_num 77824 nb_sectors 18432 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 2 - 1 iscsi_co_writev: sector_num 96256 nb_sectors 2048 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 12 - 1 iscsi_co_writev: sector_num 98304 nb_sectors 12288 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 19 - 1 iscsi_co_writev: sector_num 110592 nb_sectors 19456 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 1 - 1 iscsi_co_writev: sector_num 130048 nb_sectors 1024 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 11 - 1 iscsi_co_writev: sector_num 131072 nb_sectors 11264 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 19 - 1 iscsi_co_writev: sector_num 142336 nb_sectors 19456 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 2 - 1 iscsi_co_writev: sector_num 161792 nb_sectors 2048 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 12 - 1 iscsi_co_writev: sector_num 163840 nb_sectors 12288 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 19 - 1 iscsi_co_writev: sector_num 176128 nb_sectors 19456 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 1 - 1 iscsi_co_writev: sector_num 195584 nb_sectors 1024 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 7 - 1 iscsi_co_writev: sector_num 196608 nb_sectors 7168 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 18 - 1 iscsi_co_writev: sector_num 203776 nb_sectors 18432 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 7 - 1 iscsi_co_writev: sector_num 08 nb_sectors 7168 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 11 - 1 iscsi_co_writev: sector_num 229376 nb_sectors 11264 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 19 - 1 iscsi_co_writev: sector_num 240640 nb_sectors 19456 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 2 - 1 iscsi_co_writev: sector_num 260096 nb_sectors 2048 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 11 - 1 iscsi_co_writev: sector_num 262144 nb_sectors 11264 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 18 - 1 iscsi_co_writev: sector_num 273408 nb_sectors 18432 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 3 - 1 iscsi_co_writev: sector_num 291840 nb_sectors 3072 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 12 - 1 iscsi_co_writev: sector_num 294912 nb_sectors 12288 bs-bl.max_transfer_length 65535 multiwrite_merge: num_reqs 19 - 1 iscsi_co_writev: sector_num
Re: [Qemu-devel] [PATCH v2 0/9] virtio: fix virtio child recount in transports
Ping...
Any comments will be appreciated!
Best regards,
-Gonglei
-Original Message-
From: Gonglei (Arei)
Sent: Tuesday, September 09, 2014 2:35 PM
To: qemu-devel@nongnu.org
Cc: m...@redhat.com; pbonz...@redhat.com; stefa...@redhat.com;
Huangweidong (C); ag...@suse.de; Huangpeng (Peter); r...@twiddle.net;
cornelia.h...@de.ibm.com; borntrae...@de.ibm.com; Luonengjun; Gonglei
(Arei)
Subject: [PATCH v2 0/9] virtio: fix virtio child recount in transports
From: Gonglei arei.gong...@huawei.com
virtio-$device-{pci, s390, ccw} all duplicate the
qdev properties of their virtio child. This approach does
not work well with string or pointer properties since we
must be careful about leaking or double-freeing them.
Use the QOM alias property to forward property accesses to the
VirtIORNG child. This way no duplication is necessary.
For their child, object_initialize() leaves the object with a refcount of 1.
object_property_add_child() adds its own reference which is dropped
again when the property is deleted.
The upshot of this is that we always have a refcount = 1. Upon hot
unplug the virtio-$device child is not finalized!
Drop our reference after the child property has been added to the
parent.
The v1 as below:
http://lists.gnu.org/archive/html/qemu-devel/2014-09/msg01208.html
Changes since v1:
1. using alias properties avoid to double-free property.(Stefan)
2. add handling all other virtio-devices had the same probleam.
3. same handling for CCW and s390-virito.
Acknowledgements:
I copied Stefan's commit message about virtio-blk which summarized
reasons very well, I cannot agree more with him. Holp Stefan do not
mind, thank you so much!
Gonglei (9):
virtio-net: use aliases instead of duplicate qdev properties
virtio: fix virtio-net child refcount in transports
virtio/vhost scsi: use aliases instead of duplicate qdev properties
virtio/vhost-scsi: fix virtio-scsi/vhost-scsi child refcount in
transports
virtio-serial: use aliases instead of duplicate qdev properties
virtio-serial: fix virtio-serial child refcount in transports
virtio-rng: use aliases instead of duplicate qdev properties
virtio-rng: fix virtio-rng child refcount in transports
virtio-balloon: fix virtio-balloon child refcount in transports
hw/s390x/s390-virtio-bus.c | 16 ++--
hw/s390x/virtio-ccw.c | 18 +++---
hw/virtio/virtio-pci.c | 18 +++---
3 files changed, 32 insertions(+), 20 deletions(-)
--
1.7.12.4
Re: [Qemu-devel] [RFC PATCH 11/17] COLO ctl: implement colo checkpoint protocol
* Hongyang Yang (yan...@cn.fujitsu.com) wrote:
??? 09/12/2014 07:17 PM, Dr. David Alan Gilbert ??:
* Hongyang Yang (yan...@cn.fujitsu.com) wrote:
??? 08/01/2014 11:03 PM, Dr. David Alan Gilbert ??:
* Yang Hongyang (yan...@cn.fujitsu.com) wrote:
snip
+static int do_colo_transaction(MigrationState *s, QEMUFile *control,
+ QEMUFile *trans)
+{
+int ret;
+
+ret = colo_ctl_put(s-file, COLO_CHECKPOINT_NEW);
+if (ret) {
+goto out;
+}
+
+ret = colo_ctl_get(control, COLO_CHECKPOINT_SUSPENDED);
What happens at this point if the slave just doesn't respond?
(i.e. the socket doesn't drop - you just don't get the byte).
If the socket return bytes that were not expected, exit. If
socket return error, do some cleanup and quit COLO process.
refer to: colo_ctl_get() and colo_ctl_get_value()
But what happens if the slave just doesn't respond at all; e.g.
if the slave host loses power, it'll take a while (many seconds)
before the socket will timeout.
It will wait until the call returns timeout error, and then do some
cleanup and quit COLO process.
If it was to wait here for ~30seconds for the timeout what would happen
to the primary? Would it be stopped from sending any network traffic
for those 30 seconds - I think that's too long to fail over.
There may be better way to handle this?
In postcopy I always take reads coming back from the destination
in a separate thread, because that thread can't block the main thread
going out (I originally did that using async reads but the thread
is nicer). You could also use something like a poll() with a shorter
timeout to however long you are happy for COLO to go before it fails.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [PATCH 0/2] target-arm: implement architectural breakpoints
Implement support for the ARM architecturally mandated hardware breakpoints, for ARMv8 and ARMv7. Tested that hardware bps work for both v7 and v8 kernels (including v8 compat userspace in a 32 bit kernel). There are a few odd subfeatures which we don't implement (yet): * address-mismatch breakpoints which fire if the PC is anything other than the specified value * address-mismatch breakpoints with zero byte-address-select, which fire for every single instruction execution * unlinked context match breakpoints, which fire for every instruction executed with a particular value of CONTEXTIDR/VMID These aren't used by Linux's ptrace support, and I wasn't sure of the best way to implement them, so for now they just produce a LOG_UNIMP warning if the guest tries to use them. This patchset sits on target-arm.next (ie after the watchpoint code). Peter Maydell (2): target-arm: Implement setting guest breakpoints target-arm: Implement handling of breakpoint firing target-arm/cpu.c | 1 + target-arm/cpu.h | 1 + target-arm/helper.c| 126 - target-arm/internals.h | 15 ++ target-arm/machine.c | 1 + target-arm/op_helper.c | 75 +++-- 6 files changed, 202 insertions(+), 17 deletions(-) -- 1.9.1
[Qemu-devel] [PATCH 2/2] target-arm: Implement handling of breakpoint firing
Implement handling of breakpoint event firing to correctly
inject the debug exception into the guest.
Since the breakpoint and watchpoint control register format is
very similar we adjust wp_matches() to also handle breakpoints
as well rather than using a separate function.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/internals.h | 6
target-arm/op_helper.c | 75 --
2 files changed, 66 insertions(+), 15 deletions(-)
diff --git a/target-arm/internals.h b/target-arm/internals.h
index b7e4822..986a7b1 100644
--- a/target-arm/internals.h
+++ b/target-arm/internals.h
@@ -313,6 +313,12 @@ static inline uint32_t syn_watchpoint(int same_el, int cm,
int wnr)
| (cm 8) | (wnr 6) | 0x22;
}
+static inline uint32_t syn_breakpoint(int same_el)
+{
+return (EC_BREAKPOINT ARM_EL_EC_SHIFT) | (same_el ARM_EL_EC_SHIFT)
+| ARM_EL_IL | 0x22;
+}
+
/* Update a QEMU watchpoint based on the information the guest has set in the
* DBGWCRn_EL1 and DBGWVRn_EL1 registers.
*/
diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
index b956216..d0bcd97 100644
--- a/target-arm/op_helper.c
+++ b/target-arm/op_helper.c
@@ -511,32 +511,43 @@ static bool linked_bp_matches(ARMCPU *cpu, int lbn)
return false;
}
-static bool wp_matches(ARMCPU *cpu, int n)
+static bool bp_wp_matches(ARMCPU *cpu, int n, bool is_wp)
{
CPUARMState *env = cpu-env;
-uint64_t wcr = env-cp15.dbgwcr[n];
+uint64_t cr;
int pac, hmc, ssc, wt, lbn;
/* TODO: check against CPU security state when we implement TrustZone */
bool is_secure = false;
-if (!env-cpu_watchpoint[n]
-|| !(env-cpu_watchpoint[n]-flags BP_WATCHPOINT_HIT)) {
-return false;
-}
+if (is_wp) {
+if (!env-cpu_watchpoint[n]
+|| !(env-cpu_watchpoint[n]-flags BP_WATCHPOINT_HIT)) {
+return false;
+}
+cr = env-cp15.dbgwcr[n];
+} else {
+uint64_t pc = is_a64(env) ? env-pc : env-regs[15];
+if (!env-cpu_breakpoint[n] || env-cpu_breakpoint[n]-pc != pc) {
+return false;
+}
+cr = env-cp15.dbgbcr[n];
+}
/* The WATCHPOINT_HIT flag guarantees us that the watchpoint is
- * enabled and that the address and access type match; check the
- * remaining fields, including linked breakpoints.
- * Note that some combinations of {PAC, HMC SSC} are reserved and
+ * enabled and that the address and access type match; for breakpoints
+ * we know the address matched; check the remaining fields, including
+ * linked breakpoints. We rely on WCR and BCR having the same layout
+ * for the LBN, SSC, HMC, PAC/PMC and is-linked fields.
+ * Note that some combinations of {PAC, HMC, SSC} are reserved and
* must act either like some valid combination or as if the watchpoint
* were disabled. We choose the former, and use this together with
* the fact that EL3 must always be Secure and EL2 must always be
* Non-Secure to simplify the code slightly compared to the full
* table in the ARM ARM.
*/
-pac = extract64(wcr, 1, 2);
-hmc = extract64(wcr, 13, 1);
-ssc = extract64(wcr, 14, 2);
+pac = extract64(cr, 1, 2);
+hmc = extract64(cr, 13, 1);
+ssc = extract64(cr, 14, 2);
switch (ssc) {
case 0:
@@ -560,6 +571,7 @@ static bool wp_matches(ARMCPU *cpu, int n)
* Implementing this would require reworking the core watchpoint code
* to plumb the mmu_idx through to this point. Luckily Linux does not
* rely on this behaviour currently.
+ * For breakpoints we do want to use the current CPU state.
*/
switch (arm_current_pl(env)) {
case 3:
@@ -582,8 +594,8 @@ static bool wp_matches(ARMCPU *cpu, int n)
g_assert_not_reached();
}
-wt = extract64(wcr, 20, 1);
-lbn = extract64(wcr, 16, 4);
+wt = extract64(cr, 20, 1);
+lbn = extract64(cr, 16, 4);
if (wt !linked_bp_matches(cpu, lbn)) {
return false;
@@ -606,7 +618,28 @@ static bool check_watchpoints(ARMCPU *cpu)
}
for (n = 0; n ARRAY_SIZE(env-cpu_watchpoint); n++) {
-if (wp_matches(cpu, n)) {
+if (bp_wp_matches(cpu, n, true)) {
+return true;
+}
+}
+return false;
+}
+
+static bool check_breakpoints(ARMCPU *cpu)
+{
+CPUARMState *env = cpu-env;
+int n;
+
+/* If breakpoints are disabled globally or we can't take debug
+ * exceptions here then breakpoint firings are ignored.
+ */
+if (extract32(env-cp15.mdscr_el1, 15, 1) == 0
+|| !arm_generate_debug_exceptions(env)) {
+return false;
+}
+
+for (n = 0; n ARRAY_SIZE(env-cpu_breakpoint); n++) {
+if (bp_wp_matches(cpu, n, false)) {
return true;
}
}
@@ -641,6 +674,18 @@ void arm_debug_excp_handler(CPUState *cs)
cpu_resume_from_signal(cs, NULL);
[Qemu-devel] [PATCH 1/2] target-arm: Implement setting guest breakpoints
This patch adds support for setting guest breakpoints
based on values the guest writes to the DBGBVR and DBGBCR
registers. (It doesn't include the code to handle when
these breakpoints fire, so has no guest-visible effect.)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/cpu.c | 1 +
target-arm/cpu.h | 1 +
target-arm/helper.c| 126 -
target-arm/internals.h | 9
target-arm/machine.c | 1 +
5 files changed, 136 insertions(+), 2 deletions(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 7ea12bd..5b5531a 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -185,6 +185,7 @@ static void arm_cpu_reset(CPUState *s)
}
#endif
+hw_breakpoint_update_all(cpu);
hw_watchpoint_update_all(cpu);
}
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index d1e1ccb..fa6ae0a 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -323,6 +323,7 @@ typedef struct CPUARMState {
int eabi;
#endif
+struct CPUBreakpoint *cpu_breakpoint[16];
struct CPUWatchpoint *cpu_watchpoint[16];
CPU_COMMON
diff --git a/target-arm/helper.c b/target-arm/helper.c
index ece9673..d246d36 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2492,6 +2492,124 @@ static void dbgwcr_write(CPUARMState *env, const
ARMCPRegInfo *ri,
hw_watchpoint_update(cpu, i);
}
+void hw_breakpoint_update(ARMCPU *cpu, int n)
+{
+CPUARMState *env = cpu-env;
+uint64_t bvr = env-cp15.dbgbvr[n];
+uint64_t bcr = env-cp15.dbgbcr[n];
+vaddr addr;
+int bt;
+int flags = BP_CPU;
+
+if (env-cpu_breakpoint[n]) {
+cpu_breakpoint_remove_by_ref(CPU(cpu), env-cpu_breakpoint[n]);
+env-cpu_breakpoint[n] = NULL;
+}
+
+if (!extract64(bcr, 0, 1)) {
+/* E bit clear : watchpoint disabled */
+return;
+}
+
+bt = extract64(bcr, 20, 4);
+
+switch (bt) {
+case 4: /* unlinked address mismatch (reserved if AArch64) */
+case 5: /* linked address mismatch (reserved if AArch64) */
+qemu_log_mask(LOG_UNIMP,
+ arm: address mismatch breakpoint types not
implemented);
+return;
+case 0: /* unlinked address match */
+case 1: /* linked address match */
+{
+/* Bits [63:49] are hardwired to the value of bit [48]; that is,
+ * we behave as if the register was sign extended. Bits [1:0] are
+ * RES0. The BAS field is used to allow setting breakpoints on 16
+ * bit wide instructions; it is CONSTRAINED UNPREDICTABLE whether
+ * a bp will fire if the addresses covered by the bp and the addresses
+ * covered by the insn overlap but the insn doesn't start at the
+ * start of the bp address range. We choose to require the insn and
+ * the bp to have the same address. The constraints on writing to
+ * BAS enforced in dbgbcr_write mean we have only four cases:
+ * 0b = no breakpoint
+ * 0b0011 = breakpoint on addr
+ * 0b1100 = breakpoint on addr + 2
+ * 0b = breakpoint on addr
+ * See also figure D2-3 in the v8 ARM ARM (DDI0487A.c).
+ */
+int bas = extract64(bcr, 5, 4);
+addr = sextract64(bvr, 0, 49) ~3ULL;
+if (bas == 0) {
+return;
+}
+if (bas == 0xc) {
+addr += 2;
+}
+break;
+}
+case 2: /* unlinked context ID match */
+case 8: /* unlinked VMID match (reserved if no EL2) */
+case 10: /* unlinked context ID and VMID match (reserved if no EL2) */
+qemu_log_mask(LOG_UNIMP,
+ arm: unlinked context breakpoint types not
implemented);
+return;
+case 9: /* linked VMID match (reserved if no EL2) */
+case 11: /* linked context ID and VMID match (reserved if no EL2) */
+case 3: /* linked context ID match */
+default:
+/* We must generate no events for Linked context matches (unless
+ * they are linked to by some other bp/wp, which is handled in
+ * updates for the linking bp/wp). We choose to also generate no events
+ * for reserved values.
+ */
+return;
+}
+
+cpu_breakpoint_insert(CPU(cpu), addr, flags, env-cpu_breakpoint[n]);
+}
+
+void hw_breakpoint_update_all(ARMCPU *cpu)
+{
+int i;
+CPUARMState *env = cpu-env;
+
+/* Completely clear out existing QEMU breakpoints and our array, to
+ * avoid possible stale entries following migration load.
+ */
+cpu_breakpoint_remove_all(CPU(cpu), BP_CPU);
+memset(env-cpu_breakpoint, 0, sizeof(env-cpu_breakpoint));
+
+for (i = 0; i ARRAY_SIZE(cpu-env.cpu_breakpoint); i++) {
+hw_breakpoint_update(cpu, i);
+}
+}
+
+static void dbgbvr_write(CPUARMState *env, const ARMCPRegInfo *ri,
+ uint64_t value)
+{
+ARMCPU *cpu = arm_env_get_cpu(env);
+int i = ri-crm;
+
+raw_write(env, ri,
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Confirmed - the current kvm.git without any ipipe patch also causes the issue. Trace File attached. ** Attachment added: trace.tgz https://bugs.launchpad.net/qemu/+bug/1366836/+attachment/4202192/+files/trace.tgz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via info registers, nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
Re: [Qemu-devel] [question] virtio-blk performance degradation happened with virito-serial
On Fri, Sep 12, 2014 at 11:21:37AM +0800, Zhang Haoyu wrote: If virtio-blk and virtio-serial share an IRQ, the guest operating system has to check each virtqueue for activity. Maybe there is some inefficiency doing that. AFAIK virtio-serial registers 64 virtqueues (on 31 ports + console) even if everything is unused. That could be the case if MSI is disabled. Do the windows virtio drivers enable MSIs, in their inf file? It depends on the version of the drivers, but it is a reasonable guess at what differs between Linux and Windows. Haoyu, can you give us the output of lspci from a Linux guest? I made a test with fio on rhel-6.5 guest, the same degradation happened too, this degradation can be reproduced on rhel6.5 guest 100%. virtio_console module installed: 64K-write-sequence: 285 MBPS, 4380 IOPS virtio_console module uninstalled: 64K-write-sequence: 370 MBPS, 5670 IOPS I use top -d 1 -H -p qemu-pid to monitor the cpu usage, and found that, virtio_console module installed: qemu main thread cpu usage: 98% virtio_console module uninstalled: qemu main thread cpu usage: 60% perf top -p qemu-pid result, virtio_console module installed: PerfTop:9868 irqs/sec kernel:76.4% exact: 0.0% [4000Hz cycles], (target_pid: 88381) -- 11.80% [kernel] [k] _raw_spin_lock_irqsave 8.42% [kernel] [k] _raw_spin_unlock_irqrestore 7.33% [kernel] [k] fget_light 6.28% [kernel] [k] fput 3.61% [kernel] [k] do_sys_poll 3.30% qemu-system-x86_64 [.] qcow2_check_metadata_overlap 3.10% [kernel] [k] __pollwait 2.15% qemu-system-x86_64 [.] qemu_iohandler_poll 1.44% libglib-2.0.so.0.3200.4 [.] g_array_append_vals 1.36% libc-2.13.so [.] 0x0011fc2a 1.31% libpthread-2.13.so [.] pthread_mutex_lock 1.24% libglib-2.0.so.0.3200.4 [.] 0x0001f961 1.20% libpthread-2.13.so [.] __pthread_mutex_unlock_usercnt 0.99% [kernel] [k] eventfd_poll 0.98% [vdso] [.] 0x0771 0.97% [kernel] [k] remove_wait_queue 0.96% qemu-system-x86_64 [.] qemu_iohandler_fill 0.95% [kernel] [k] add_wait_queue 0.69% [kernel] [k] __srcu_read_lock 0.58% [kernel] [k] poll_freewait 0.57% [kernel] [k] _raw_spin_lock_irq 0.54% [kernel] [k] __srcu_read_unlock 0.47% [kernel] [k] copy_user_enhanced_fast_string 0.46% [kvm_intel] [k] vmx_vcpu_run 0.46% [kvm][k] vcpu_enter_guest 0.42% [kernel] [k] tcp_poll 0.41% [kernel] [k] system_call_after_swapgs 0.40% libglib-2.0.so.0.3200.4 [.] g_slice_alloc 0.40% [kernel] [k] system_call 0.38% libpthread-2.13.so [.] 0xe18d 0.38% libglib-2.0.so.0.3200.4 [.] g_slice_free1 0.38% qemu-system-x86_64 [.] address_space_translate_internal 0.38% [kernel] [k] _raw_spin_lock 0.37% qemu-system-x86_64 [.] phys_page_find 0.36% [kernel] [k] get_page_from_freelist 0.35% [kernel] [k] sock_poll 0.34% [kernel] [k] fsnotify 0.31% libglib-2.0.so.0.3200.4 [.] g_main_context_check 0.30% [kernel] [k] do_direct_IO 0.29% libpthread-2.13.so [.] pthread_getspecific virtio_console module uninstalled: PerfTop:9138 irqs/sec kernel:71.7% exact: 0.0% [4000Hz cycles], (target_pid: 88381) -- 5.72% qemu-system-x86_64 [.] qcow2_check_metadata_overlap 4.51% [kernel] [k] fget_light 3.98% [kernel] [k] _raw_spin_lock_irqsave 2.55% [kernel] [k] fput 2.48% libpthread-2.13.so [.] pthread_mutex_lock 2.46% [kernel] [k] _raw_spin_unlock_irqrestore 2.21% libpthread-2.13.so [.] __pthread_mutex_unlock_usercnt 1.71% [vdso] [.] 0x060c 1.68% libc-2.13.so [.] 0x000e751f 1.64% libglib-2.0.so.0.3200.4 [.] 0x0004fca0 1.20% [kernel] [k] __srcu_read_lock 1.14% [kernel] [k] do_sys_poll 0.96% [kernel] [k] _raw_spin_lock_irq 0.95% [kernel] [k] __pollwait
Re: [Qemu-devel] [PATCH 1/2] virtio-gpu/2d: add hardware spec include file
On 09/12/2014 04:44 AM, Gerd Hoffmann wrote:
+enum virtgpu_ctrl_type {
+VIRTGPU_UNDEFINED = 0,
+
+/* 2d commands */
+VIRTGPU_CMD_GET_DISPLAY_INFO = 0x0100,
Please consider also adding:
#define VIRTGPU_CMD_GET_DISPLAY_INFO VIRTGPU_CMD_GET_DISPLAY_INFO
and friends. It makes it MUCH nicer for application software to probe
for later extensions if every member of the enum is also associated with
a preprocessor macro.
I don't think this will ever be shipped as library header for external
users ...
Fair enough. I wasn't sure, so it didn't hurt to ask.
+struct virtgpu_ctrl_hdr {
+uint32_t type;
+uint32_t flags;
+uint64_t fence_id;
+uint32_t ctx_id;
+uint32_t padding;
+};
+
Is the padding to ensure that this is aligned regardless of 32-bit or
64-bit hosts?
Yes.
Is it worth adding a compile-time assertion about the
size of the struct to ensure the compiler doesn't add any additional
padding?
Makes sense. What is the usual trick to do that?
Among others,
struct dummy {
int size_check : (sizeof(virtgpu_ctrl_hdr) == 24 ? 1 : -1);
};
Since bitfields cannot have a negative size, the compiler will
forcefully fail compilation if the struct size ever changes. Similar
tricks include setting up array bounds that would be negative on
failure, or (inside a function body) declaring a switch that has
colliding case statements on failure. But depending on the set of
compiler warning options in effect, declaring an otherwise unused struct
may be too noisy. So if you need more ideas and a good read, check out
the comments in how gnulib does it (the link mentions GPLv3+, but that
file is also shipped as LGPLv2+ so it is compatible with qemu):
git.savannah.gnu.org/cgit/gnulib.git/tree/lib/verify.h
with an end result that a user just writes:
verify(sizeof(virtgpu_ctrl_hdr) == 24);
and calls it a day.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 10/10] aio-win32: add support for sockets
On Fri, Sep 12, 2014 at 09:39:16AM +0800, TeLeMan wrote:
On Wed, Jul 9, 2014 at 5:53 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Uses the same select/WSAEventSelect scheme as main-loop.c.
WSAEventSelect() is edge-triggered, so it cannot be used
directly, but it is still used as a way to exit from a
blocking g_poll().
Before g_poll() is called, we poll sockets with a non-blocking
select() to achieve the level-triggered semantics we require:
if a socket is ready, the g_poll() is made non-blocking too.
Based on a patch from Or Goshen.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
aio-win32.c | 150
++--
block/Makefile.objs | 2 -
include/block/aio.h | 2 -
3 files changed, 145 insertions(+), 9 deletions(-)
diff --git a/aio-win32.c b/aio-win32.c
index 4542270..61e3d2d 100644
--- a/aio-win32.c
+++ b/aio-win32.c
@@ -183,6 +318,7 @@ bool aio_poll(AioContext *ctx, bool blocking)
/* wait until next event */
while (count 0) {
+HANDLE event;
int ret;
timeout = blocking
@@ -196,13 +332,17 @@ bool aio_poll(AioContext *ctx, bool blocking)
first = false;
/* if we have any signaled events, dispatch event */
-if ((DWORD) (ret - WAIT_OBJECT_0) = count) {
+event = NULL;
+if ((DWORD) (ret - WAIT_OBJECT_0) count) {
+event = events[ret - WAIT_OBJECT_0];
+} else if (!have_select_revents) {
when (ret - WAIT_OBJECT_0) = count and have_select_revents is true,
the following events[ret - WAIT_OBJECT_0] will be overflowed.
Thanks for your review. Paolo has hardware problems and is travelling
next week.
Are you able to send patches to fix these issues?
Thanks,
Stefan
pgpsQlbaRLMdU.pgp
Description: PGP signature
