gmane.comp.emulators.qemu

Re: [PATCH v3 0/8] block: drive-backup live backupcommand

Dietmar Maurer — 2013-05-22T15:34:18

I also consider it safer, because you make sure the data exists (using hash keys like SHA1).

I am unsure how you can check if a dirty bitmap contains errors, or is out of date?

Also, you can compare arbitrary Merkle trees, whereas a dirty bitmap is always related to a single image.
(consider the user remove the latest backup from the backup target).

Re: New targets (was: [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line)

Peter Maydell — 2013-05-22T15:33:39

I think the bar should probably be at about "either can run some
plausible set of Linux binaries in user mode, or can run some
softmmu image (eg linux with a minimal config", whichever the
target submitter prefers. Basically something plausibly useful
to somebody other than the developer.

thanks

Re: [libvirt] [qemu-devel] Default machine type setting for ppc64

Li Zhang — 2013-05-22T15:26:38

Hi Anthony,

Currently, to resolve this problem, can we set 'pseries' as default?
Because mac99 doesn't work at all on our platform.

Thanks. :)

[PATCH] monitor: allow to disable the default monitor

Luiz Capitulino — 2013-05-22T15:19:50

Signed-off-by: Luiz Capitulino <lcapitulino< at >redhat.com>
---
 qemu-options.hx | 1 +
 vl.c            | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index fb3961d..bf94862 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
< at >< at > -2528,6 +2528,7 < at >< at > Redirect the monitor to host device < at >var{dev} (same devices as the
 serial port).
 The default device is < at >code{vc} in graphical mode and < at >code{stdio} in
 non graphical mode.
+Use < at >code{-monitor none} to disable the default monitor.
 ETEXI
 DEF("qmp", HAS_ARG, QEMU_OPTION_qmp, \
     "-qmp dev        like -monitor but opens in 'control' mode\n",
diff --git a/vl.c b/vl.c
index 59dc0b4..510d2c2 100644
--- a/vl.c
+++ b/vl.c
< at >< at > -3366,8 +3366,10 < at >< at > int main(int argc, char **argv, char **envp)
                     break;
                 }
             case QEMU_OPTION_monitor:
-                monitor_parse(optarg, "readline");
                 default_monitor = 0;
+                if (strncmp(optarg, "none", 4)) {
+                    monitor_parse(optarg, "readline");
+                }
                 break;
             case QEMU_OPTION_qmp:
                 monitor_parse(optarg, "control");

Re: [PATCH v3 0/8] block: drive-backup live backupcommand

Dietmar Maurer — 2013-05-22T15:10:33

yes, but we need 'snapshots' and something more optimized (rsync compared the whole files). 
I think this can be implemented using the backup job with a specialized backup driver.

[PATCH] block/curl.c: Refuse to open the handle forwrites.

Richard W.M. Jones — 2013-05-22T15:01:21

From: "Richard W.M. Jones" <rjones< at >redhat.com>

---
 block/curl.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/block/curl.c b/block/curl.c
index b8935fd..f1e302b 100644
--- a/block/curl.c
+++ b/block/curl.c
< at >< at > -406,6 +406,10 < at >< at > static int curl_open(BlockDriverState *bs, QDict *options, int flags)
 
     static int inited = 0;
 
+    if (flags & BDRV_O_RDWR) {
+        return -ENOTSUP;
+    }
+
     opts = qemu_opts_create_nofail(&runtime_opts);
     qemu_opts_absorb_qdict(opts, options, &local_err);
     if (error_is_set(&local_err)) {

Re: [PATCH] hw/9pfs: Use O_NOFOLLOW when opening files on server

Stefan Hajnoczi — 2013-05-22T14:54:55

Why is the root path not allowed to be a symlink?

And if so, it would be more user-friendly to resolve the path before
open.  That way we don't need to bug the user with an error here.

Re: New targets (was: [PATCH] qapi-schema.json:Reformat TargetType enum to one-per-line)

Anthony Liguori — 2013-05-22T14:48:59


Aren't most of our target incomplete by some standard?

I thought the typical approach for a target was to get linux-user
working first, and then go for softmmu.  As long as linux-user can run
application, I think it's fair game for merging.


I think that's far too high of a hurdle.

Regards,

Anthony Liguori

Re: RFC: Full introspection support for QMP

Kevin Wolf — 2013-05-22T14:44:48

Am 22.05.2013 um 15:40 hat Amos Kong geschrieben:

Yes, the schema as defined in qapi-schema.json should be good to be sent
over the wire.

Maybe we should already now consider that we'll want to have a dynamic
schema eventually: Depending on which modules are compiled in (or even
which modules are loaded when we go forward with shared libraries), some
types, commands or enum values may be available or not.

For example, libvirt wants to query which block drivers it can use. It
doesn't really matter for which drivers we had the source initially, but
only which drivers are compiled in (possibly loaded) and can actually be
used.


Maybe a (shortened) example for the complete schema version? I assume it
will be just an array of the structs you showed here?

Kevin

Re: [PATCH 0/9 v3] Make monitor command 'dump-guest-memory' dump in kdump-compressed format

Andreas Färber — 2013-05-22T14:44:18

Am 17.05.2013 05:24, schrieb Qiao Nuohan:

All these subjects should get a "dump: " prefix (or so) please, to show
what subsystem they are touching. If the subject gets line-wrapped it
indicates it's too long, please limit to 76 chars (check `git log`).

Andreas

Re: [PATCH v4 00/10] curl: fix curl read

Stefan Hajnoczi — 2013-05-22T14:39:45

Please post a top-level thread so that your patch gets picked up by
scripts and noticed by humans too :).

Alternatively Fam can include it in the next revision of this series.

Stefan

Re: [PATCH v4 3/8] block: add drive-backup QMP command

Stefan Hajnoczi — 2013-05-22T14:33:50

You are right.  It doesn't seem necessary, we'll get an error message
later from bdrv_open() or bdrv_img_create().

Will drop in the next revision.


Yes.  Will fix and update qmp_drive_mirror() too.


A dramatic pause, to build up suspense :).

