Re: [Qemu-devel] [PATCHv1 0/4] Timers: add timer debugging through -timer-debug-log
Il 26/10/2013 06:52, Alex Bligh ha scritto:
On 26 Oct 2013, at 00:00, Paolo Bonzini wrote:
his is a bug in the distro, if it is Linux. There is no reason not to
enable the stap trace format when running on Linux (Fedora does for
other packages than QEMU, too---most notably glib and glibc).
If it is useful, adding debugging information to timer_new_ns (please
make file and line two separate arguments, though) can definitely be
done unconditionally and added to the traces. I think adding a
tracepoint in timerlist_run_timers would provide very similar
information to that in your file.
I read the tracepoint information. Doesn't that require the end
user to have far more skills (and far more stuff installed) to
get things like average expiry delta? Especially as that's
not something we'd normally calculate as we don't get the clock
value when setting a timer normally.
The simple trace backend includes a nanosecond value that is the same as
rt_clock, so you can correlate the last timer_mod with the next
iteration in timerlist_run_timers (I would put the tracepoint inside the
loop, just before the callback is done). Similarly, in systemtap you
can just use the builtin gettimeofday_ns() function
All clocks are basically in nanoseconds (the only difference between
vm_clock and rt_clock is that the former stops when the VM is stopped),
so you can get the average expiry delta from there.
Of course it requires some postprocessing or a systemtap script, but we
can put that into scripts/ or give it to the user. See
https://sourceware.org/ml/systemtap/2011-q3/txt3.txt for an example,
I suppose the expiry time computation would look like this:
global modtime, expirytot, firedcnt
probe qemu.system.x86_64.timer_mod {
loc = sprintf(%s:%d, timer_file, timer_line)
modtime[pid(), loc] = gettimeofday_ns()
}
probe qemu.system.x86_64.timer_run {
loc = sprintf(%s:%d, timer_file, timer_line)
expirytot[pid(), loc] += gettimeofday_ns() - modtime[pid(), loc]
firedcnt[pid(), loc]++
}
probe end
{
printf(\n%8s %28s %8s %8s\n, pid, loc, avg expiry, cnt)
foreach([p+, loc] in firedcnt) {
printf(%8d %28s %8d %8d\n, p, loc,
expirytot[p, loc] / firedcnt[p, loc],
firedcnt[p, loc])
}
}
which I wrote based on the example at
http://cygwin.com/ml/systemtap/2011-q3/msg00316.html
I understand your usecase, but it's not really feasible to add a logging
option for each tracing need; it's much better to add new tracepoints
and distribute sample systemtap scripts. And please lobby your distro
for enabling systemtap support and distributing the .stp file!
Paolo
Re: [Qemu-devel] [PATCHv1 0/4] Timers: add timer debugging through -timer-debug-log
Paolo,
On 26 Oct 2013, at 08:18, Paolo Bonzini wrote:
The simple trace backend includes a nanosecond value that is the same as
rt_clock, so you can correlate the last timer_mod with the next
iteration in timerlist_run_timers (I would put the tracepoint inside the
loop, just before the callback is done). Similarly, in systemtap you
can just use the builtin gettimeofday_ns() function
All clocks are basically in nanoseconds (the only difference between
vm_clock and rt_clock is that the former stops when the VM is stopped),
so you can get the average expiry delta from there.
Of course it requires some postprocessing or a systemtap script, but we
can put that into scripts/ or give it to the user. See
https://sourceware.org/ml/systemtap/2011-q3/txt3.txt for an example,
I suppose the expiry time computation would look like this:
OK I need to look at the tracepoint stuff a bit more it seems :-)
If we can do this without a patch (save to put some tracepoints in),
that's obviously better than doing it with a patch. I don't like
the file particularly either.
global modtime, expirytot, firedcnt
probe qemu.system.x86_64.timer_mod {
loc = sprintf(%s:%d, timer_file, timer_line)
How do timer_file and timer_line get filled in? If those still
need to be put in through code changes, how about taking
patch 1 of the series (that fills in timer-dbg with this
information), save for the unnecessary additions to the structure,
plus whatever is necessary to put the tracepoints in?
Alex
modtime[pid(), loc] = gettimeofday_ns()
}
probe qemu.system.x86_64.timer_run {
loc = sprintf(%s:%d, timer_file, timer_line)
expirytot[pid(), loc] += gettimeofday_ns() - modtime[pid(), loc]
firedcnt[pid(), loc]++
}
probe end
{
printf(\n%8s %28s %8s %8s\n, pid, loc, avg expiry, cnt)
foreach([p+, loc] in firedcnt) {
printf(%8d %28s %8d %8d\n, p, loc,
expirytot[p, loc] / firedcnt[p, loc],
firedcnt[p, loc])
}
}
--
Alex Bligh
Re: [Qemu-devel] [PATCH v4] integrator: fix Linux boot failure by emulating dbg region
peter.mayd...@linaro.org writes:
On 22 October 2013 15:16, alex.ben...@linaro.org wrote:
+typedef struct {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} IntegratorDebugState
You forgot to remove these unused fields. I've done so
and added that slightly-edited patch to target-arm.next.
Doh, sorry about that. Thanks.
thanks
-- PMM
--
Alex Bennée
[Qemu-devel] Atmel AT91RM920 (ARM920) support and workload estimate
Hi, I've got a linux source code running on a real target based on AT91RM9200. I would like to make it working on qemu for demonstration and possible evolutions. I've read on a forum that this system-on-chip is not supported by QEMU. Is it correct ? Is it a hard work to make the porting ? Filip Navara made the support of AT91SAM7X256 (ARM7TDMI) some years ago ( http://rtime.felk.cvut.cz/hw/index.php/AT91SAM7X256). Can I re-use part of the work made for this chip ? Thanks by advance for your help. Regards, Alexandre
Re: [Qemu-devel] [PATCH] rdma: rename 'x-rdma' = 'rdma'
On 10/25/2013 11:14 AM, Paolo Bonzini wrote: Il 25/10/2013 16:03, Michael R. Hines ha scritto: Well, I tried posting libvirt support with this naming scheme, but they didn't accepted. Their reason (Daniel, I think) is valid: experimental implies that it shouldn't be exposed in the management software until it is deemed stable at some point. As far we can tell, it is stable, and made very clear using the new 'setup' state in the migration state machine. Sure, x-rdma = rdma *is* stable. I'm not sure about x-rdma-pin-all though. Paolo Use of this capability (which is disabled by default) is actually safer than migration without it - you would get an early warning well in advance of actually starting the iterative phases that there was not sufficient memory available on the destination. Safety is all relative, of course, but I have successfully performed thousands of back-to-back RDMA migrations automatically looped *in a row* using a heavy-weight memory-stress benchmark here at IBM. Migration success is done by capturing the actual serial console output of the virtual machine while the benchmark is running and redirecting each migration output to a file to verify that the output matches the expected output of a successful migration. Migrations have been tested with both 14GB and 2GB virtual machine sizes (to make sure I was testing both 32-bit and 64-bit address boundaries). The benchmark is configured to have 75% stores and 25% loads and is configured to use 80% of the allocatable free memory of the VM (i.e. no swapping allowed). I have defined a successful migration per the output file as follows: 1. The memory benchmark is still running and active (CPU near 100% and memory usage is high) 2. There are no kernel panics in the console output (regex keywords panic, BUG, oom, etc...) 3. The VM is still responding to network activity (pings) 4. The console is still responsive by printing periodic messages throughout the life of the VM to the console from inside the VM using the 'write' command in infinite loop. - Michael
Re: [Qemu-devel] [PATCH 0/2] sun4m: Implement Sun CG3 framebuffer for QEMU
On 15/10/13 21:19, Mark Cave-Ayland wrote: This patchset follows on from the previous Add FCode ROM for TCX framebuffer patch and provides QEMU with an implementation of the Sun CG3 8-bit framebuffer. It is based upon Bob Breuer's original work which has been rebased onto git master, and is now capable of running with an OpenBIOS CG3 FCode ROM instead of requiring copies of proprietary Sun ROMs. Note this patch has been around for a month or so but has been waiting for the updated OpenBIOS images to be included in QEMU. Therefore while it has not yet been reviewed, it is a reasonably simple and self-contained patchset and has been updated to reflect the comments received from the associated Add FCode ROM for TCX framebuffer patch. For this reason, I feel that both these patches are a candidate for 1.7. The motivation behind this patch is that older operating systems such as Debian Woody and Solaris (running OpenWindows) do not contain drivers for the TCX framebuffer and as a result currently cannot run in graphical mode. The screenshots linked below show qemu-system-sparc successfully running both Debian Woody and the Solaris 8 installer in graphical mode during testing: http://www.ilande.co.uk/tmp/debian-woody.png http://www.ilande.co.uk/tmp/sol8-1.png http://www.ilande.co.uk/tmp/sol8-2.png The CG3 framebuffer is selected by passing -vga cg3 on the command line to qemu-system-sparc. If either -vga tcx is specified (or the -vga argument is omitted) then qemu-system-sparc defaults to using the existing TCX framebuffer to maintain compatibility. Signed-off-by: Mark Cave-Aylandmark.cave-ayl...@ilande.co.uk Hi Anthony, Do you think it is possible that this (and the associated TCX framebuffer patch also mentioned above) could be applied for 1.7? While I've had no review from Blue (no news is good news?), I feel that the patch itself is in reasonably good shape and has been on my computer in various forms for several months now. Peter reviewed the associated Add FCode ROM for TCX framebuffer patch, and I resubmitted a revised version back to the list based upon his comments a while back. I then made the same stylistic changes to the CG3 patch and posted it above just in time for the soft feature freeze for review. Peter has further commented on this patch, but didn't have any objections AFAICT. Both patches are fine according to checkpatch, and if any issues are found then I'm happy to iron them out before the 1.7 release. I realise that SPARC is not one of the more popular architectures these days, however myself, Artyom and Bob still receive personal emails from people who are interested in QEMU's ability to run Solaris under emulation (either to replace aging hardware or provide resilience). On the plus side, given that there are fewer users and the fact that the patch preserves using TCX as the default, then the risk of side-effects from these two patches should be extremely minimal. ATB, Mark.
Re: [Qemu-devel] [Qemu-ppc] [PULL 00/29] ppc patch queue 2013-10-25
On 26/10/13 05:43, Alexander Graf wrote: Did you get my repost of the PPC PCI configuration space patch to qemu-devel here: http://lists.gnu.org/archive/html/qemu-devel/2013-10/msg01491.html? Or should that go via someone else's tree? Thanks a lot for the reminder. There is absolutely nothibg wrong with the patch, but I wanted to make sure that I have a fully autotested tree synced out before the hard freeze. I'll send this together with the next SLOF update as soon as the SLOF git tree is synchronized. Since this is a genuine bugfix, we can always get it into QEMU after the hard freeze deadline. Great - thanks Alex! ATB, Mark.
Re: [Qemu-devel] [PATCH 1/1] docs/ccid.txt: fix the typo
25.10.2013 07:36, Weng Fan wrote: From: WengFan wengfan-f...@cn.fujitsu.com Date: Wed, 25 Oct 2013 11:18:22 -0400 Subject: [PATCH 1/1] fix the typo Signed-off-by: WengFan wengfan-f...@cn.fujitsu.com --- qemu-master/docs/ccid.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) I had to fix the filename (qemu git tree does not have qemu-master subdir), and the context for a bit. The typo is there still, and the change is really trivial, so I haven't asked for a v2/resent of the patch. Thanks, applied to the trivial-patches queue. /mjt
Re: [Qemu-devel] [Qemu-trivial] [PATCH v3] misc: Spelling and grammar fixes in comments
11.10.2013 23:34, Stefan Weil wrote: * it's - its * grammar fix in ui/vnc-enc-zywrle.h Thanks, applied to the trivial patches queue. /mjt
Re: [Qemu-devel] [Qemu-trivial] [PATCH] audio/mixeng_template.h: fix inline declaration
22.10.2013 13:26, Alex Bligh пишет: ping I think this is should go to qemu-trivial --On 6 August 2013 19:45:13 +0100 Alex Bligh a...@alex.org.uk wrote: Fix error: ‘inline’ is not at beginning of declaration [-Werror=old-style-declaration] Thanks, applied to the trivial patches queue. /mjt
Re: [Qemu-devel] Bug#727756: qemu: Broken -smb with latest SAMBA package. (Unsupported security=share option)
26.10.2013 13:07, Michael Büsch wrote: Package: qemu Version: 1.6.0+dfsg-2 Severity: normal Tags: patch The smb.conf automatically generated by qemu's -smb option fails on current samba, because smbd rejects the security=share option with the following warning: WARNING: Ignoring invalid value 'share' for parameter 'security' Which makes it fall back to security=user without guest login. This results in being unable to login to the samba server from the guest OS. The attached patch fixes this by selecting 'user' explicitly and mapping unknown users to guest logins. Index: qemu-1.6.0+dfsg/net/slirp.c === --- qemu-1.6.0+dfsg.orig/net/slirp.c +++ qemu-1.6.0+dfsg/net/slirp.c @@ -529,7 +529,8 @@ static int slirp_smb(SlirpState* s, cons state directory=%s\n log file=%s/log.smbd\n smb passwd file=%s/smbpasswd\n -security = share\n +security = user\n +map to guest = Bad User\n [qemu]\n path=%s\n read only=no\n Thank you for the report and the patch Michael. Are you sure the result is equivalent? I mean, it *looks* like okay, because [qemu] share definition - which looks like this: [qemu] path=%s read only=no guest ok=yes force user=%s explicitly says that guest is okay, and forces user to the right one. And it should work the same with other versions of samba too. But samba collected so many semi-conflicting options with years, so I'm not sure anymore. Also, which users are bad -- will it be possible for our user to clash with some built-in/known user? Cc'ing qemu-devel@ because this needs to be resolved upstream too. Thank you again, /mjt
[Qemu-devel] [PULL 1/7] configure: create fsdev/ directory
In some cases when building with parallelism (make -jN), build fails because the directory where output files are supposed to be does not exist. In particular, when make decides to build virtfs-proxy-helper.1 before other files in fsdev/, build will fail with the following error: perl -Ww -- BUILDDIR/scripts/texi2pod.pl BUILDDIR/fsdev/virtfs-proxy-helper.texi fsdev/virtfs-proxy-helper.pod pod2man --utf8 --section=1 --center= --release= fsdev/virtfs-proxy-helper.pod fsdev/virtfs-proxy-helper.1 opening fsdev/virtfs-proxy-helper.pod: No such file or directory Signed-off-by: Michael Tokarev m...@tls.msk.ru Acked-by: Paolo Bonzini pbonz...@redhat.com --- configure |1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index 57ee62a..61bb27c 100755 --- a/configure +++ b/configure @@ -4647,6 +4647,7 @@ fi # build tree in object directory in case the source is not in the current directory DIRS=tests tests/tcg tests/tcg/cris tests/tcg/lm32 tests/libqos tests/qapi-schema tests/tcg/xtensa tests/qemu-iotests +DIRS=$DIRS fsdev DIRS=$DIRS pc-bios/optionrom pc-bios/spapr-rtas pc-bios/s390-ccw DIRS=$DIRS roms/seabios roms/vgabios DIRS=$DIRS qapi-generated -- 1.7.10.4
[Qemu-devel] [PULL 2/7] misc: New spelling fixes in comments
From: Stefan Weil s...@weilnetz.de
compatiblity - compatibility
continously - continuously
existance - existence
usefull - useful
shoudl - should
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
block/iscsi.c|2 +-
hw/ppc/spapr.c |2 +-
target-alpha/translate.c |2 +-
tests/test-throttle.c|4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index a2a961e..a2d578c 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -866,7 +866,7 @@ retry:
/* in case the get_lba_status_callout fails (i.e.
* because the device is busy or the cmd is not
* supported) we pretend all blocks are allocated
- * for backwards compatiblity */
+ * for backwards compatibility */
goto out;
}
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 004184d..74aa5cc 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -120,7 +120,7 @@ int spapr_allocate_irq_block(int num, bool lsi, bool msi)
* it has to be aligned to num to support multiple
* MSI vectors. MSI-X is not affected by this.
* The hint is used for the first IRQ, the rest should
- * be allocated continously.
+ * be allocated continuously.
*/
if (msi) {
assert((num == 1) || (num == 2) || (num == 4) ||
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index c24910f..1155e86 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -1601,7 +1601,7 @@ static ExitStatus gen_call_pal(DisasContext *ctx, int
palcode)
tcg_temp_free(pc);
/* Since the destination is running in PALmode, we don't really
- need the page permissions check. We'll see the existance of
+ need the page permissions check. We'll see the existence of
the page when we create the TB, and we'll flush all TBs if
we change the PAL base register. */
if (!ctx-singlestep_enabled !(ctx-tb-cflags CF_LAST_IO)) {
diff --git a/tests/test-throttle.c b/tests/test-throttle.c
index 7608126..1d4ffd3 100644
--- a/tests/test-throttle.c
+++ b/tests/test-throttle.c
@@ -18,7 +18,7 @@ LeakyBucketbkt;
ThrottleConfig cfg;
ThrottleState ts;
-/* usefull function */
+/* useful function */
static bool double_cmp(double x, double y)
{
return fabsl(x - y) 1e-6;
@@ -320,7 +320,7 @@ static void test_have_timer(void)
/* zero the structure */
memset(ts, 0, sizeof(ts));
-/* no timer set shoudl return false */
+/* no timer set should return false */
g_assert(!throttle_have_timer(ts));
/* init the structure */
--
1.7.10.4
[Qemu-devel] [PULL 3/7] .gitignore: ignore qmp-commands.txt
From: Fam Zheng f...@redhat.com This file is moved out from QMP/ to BUILD dir, change the ignore file too. Signed-off-by: Fam Zheng f...@redhat.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com Signed-off-by: Michael Tokarev m...@tls.msk.ru --- .gitignore |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 8e1b73f..5584b5f 100644 --- a/.gitignore +++ b/.gitignore @@ -44,7 +44,7 @@ qemu-ga qemu-bridge-helper qemu-monitor.texi vscclient -QMP/qmp-commands.txt +qmp-commands.txt test-bitops test-coroutine test-int128 -- 1.7.10.4
[Qemu-devel] [PULL 0/7 for-1.7] Trivial patches for 2013-10-26
This is a 2-week pull request, I haven't asked for pull a week ago since we had not much stuff happening on trivial front. Please consider pulling. Thanks, /mjt The following changes since commit fc8ead74674b7129e8f31c2595c76658e5622197: Merge remote-tracking branch 'qemu-kvm/uq/master' into staging (2013-10-18 10:03:24 -0700) are available in the git repository at: git://git.corpit.ru/qemu.git trivial-patches for you to fetch changes up to 203cea22a3d33ac86d170af74f8c655f119c8c62: audio/mixeng_template.h: fix inline declaration (2013-10-26 13:09:34 +0400) Alex Bligh (1): audio/mixeng_template.h: fix inline declaration Eric Blake (1): qapi: fix documentation example Fam Zheng (1): .gitignore: ignore qmp-commands.txt Michael Tokarev (1): configure: create fsdev/ directory Stefan Weil (2): misc: New spelling fixes in comments misc: Spelling and grammar fixes in comments WengFan (1): docs/ccid.txt: fix the typo .gitignore |2 +- audio/mixeng_template.h |4 ++-- block/iscsi.c|2 +- configure|1 + docs/ccid.txt|2 +- docs/qapi-code-gen.txt |2 +- hw/ppc/spapr.c |2 +- qapi-schema.json |2 +- slirp/if.c |2 +- target-alpha/translate.c |2 +- tests/test-throttle.c|4 ++-- ui/vnc-enc-zywrle.h |2 +- 12 files changed, 14 insertions(+), 13 deletions(-)
[Qemu-devel] [PULL 4/7] qapi: fix documentation example
From: Eric Blake ebl...@redhat.com
The QMP wire format uses , not '', around strings.
* docs/qapi-code-gen.txt: Fix typo.
Signed-off-by: Eric Blake ebl...@redhat.com
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
docs/qapi-code-gen.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index 91f44d0..0728f36 100644
--- a/docs/qapi-code-gen.txt
+++ b/docs/qapi-code-gen.txt
@@ -164,7 +164,7 @@ This example allows using both of the following example
objects:
{ file: my_existing_block_device_id }
{ file: { driver: file,
readonly: false,
- 'filename': /tmp/mydisk.qcow2 } }
+ filename: /tmp/mydisk.qcow2 } }
=== Commands ===
--
1.7.10.4
[Qemu-devel] [PULL 7/7] audio/mixeng_template.h: fix inline declaration
From: Alex Bligh a...@alex.org.uk
Fix error: ‘inline’ is not at beginning of declaration
[-Werror=old-style-declaration]
Signed-off-by: Alex Bligh a...@alex.org.uk
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
audio/mixeng_template.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/audio/mixeng_template.h b/audio/mixeng_template.h
index 30849a6..77cc89b 100644
--- a/audio/mixeng_template.h
+++ b/audio/mixeng_template.h
@@ -35,7 +35,7 @@
#define IN_T glue (glue (ITYPE, BSIZE), _t)
#ifdef FLOAT_MIXENG
-static mixeng_real inline glue (conv_, ET) (IN_T v)
+static inline mixeng_real glue (conv_, ET) (IN_T v)
{
IN_T nv = ENDIAN_CONVERT (v);
@@ -54,7 +54,7 @@ static mixeng_real inline glue (conv_, ET) (IN_T v)
#endif
}
-static IN_T inline glue (clip_, ET) (mixeng_real v)
+static inline IN_T glue (clip_, ET) (mixeng_real v)
{
if (v = 0.5) {
return IN_MAX;
--
1.7.10.4
[Qemu-devel] [PULL 5/7] docs/ccid.txt: fix the typo
From: WengFan wengfan-f...@cn.fujitsu.com Signed-off-by: WengFan wengfan-f...@cn.fujitsu.com Reviewed-by: Eric Blake ebl...@redhat.com Signed-off-by: Michael Tokarev m...@tls.msk.ru --- docs/ccid.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ccid.txt b/docs/ccid.txt index 8bbaa94..83c174d 100644 --- a/docs/ccid.txt +++ b/docs/ccid.txt @@ -52,7 +52,7 @@ Configuring and building: Assuming you have a working smartcard on the host with the current user, using NSS, qemu acts as another NSS client using ccid-card-emulated: -qemu -usb -device usb-ccid -device ccid-card-emualated +qemu -usb -device usb-ccid -device ccid-card-emulated 4. Using ccid-card-emulated with certificates -- 1.7.10.4
[Qemu-devel] [PULL 6/7] misc: Spelling and grammar fixes in comments
From: Stefan Weil s...@weilnetz.de * it's - its * grammar fix in ui/vnc-enc-zywrle.h Signed-off-by: Stefan Weil s...@weilnetz.de Reviewed-by: Don Koch dk...@verizon.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Michael Tokarev m...@tls.msk.ru --- qapi-schema.json|2 +- slirp/if.c |2 +- ui/vnc-enc-zywrle.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/qapi-schema.json b/qapi-schema.json index 60f3fd1..a003aa1 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -1914,7 +1914,7 @@ # # Since: 0.14.0 # -# Notes: This command only exists as a stop-gap. It's use is highly +# Notes: This command only exists as a stop-gap. Its use is highly #discouraged. The semantics of this command are not guaranteed. # #Known limitations: diff --git a/slirp/if.c b/slirp/if.c index 87ca8a5..fb7acf8 100644 --- a/slirp/if.c +++ b/slirp/if.c @@ -142,7 +142,7 @@ diddit: /* * Send a packet - * We choose a packet based on it's position in the output queues; + * We choose a packet based on its position in the output queues; * If there are packets on the fastq, they are sent FIFO, before * everything else. Otherwise we choose the first packet from the * batchq and send it. the next packet chosen will be from the session diff --git a/ui/vnc-enc-zywrle.h b/ui/vnc-enc-zywrle.h index 1ff40b1..d436d58 100644 --- a/ui/vnc-enc-zywrle.h +++ b/ui/vnc-enc-zywrle.h @@ -305,7 +305,7 @@ static inline void harr(int8_t *px0, int8_t *px1) |L1H0H1H0|L1H0H1H0|L1H0H1H0|L1H0H1H0| : level 1 In this method, H/L and X0/X1 is always same position. - This lead us to more speed and less memory. + This leads us to more speed and less memory. Of cause, the result of both method is quite same because it's only difference that coefficient position. */ -- 1.7.10.4
Re: [Qemu-devel] qemu 1.6.1
Am 24.10.2013 23:47, schrieb Paolo Bonzini: Il 24/10/2013 17:37, Stefan Weil ha scritto: Yes, that works, too. It also fixes the problem with the assertion (tested with Wine). No, we cannot remove from_, because the same interface is also used for Linux and other hosts which don't have a 'current' variable. Or we would have to call qemu_coroutine_self() to get the current coroutine. Yes, I was thinking of using qemu_coroutine_self(). By the way, can you post the two assembly language outputs for just - CoroutineWin32 *from = DO_UPCAST(CoroutineWin32, base, from_); + CoroutineWin32 *from = DO_UPCAST(CoroutineWin32, base, current); which AIUI works and is enough to fix the bug? Paolo See disassembled code below. I removed compiler option -fstack-protector-all to simplify the assembler code and tested that the result was not affected by this removal. The C and assembler code from the test is also available at http://qemu.weilnetz.de/test/coroutine-win32/. Stefan unpatched QEMU, crash with assertion 00448670 _qemu_coroutine_switch: 448670: 53 push %ebx 448671: 83 ec 18sub$0x18,%esp 448674: c7 04 24 a8 62 6d 00movl $0x6d62a8,(%esp) 44867b: 8b 5c 24 24 mov0x24(%esp),%ebx 44867f: e8 ec 9e 27 00 call 6c2570 ___emutls_get_address 448684: 89 18 mov%ebx,(%eax) 448686: 8b 44 24 28 mov0x28(%esp),%eax 44868a: 89 43 24mov%eax,0x24(%ebx) 44868d: 8b 43 20mov0x20(%ebx),%eax 448690: 89 04 24mov%eax,(%esp) 448693: ff 15 c0 5f 83 00 call *0x835fc0 448699: 83 ec 04sub$0x4,%esp 44869c: 8b 44 24 20 mov0x20(%esp),%eax 4486a0: 8b 40 24mov0x24(%eax),%eax 4486a3: 83 c4 18add$0x18,%esp 4486a6: 5b pop%ebx 4486a7: c3 ret patched, works 00448620 _qemu_coroutine_switch: 448620: 83 ec 1csub$0x1c,%esp 448623: c7 04 24 a8 62 6d 00movl $0x6d62a8,(%esp) 44862a: 89 5c 24 14 mov%ebx,0x14(%esp) 44862e: 8b 5c 24 24 mov0x24(%esp),%ebx 448632: 89 74 24 18 mov%esi,0x18(%esp) 448636: e8 25 9f 27 00 call 6c2560 ___emutls_get_address 44863b: 8b 30 mov(%eax),%esi 44863d: 89 18 mov%ebx,(%eax) 44863f: 8b 44 24 28 mov0x28(%esp),%eax 448643: 89 43 24mov%eax,0x24(%ebx) 448646: 8b 43 20mov0x20(%ebx),%eax 448649: 89 04 24mov%eax,(%esp) 44864c: ff 15 c0 5f 83 00 call *0x835fc0 448652: 8b 46 24mov0x24(%esi),%eax 448655: 83 ec 04sub$0x4,%esp 448658: 8b 5c 24 14 mov0x14(%esp),%ebx 44865c: 8b 74 24 18 mov0x18(%esp),%esi 448660: 83 c4 1cadd$0x1c,%esp 448663: c3 ret
Re: [Qemu-devel] [PATCH v5 0/8] Add metadata overlap checks
Am 20.09.2013 12:32, schrieb Stefan Hajnoczi: On Thu, Sep 19, 2013 at 05:07:56PM +0200, Max Reitz wrote: As far as I understand, the I/O speed (the duration of an I/O operation) should be pretty much the same for all scenarios, however, the latency is the value in question (since the overlap checks should affect the latency only). The other value to look at is the host CPU consumption per I/O. In other words, the CPU overhead added by performing the extra checks: efficiency = avg throughput / avg cpu utilization Once CPU consumption reaches 100% the workload is CPU-bound and we have a bottleneck. Hopefully the efficiency doesn't change noticably either, then we know there is no big impact from the extra checks. Stefan Okay, after fixing the VM state in qcow2, I was now finally able to actually perform the CPU benchmark. On second thought, it wasn't really neccessary, since I performed most of the tests in RAM anyway, so the CPU was already the bottleneck for these tests. I ran bonnie++ (bonnie++ -s 4g -n 0 -x 16) from an arch live CD ISO on a 5 GB qcow2 image formatted as ext4, both residing in /tmp; I prepared the VM state to the point where I just had to press Enter to perform the test and shut down the VM. I then performed a snapshot and used this image as the basis for two tests, one with no overlap checks enabled and one with all of them enabled. The time output for both qemu instances was respectively: echo 'sendkey ret' | time $QEMU_DIR/x86_64-softmmu/qemu-system-x86_64 -cdrom arch.iso -drive file=base.qcow2,overlap-check=none -enable-kvm -vga std -m 512 -loadvm 0 -monitor stdio d 294.42s user 117.72s system 98% cpu 6:58.00 total echo 'sendkey ret' | time $QEMU_DIR/x86_64-softmmu/qemu-system-x86_64 -cdrom arch.iso -drive file=base.qcow2,overlap-check=all -enable-kvm -vga std -m 512 -loadvm 0 -monitor stdio d 298.87s user 119.55s system 100% cpu 6:56.37 total So, as you can see, the CPU time differs only marginally (using all overlap checks instead of none took 1.52 % more CPU time). Max
Re: [Qemu-devel] [PATCH v5 0/8] Add metadata overlap checks
Am 26.10.2013 15:03, schrieb Max Reitz: Am 20.09.2013 12:32, schrieb Stefan Hajnoczi: On Thu, Sep 19, 2013 at 05:07:56PM +0200, Max Reitz wrote: As far as I understand, the I/O speed (the duration of an I/O operation) should be pretty much the same for all scenarios, however, the latency is the value in question (since the overlap checks should affect the latency only). The other value to look at is the host CPU consumption per I/O. In other words, the CPU overhead added by performing the extra checks: efficiency = avg throughput / avg cpu utilization Once CPU consumption reaches 100% the workload is CPU-bound and we have a bottleneck. Hopefully the efficiency doesn't change noticably either, then we know there is no big impact from the extra checks. Stefan Okay, after fixing the VM state in qcow2, I was now finally able to actually perform the CPU benchmark. On second thought, it wasn't really neccessary, since I performed most of the tests in RAM anyway, so the CPU was already the bottleneck for these tests. I forgot to mention: I used the qemu from Kevin's current block branch for these tests. Max I ran bonnie++ (bonnie++ -s 4g -n 0 -x 16) from an arch live CD ISO on a 5 GB qcow2 image formatted as ext4, both residing in /tmp; I prepared the VM state to the point where I just had to press Enter to perform the test and shut down the VM. I then performed a snapshot and used this image as the basis for two tests, one with no overlap checks enabled and one with all of them enabled. The time output for both qemu instances was respectively: echo 'sendkey ret' | time $QEMU_DIR/x86_64-softmmu/qemu-system-x86_64 -cdrom arch.iso -drive file=base.qcow2,overlap-check=none -enable-kvm -vga std -m 512 -loadvm 0 -monitor stdio d 294.42s user 117.72s system 98% cpu 6:58.00 total echo 'sendkey ret' | time $QEMU_DIR/x86_64-softmmu/qemu-system-x86_64 -cdrom arch.iso -drive file=base.qcow2,overlap-check=all -enable-kvm -vga std -m 512 -loadvm 0 -monitor stdio d 298.87s user 119.55s system 100% cpu 6:56.37 total So, as you can see, the CPU time differs only marginally (using all overlap checks instead of none took 1.52 % more CPU time). Max
Re: [Qemu-devel] [PATCH] Fix COR by disabling BDRV_O_COPY_ON_READ before opening the backing_file.
Am 25.10.2013 02:15, schrieb Thibaut LAURENT: Since commit 0ebd24e0a203cf2852c310b59fbe050190dc6c8c, bdrv_open_common will throw an error when trying to open a file read-only with the BDRV_O_COPY_ON_READ flag set. Although BDRV_O_RDWR is unset for the backing files, BDRV_O_COPY_ON_READ is still passed on if copy-on-read was requested for the drive. Let's unset this flag too before opening the backing file, or bdrv_open_common will fail. Signed-off-by: Thibaut LAURENT thibaut.laur...@gmail.com --- block.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Max Reitz mre...@redhat.com
[Qemu-devel] [PATCH] block: Don't copy backing file name on error
bdrv_open_backing_file() tries to copy the backing file name using
pstrcpy directly after calling bdrv_open() to open the backing file
without checking whether that was actually successful. If it was not,
ps-backing_hd-file will probably be NULL and qemu will crash.
Fix this by moving pstrcpy after checking whether bdrv_open() succeeded.
Signed-off-by: Max Reitz mre...@redhat.com
---
block.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 4474012..61795fe 100644
--- a/block.c
+++ b/block.c
@@ -1005,8 +1005,6 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict
*options, Error **errp)
ret = bdrv_open(bs-backing_hd,
*backing_filename ? backing_filename : NULL, options,
back_flags, back_drv, local_err);
-pstrcpy(bs-backing_file, sizeof(bs-backing_file),
-bs-backing_hd-file-filename);
if (ret 0) {
bdrv_unref(bs-backing_hd);
bs-backing_hd = NULL;
@@ -1014,6 +1012,8 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict
*options, Error **errp)
error_propagate(errp, local_err);
return ret;
}
+pstrcpy(bs-backing_file, sizeof(bs-backing_file),
+bs-backing_hd-file-filename);
return 0;
}
--
1.8.4.1
Re: [Qemu-devel] Bug#727756: qemu: Broken -smb with latest SAMBA package. (Unsupported security=share option)
On Sat, 26 Oct 2013 13:19:29 +0400 Michael Tokarev m...@tls.msk.ru wrote: Thank you for the report and the patch Michael. Are you sure the result is equivalent? Well, I am far from being an SMB expert. So I can't really say whether this is equivalent. I also posted this patch to the qemu-devel list, but didn't get a reply, yet. I tested this with a Windows XP client. Without this patch the client will always ask for username and password. Which I am unable to supply (smbpasswd is empty after all). With this patch applied, the share works without authentication. And this is how it used to work in previous versions, too. explicitly says that guest is okay, and forces user to the right one. And it should work the same with other versions of samba too. I only tried this with smbd from sid. My guess is that it would work on older versions, too. But that is untested. Also, which users are bad -- will it be possible for our user to clash with some built-in/known user? 'bad users seem to be users that are not in the smbpasswd file. As qemu creates an empty smbpasswd file, all users probably are bad. But I'm not sure if there are exceptions to that. Cc'ing qemu-devel@ because this needs to be resolved upstream too. signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCHv1 0/4] Timers: add timer debugging through -timer-debug-log
Il 26/10/2013 10:24, Alex Bligh ha scritto: How do timer_file and timer_line get filled in? If those still need to be put in through code changes, how about taking patch 1 of the series (that fills in timer-dbg with this information), save for the unnecessary additions to the structure, plus whatever is necessary to put the tracepoints in? Sure! Paolo
Re: [Qemu-devel] [PATCH] rdma: rename 'x-rdma' = 'rdma'
Il 26/10/2013 10:45, Michael R. Hines ha scritto: Sure, x-rdma = rdma *is* stable. I'm not sure about x-rdma-pin-all though. Use of this capability (which is disabled by default) is actually safer than migration without it - you would get an early warning well in advance of actually starting the iterative phases that there was not sufficient memory available on the destination. I guess that shows more of my (lack of) knowledge about RDMA. :) You're obviously right, x-rdma-pin-all could make sense even if we had fancy caching strategies. Paolo
Re: [Qemu-devel] About VM fork in QEMU
External snapshots (via the blockdev-snapshot-sync QMP command) can be taken in a matter of milliseconds if you only care about disk state. Furthermore, if you want to take a snapshot of both memory and disk state, such that the clone can be resumed from the same time, you can do that with a guest downtime that only lasts as long as the blockdev-snapshot-sync, by first doing a migrate to file then doing the disk snapshot when the VM pauses at the end of migration. Resuming the original guest is fast; resuming from the migration file is a bit longer, but it is still the fastest way possible to resume from a memory+disk snapshot. If you need anything faster, then yes, you would have to write patches to qemu to attempt cloning via fork() that makes sure to modify the active disk in use by the fork child so as not to interfere with the fork parent. I think migrating memory to file then doing external disk snapshot is exactly what we want. Since we are using libvirt to manage different VMs, could you give us some specific guides (or references) that how we could migrate memory state to file using virsh interfaces and do external snapshots? Thanks, Xinyang -- Xinyang GE Department of Computer Science Engineering The Pennsylvania State University Homepage: http://www.cse.psu.edu/~xxg113/
Re: [Qemu-devel] About VM fork in QEMU
External snapshots (via the blockdev-snapshot-sync QMP command) can be taken in a matter of milliseconds if you only care about disk state. Furthermore, if you want to take a snapshot of both memory and disk state, such that the clone can be resumed from the same time, you can do that with a guest downtime that only lasts as long as the blockdev-snapshot-sync, by first doing a migrate to file then doing the disk snapshot when the VM pauses at the end of migration. Resuming the original guest is fast; resuming from the migration file is a bit longer, but it is still the fastest way possible to resume from a memory+disk snapshot. If you need anything faster, then yes, you would have to write patches to qemu to attempt cloning via fork() that makes sure to modify the active disk in use by the fork child so as not to interfere with the fork parent. I noticed there is a qemu-monitor-command option for virsh and maybe I can use this to issue QMP commands. However, when I run blockdev-snapshot-sync, I cannot correctly identify the correct values for argument device. Below is part of the VM's configuration file (libvirt format): devices emulator/usr/bin/kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2'/ source file='/var/lib/libvirt/images/u12.qcow2'/ target dev='hda' bus='ide'/ alias name='ide0-0-0'/ address type='drive' controller='0' bus='0' unit='0'/ /disk disk type='block' device='cdrom' driver name='qemu' type='raw'/ target dev='hdc' bus='ide'/ readonly/ alias name='ide0-1-0'/ address type='drive' controller='0' bus='1' unit='0'/ /disk Can you help me find out which is the right value for device when I run blockdev-snapshot-sync? Thanks in advance! Xinyang -- Xinyang GE Department of Computer Science Engineering The Pennsylvania State University Homepage: http://www.cse.psu.edu/~xxg113/
Re: [Qemu-devel] fix clearing i8259 IRQ lines (Was: Should the i8259 devices remain no-user?)
On Wed, Oct 16, 2013 at 06:23:11PM +0200, Paolo Bonzini wrote: Il 16/10/2013 18:21, BALATON Zoltan ha scritto: A bit off topic but this reminded me of these patches: http://patchwork.ozlabs.org/patch/206753/ http://patchwork.ozlabs.org/patch/208252/ which never got merged. Is there a chance that these fixes get merged sometimes or is there an explanation why it won't be fixed? As far as I remember the patches were reviewed and multiple versions were proposed but at the end no decision was reached on which one to merge and it was just left uncorrected. Right, thank you very much. ISTR the unanswered question was what to do about migration, but I need to reread all the threads. Paolo Essentially correct. Although the 8259 (interrupts) model is clearly wrong with respect to clearing an IRQ request line, only one ancient unimportant guest (Microport UNIX ca. 1987) seems to care, and there are potentially significant risks to more important guests if we try to fix it: Risks: The 8254 (timers) model is wrong in various ways, some of which are hidden by the incorrect 8259 model, and fixing it could potentially break migration, depending on exact circumstances. Also, it isn't clear if there are other device models depending on the incorrect 8259 that would also need to be fixed. Similar changes are needed in KVM for consistency, although some of the 8254 modes are implemented in a more simplistic way (pulses handled as fast as possible directly, instead of 1-millisecond-long pulses on real hardware). Note that I was never able to get my guest running successfully under KVM; I'm not sure what the remaining problems were. Also, the patch series included a few other things: - A couple of low priority fixes that can still be worked around without code changes, but could probably qualify as trivial patches. - Some test cases to test for the 8259 problem. - Plus an optional VGA hack to make it work when my ancient guest tries to directly (no BIOS) configure it for CGA text mode. I didn't get much feedback about these. - If someone actually showed real interest in actually merging these, including the selection of a migration compatibility strategy they would actually be willing to merge (and above: other devices, KVM, etc), I could look into updating the patches to match. But the if parts aren't looking particularly likely. This seems like a rather core-level wide-implication change for a newbie to be messing with. (I've already spent noticably more time on qemu patches than I had intended to spend total on playing with this guest, although I may continue if I have a clearly defined strategy.) - Matthew Ogilvie
[Qemu-devel] [PATCH v2] rdma: rename 'x-rdma' = 'rdma'
From: Michael R. Hines mrhi...@us.ibm.com
As far as we can tell, all known bugs have been fixed:
1. Parallel RDMA migrations are working
2. IPv6 migration is working
3. Libvirt patches are ready
4. virt-test is working
Signed-off-by: Michael R. Hines mrhi...@us.ibm.com
---
docs/rdma.txt| 24 ++--
migration-rdma.c |2 +-
migration.c |6 +++---
qapi-schema.json |4 ++--
4 files changed, 16 insertions(+), 20 deletions(-)
diff --git a/docs/rdma.txt b/docs/rdma.txt
index 8d1e003..c559f9a 100644
--- a/docs/rdma.txt
+++ b/docs/rdma.txt
@@ -66,7 +66,7 @@ bulk-phase round of the migration and can be enabled for
extremely
high-performance RDMA hardware using the following command:
QEMU Monitor Command:
-$ migrate_set_capability x-rdma-pin-all on # disabled by default
+$ migrate_set_capability rdma-pin-all on # disabled by default
Performing this action will cause all 8GB to be pinned, so if that's
not what you want, then please ignore this step altogether.
@@ -93,12 +93,12 @@ $ migrate_set_speed 40g # or whatever is the MAX of your
RDMA device
Next, on the destination machine, add the following to the QEMU command line:
-qemu . -incoming x-rdma:host:port
+qemu . -incoming rdma:host:port
Finally, perform the actual migration on the source machine:
QEMU Monitor Command:
-$ migrate -d x-rdma:host:port
+$ migrate -d rdma:host:port
PERFORMANCE
===
@@ -120,8 +120,8 @@ For example, in the same 8GB RAM example with all 8GB of
memory in
active use and the VM itself is completely idle using the same 40 gbps
infiniband link:
-1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
-2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
+1. rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
+2. rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
These numbers would of course scale up to whatever size virtual machine
you have to migrate using RDMA.
@@ -407,18 +407,14 @@ socket is broken during a non-RDMA based migration.
TODO:
=
-1. 'migrate x-rdma:host:port' and '-incoming x-rdma' options will be
- renamed to 'rdma' after the experimental phase of this work has
- completed upstream.
-2. Currently, 'ulimit -l' mlock() limits as well as cgroups swap limits
+1. Currently, 'ulimit -l' mlock() limits as well as cgroups swap limits
are not compatible with infinband memory pinning and will result in
an aborted migration (but with the source VM left unaffected).
-3. Use of the recent /proc/pid/pagemap would likely speed up
+2. Use of the recent /proc/pid/pagemap would likely speed up
the use of KSM and ballooning while using RDMA.
-4. Also, some form of balloon-device usage tracking would also
+3. Also, some form of balloon-device usage tracking would also
help alleviate some issues.
-5. Move UNREGISTER requests to a separate thread.
-6. Use LRU to provide more fine-grained direction of UNREGISTER
+4. Use LRU to provide more fine-grained direction of UNREGISTER
requests for unpinning memory in an overcommitted environment.
-7. Expose UNREGISTER support to the user by way of workload-specific
+5. Expose UNREGISTER support to the user by way of workload-specific
hints about application behavior.
diff --git a/migration-rdma.c b/migration-rdma.c
index f94f3b4..eeb4302 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -3412,7 +3412,7 @@ void rdma_start_outgoing_migration(void *opaque,
}
ret = qemu_rdma_source_init(rdma, local_err,
-s-enabled_capabilities[MIGRATION_CAPABILITY_X_RDMA_PIN_ALL]);
+s-enabled_capabilities[MIGRATION_CAPABILITY_RDMA_PIN_ALL]);
if (ret) {
goto err;
diff --git a/migration.c b/migration.c
index b4f8462..d9c7a62 100644
--- a/migration.c
+++ b/migration.c
@@ -81,7 +81,7 @@ void qemu_start_incoming_migration(const char *uri, Error
**errp)
if (strstart(uri, tcp:, p))
tcp_start_incoming_migration(p, errp);
#ifdef CONFIG_RDMA
-else if (strstart(uri, x-rdma:, p))
+else if (strstart(uri, rdma:, p))
rdma_start_incoming_migration(p, errp);
#endif
#if !defined(WIN32)
@@ -423,7 +423,7 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
if (strstart(uri, tcp:, p)) {
tcp_start_outgoing_migration(s, p, local_err);
#ifdef CONFIG_RDMA
-} else if (strstart(uri, x-rdma:, p)) {
+} else if (strstart(uri, rdma:, p)) {
rdma_start_outgoing_migration(s, p, local_err);
#endif
#if !defined(WIN32)
@@ -501,7 +501,7 @@ bool migrate_rdma_pin_all(void)
s = migrate_get_current();
-return s-enabled_capabilities[MIGRATION_CAPABILITY_X_RDMA_PIN_ALL];
+return s-enabled_capabilities[MIGRATION_CAPABILITY_RDMA_PIN_ALL];
}
bool migrate_auto_converge(void)
diff --git a/qapi-schema.json b/qapi-schema.json
index 145eca8..4bae4b1 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -615,7 +615,7 @@
#