Will drop in the next revision and update qmp_drive_mirror() too.

Re: [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line

Paolo Bonzini — 2013-05-22T14:38:27

Il 22/05/2013 16:29, Anthony Liguori ha scritto:

There is processor-dependent logic in libvirt, for example the CPUID bits.

Paolo

Re: [PATCH v4 4/8] qemu-iotests: add 055 drive-backuptest case

Stefan Hajnoczi — 2013-05-22T14:34:30

Will fix.

Re: New targets (was: [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line)

Andreas Färber — 2013-05-22T14:34:35

Am 22.05.2013 16:28, schrieb Anthony Liguori:

So are incompletely implemented targets (wrt instruction set) eligible
for upstream these days? I thought they'd need to be able to run at
least some small image successfully, preferably Linux where possible.

Regards,
Andreas

Re: [PATCH] qapi-schema.json: Reformat TargetType enumto one-per-line

Anthony Liguori — 2013-05-22T14:29:35


That's a very good point.  It was the libvirt folks that requested
this.  Perhaps they can shed some light on the logic?

Regards,

Anthony Liguori

Re: [PATCH] qapi-schema.json: Reformat TargetType enumto one-per-line

Anthony Liguori — 2013-05-22T14:28:29


Nope.


Sounds like a good reason to submit the target upstream to me...


There's no need to keep it in sorted order.  We should just add stuff to
the end of the enum.

Heck, if someone wants to send a patch to randomize the sort order,
that'd be fine too :-)

Regards,

Anthony Liguori

Re: [PATCH v3] tests: set MALLOC_PERTURB_ to exposememory bugs

Eric Blake — 2013-05-22T14:22:09

That was one of my comments, but you missed the other:


This is broken if /bin/sh is dash.  s/\$\$RANDOM/RANDOM/


Same problem on dash, same fix is needed.

Re: [PATCH 3/9 v3] Move includes and struct definitionto dump.h

Andreas Färber — 2013-05-22T14:12:49

Am 17.05.2013 05:24, schrieb Qiao Nuohan:
[...]

Thanks for avoiding qemu-common.h here.

I just posted the rest of my stub refactoring patches:
http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg02934.html

I fear that this patch is conflicting. Are really all of those headers
actually needed for the struct you're moving? In particular I'm worried
about cpu.h as well as cpu-all.h and kvm.h with indirect dependencies on
cpu.h.

In my case cpu-common.h worked as alternative to cpu-all.h to get
ram_addr_t and hwaddr types.

It would be nice if you could try rebasing your series on
git://github.com/afaerber/qemu-cpu.git qom-cpu branch plus the above
four patches to see if we can get this done in a way that avoids target
dependencies.

Thanks,
Andreas

Re: [PATCH v4 2/8] block: add basic backup support toblock driver

Kevin Wolf — 2013-05-22T14:08:40

Am 22.05.2013 um 15:58 hat Stefan Hajnoczi geschrieben:

No. Stopping the VM and on 'cont' assuming that the request was
successful (which it wasn't) would be wrong as well. You need the full
failed request handling, with restarting the request from the device
emulation and everything.


But this is _not_ a background job. This is the write request hook, it
is active on the guest write path. If you can't backup a given sector,
you can't overwrite it and must either fail the write request or the
backup job. Failing the write request is probably nicer because you get
the usual werror handling then, but it means that your assumption
doesn't hold true.

(See, this is one of the reasons why I was for a BlockDriver instead of
notifiers into block jobs. Things would be clearer that way because the
control flow would be explicit in the filter code.)


Not sure what you're trying to do here.

Kevin

Re: [RFC 2/2] qemu-log: Interrupt the GDB session on guest-errors

Edgar E. Iglesias — 2013-05-22T14:04:14

Ye, I figured this would be the case.

Maybe a qemu monitor flag controllable from the gdb client itself might be
the most useful, default off. Then one can turn the breaks on/off on
the fly while debugging.

monitor gdb_break_on_guest_errors or something like that.

Cheers,
Edgar