Replaces the pattern `atomic_store(atomic_load() something)`
pattern with its direct atomic function.
Signed-off-by: Wolfgang Bumiller
---
Note: these previously used RELEASE ordering for the store and `relaxed`
ordering for the reads, while the replacement uses SEQ_CST, as there are no
other
omic_read() +
1) with qatomic_inc() (and -1 with _dec)
Signed-off-by: Wolfgang Bumiller
---
block/graph-lock.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/block/graph-lock.c b/block/graph-lock.c
index c81162b147..32fb29b841 100644
--- a/block/graph-lock.c
+++ b/blo
ntics already ensuring that these operations are indeed working correctly
atomically, so I thought I'd point them out and ask about it by sending
patches.
In patch 2 the ordering is changed (see the note in its mail)
Wolfgang Bumiller (2):
graph-lock: make sure reader_count access is atomic
On Thu, Mar 18, 2021 at 02:35:50PM +0100, Stefan Reiter wrote:
> If OOB is disabled, events received in monitor_qmp_event will be handled
> in the main context. Thus, we must not acquire a qmp_queue_lock there,
> as the dispatcher coroutine holds one over a yield point, where it
> expects to be res
On Tue, Feb 18, 2020 at 04:40:34PM +0100, Kevin Wolf wrote:
> We want to be able to use qemu_aio_context in the monitor
> initialisation.
>
> Signed-off-by: Kevin Wolf
> Reviewed-by: Marc-André Lureau
> Reviewed-by: Markus Armbruster
> ---
> vl.c | 10 +-
> 1 file changed, 5 insertions
from the
still-suspended socket).
Fix this by resuming the monitor when clearing a queue which
was filled up.
Signed-off-by: Wolfgang Bumiller
---
Changes since v2:
* Rename `monitor_qmp_cleanup_queues_and_resume` to use singular
`queue`.
* Make the `need_resume` condition to actually
On Wed, Nov 13, 2019 at 05:45:57PM +0100, Markus Armbruster wrote:
> Wolfgang Bumiller writes:
>
> > When a monitor's queue is filled up in handle_qmp_command()
> > it gets suspended. It's the dispatcher bh's job currently to
> > resume the monitor,
On Wed, Nov 06, 2019 at 10:37:04AM +0100, Max Reitz wrote:
> On 06.11.19 09:32, Stefan Hajnoczi wrote:
> > On Tue, Nov 05, 2019 at 11:02:44AM +0100, Dietmar Maurer wrote:
> >> Example: Backup from ceph disk (rbd_cache=false) to local disk:
> >>
> >> backup_calculate_cluster_size returns 64K (correc
from the
still-suspended socket).
Fix this by resuming the monitor when clearing a queue which
was filled up.
Signed-off-by: Wolfgang Bumiller
---
Changes to v1:
* Update commit message to include the resulting symptoms.
* Moved the resume code from `monitor_qmp_cleanup_req_q
On Wed, Oct 09, 2019 at 09:18:04PM +0200, Markus Armbruster wrote:
> Wolfgang Bumiller writes:
>
> > On Wed, Oct 09, 2019 at 10:39:44AM +0200, Markus Armbruster wrote:
> >> Cc: Marc-André for additional monitor and chardev expertise.
> >>
> >> Wolfgan
On Wed, Oct 09, 2019 at 10:39:44AM +0200, Markus Armbruster wrote:
> Cc: Marc-André for additional monitor and chardev expertise.
>
> Wolfgang Bumiller writes:
>
> > When a monitor's queue is filled up in handle_qmp_command()
> > it gets suspended. It's th
efore the bh
is scheduled, which will clear the queue without resuming
the monitor, thereby preventing the dispatcher from reaching
the resume() call.
Fix this by resuming the monitor when clearing a queue which
was filled up.
Signed-off-by: Wolfgang Bumiller
---
@Michael, we ran into this with qemu 4.0,
long as
> a versioned machine type is specified (do not use just "pc"!).
>
> Originally-by: Wolfgang Bumiller
> Signed-off-by: Stefan Hajnoczi
Tested-by: Wolfgang Bumiller
Works with my otherwise failing VM from 3.0.1 -> patched-4.0.
Somehow I missed the `DEFINE
On Thu, Jun 27, 2019 at 03:12:52PM +0200, Wolfgang Bumiller wrote:
> While testing with 4.0 we've run into issues with live migration from
> 3.0.1 to 4.0 when a balloon device was involved.
>
> We'd see the following error on the destination:
> qemu-system-x86_64: g
While testing with 4.0 we've run into issues with live migration from
3.0.1 to 4.0 when a balloon device was involved.
We'd see the following error on the destination:
qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: a1
device: 1 cmask: ff wmask: c0 w1cmask:0
qemu-sys
On Thu, Oct 11, 2018 at 08:30:24AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Fri, Sep 28, 2018 at 01:00:26PM +0400, Marc-André Lureau wrote:
> >> Hi
> >>
> >> On Fri, Sep 28, 2018 at 12:02 PM Wolfgang Bumiller
> >> wrote:
>
y has use_io_thread == true. Therefore
mon_iothread initialization is protected by monitor_lock.
We still need to create the qmp_dispatcher_bh when not using
iothreads, so this now still happens via
monitor_init_globals().
Signed-off-by: Wolfgang Bumiller
Fixes: d32749deb615 ("monitor: move i
hread.
Wolfgang Bumiller (2):
monitor: guard iothread access by mon->use_io_thread
monitor: delay monitor iothread creation
monitor.c | 51 +++
1 file changed, 31 insertions(+), 20 deletions(-)
--
2.11.0
monitor_resume() and monitor_suspend() both want to
"kick" the I/O thread if it is there, but in
monitor_suspend() lacked the use_io_thread flag condition.
This is required when we later only spawn the thread on
first use.
Signed-off-by: Wolfgang Bumiller
Reviewed-by: Eric Blake
R
>>
> > >> > On Tue, Sep 25, 2018 at 01:09:57PM +0200, Wolfgang Bumiller wrote:
> > >> >>
> > >> >> > On September 25, 2018 at 12:31 PM Peter Xu
> > >> >> > wrote:
> > >> >> >
> On September 25, 2018 at 12:31 PM Peter Xu wrote:
>
>
> On Tue, Sep 25, 2018 at 10:15:07AM +0200, Wolfgang Bumiller wrote:
> > Commit d32749deb615 moved the call to monitor_init_globals()
> > to before os_daemonize(), making it an unsuitable place to
> > sp
y has use_io_thread == true.
Instantiation of monitors happens only after os_daemonize().
We still need to create the qmp_dispatcher_bh when not using
iothreads, so this now still happens in
monitor_init_globals().
Signed-off-by: Wolfgang Bumiller
Fixes: d32749deb615 ("monitor: move init glob
depends on the first one, the first is a
consistency cleanup on its own, therefore split out.
Wolfgang Bumiller (2):
monitor: guard iothread access by mon->use_io_thread
monitor: delay monitor iothread creation
monitor.c | 37 ++---
1 file changed,
monitor_resume() and monitor_suspend() both want to
"kick" the I/O thread if it is there, but in
monitor_suspend() lacked the use_io_thread flag condition.
This is required when we later only spawn the thread on
first use.
Signed-off-by: Wolfgang Bumiller
Reviewed-by: Eric Blake
R
y has use_io_thread == true.
Instantiation of monitors happens only after os_daemonize().
We still need to create the qmp_dispatcher_bh when not using
iothreads, so this now still happens in
monitor_init_globals().
Signed-off-by: Wolfgang Bumiller
Fixes: d32749deb615 ("monitor: move init glob
monitor_resume() and monitor_suspend() both want to
"kick" the I/O thread if it is there, but in
monitor_suspend() lacked the use_io_thread flag condition.
This is required when we later only spawn the thread on
first use.
Signed-off-by: Wolfgang Bumiller
---
monitor.c | 2 +-
1 file
On Thu, Sep 20, 2018 at 06:14:11PM +0200, Markus Armbruster wrote:
> Wolfgang Bumiller writes:
>
> > On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> >> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
> >>
> >> > Eithe
On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
>
> > Either way, spawning the iothread on demand can still make sense, as
> > does updating the check in resume()/suspend().
>
> Yep.
Running
On Thu, Sep 20, 2018 at 04:10:00PM +0800, Peter Xu wrote:
> On Thu, Sep 20, 2018 at 10:02:22AM +0200, Wolfgang Bumiller wrote:
> > On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> > > On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > > &
On Thu, Sep 20, 2018 at 10:59:56AM +0800, Peter Xu wrote:
> On Wed, Sep 19, 2018 at 04:58:06PM +0200, Wolfgang Bumiller wrote:
> > On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> > > Peter Xu writes:
> > > > Indeed. So we h
On Wed, Sep 19, 2018 at 03:36:02PM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Sep 05, 2018 at 05:05:10PM +0200, Wolfgang Bumiller wrote:
> >> On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote:
> >> > From: Peter Xu
> >
On Mon, Jun 18, 2018 at 04:08:53PM +0200, Markus Armbruster wrote:
> From: Peter Xu
>
> Before this patch, monitor fd helpers might be called even earlier than
> monitor_init_globals(). This can be problematic.
>
> After previous work, now monitor_init_globals() does not depend on
> accelerator
It is possible for rate limited writes to keep overshooting a slice's
quota by a tiny amount causing the slice-aligned waiting period to
effectively halve the rate.
Signed-off-by: Wolfgang Bumiller
---
Copied the Ccs from the discussion thread, hope that's fine, as I also
just notice
On Mon, Feb 05, 2018 at 03:31:40PM +, Stefan Hajnoczi wrote:
> On Fri, Feb 02, 2018 at 12:10:22PM +0100, Wolfgang Bumiller wrote:
(...)
> > Explanation:
> > The ratelimiting code in include/qemu/ratelimit.h currently uses slices with
> > quotas. Finishing up the quota for
Summary:
Rate limit is effectively halved when the size of written chunks adds up to
exceeding the quota of a slice only slightly. This is surprisingly reliable.
Explanation:
The ratelimiting code in include/qemu/ratelimit.h currently uses slices with
quotas. Finishing up the quota for one slice m
entries again instead to avoid erroneous
"Looped descriptor" errors.
Reported-by: Hans Middelhoek
Link: https://forum.proxmox.com/threads/vm-crash-with-memory-hotplug.35904/
Fixes: 3b3b0628217e ("virtio: slim down allocation of VirtQueueElements")
Signed-off-by: Wolfgang Bumi
On Mon, Feb 13, 2017 at 11:04:30AM +0100, Kevin Wolf wrote:
> Am 12.02.2017 um 01:58 hat Nir Soffer geschrieben:
> > On Sat, Feb 11, 2017 at 12:23 AM, Nir Soffer wrote:
> > > Hi all,
> > >
> > > I'm trying to convert images (mostly qcow2) to raw format on thin lv,
> > > hoping to write only the al
y small cirrus_blt_{width,height} values, which in turn implies
> only a fraction of the blit source will actually be used.
>
> Cc: Wolfgang Bumiller
> Cc: Dr. David Alan Gilbert
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Wolfgang Bumiller
> ---
> hw/display/c
.
Signed-off-by: Wolfgang Bumiller
---
Changes to v1:
* Subtract only bytesperline-1 since the original address should be
included while the byte at `begin-bytesperline` is exclusive.
* Added an assertion to ensure we don't call memory_region_set_dirty()
with a negative size since it
> On January 25, 2017 at 1:35 PM Laszlo Ersek wrote:
>
>
> On 01/25/17 13:12, Wolfgang Bumiller wrote:
> > cirrus_invalidate_region() calls memory_region_set_dirty()
> > on a per-line basis, always ranging from off_begin to
> > off_begin+bytesperline. With a nega
backward blits, otherwise the first iteration
covers the line going from the start offset forwards instead
of backwards.
Signed-off-by: Wolfgang Bumiller
---
I bumped the patch context to 4 lines to get it to include the
memory_region_set_dirty() call which takes an unsigned length (`hwaddr
size
On Wed, Jan 25, 2017 at 11:35:44AM +0100, Laszlo Ersek wrote:
> On 01/25/17 10:50, Gerd Hoffmann wrote:
> > On Mi, 2017-01-25 at 09:30 +0100, Wolfgang Bumiller wrote:
> >> On Wed, Jan 25, 2017 at 08:07:05AM +0100, Gerd Hoffmann wrote:
> >>> From: Li Qiang
> &g
t; Signed-off-by: Li Qiang
> Message-id: 5887254f.863a240a.2c122.5...@mx.google.com
>
> { kraxel: with backward blits (negative pitch) addr is the topmost
> address, so check it as-is against vram size ]
>
> Cc: qemu-sta...@nongnu.org
> Cc: P J P
> Cc: Laszlo E
The rops used by cirrus_bitblt_common_patterncopy only use
the destination pitch, so the source pitch shoul allowed to
be zero and the blit with used for the range check around the
source address.
Signed-off-by: Wolfgang Bumiller
---
I'd also like someone to take a look at cirrus_colorex
On Tue, Jan 24, 2017 at 01:29:58PM +0100, Gerd Hoffmann wrote:
> > >>> if (pitch < 0) {
> > >>> int64_t min = addr
> > >>> -+ ((int64_t)s->cirrus_blt_height-1) * pitch;
> > >>> ++ ((int64_t)s->cirrus_blt_height-1) * pitch
> > >>> +- s->cirrus_blt_wi
Actually this is wrong, sorry, I'll need to send a v2.
On Mon, Jan 23, 2017 at 03:54:55PM +0100, Wolfgang Bumiller wrote:
> The rops used by cirrus_bitblt_common_patterncopy only use
> the destination pitch, so the source pitch shoul allowed to
> be zero.
>
> Signed-off-b
The rops used by cirrus_bitblt_common_patterncopy only use
the destination pitch, so the source pitch shoul allowed to
be zero.
Signed-off-by: Wolfgang Bumiller
---
Resent as requested as non-inline reply; was originally a reply to
thread: [PATCH] display: cirrus: check vga bits per pixel(bpp
0x32] from above values:
rop_to_index[s->vga.gr[0x32]]= 5
(should be ROP2(cirrus_colorexpand_pattern_src) ?)
s->cirrus_blt_pixelwidth = 2
s->cirrus_blt_width = 1242
s->cirrus_blt_height = 27
s->cirrus_blt_srcpitch
On Fri, Dec 02, 2016 at 01:13:28PM -0600, Eric Blake wrote:
> On 12/01/2016 04:59 AM, Wolfgang Bumiller wrote:
> > Fixes #1644754.
> >
> > Signed-off-by: Wolfgang Bumiller
> > ---
> > I'm not sure what the original rationale was to treat both partial
>
Fixes #1644754.
Signed-off-by: Wolfgang Bumiller
---
I'm not sure what the original rationale was to treat both partial
reads as well as well as writes as I/O error. (Seems to have happened
from original glusterfs v1 to v2 series with a note but no reasoning
for the read side as far as I
On Mon, Jan 18, 2016 at 02:02:07PM +0100, Markus Armbruster wrote:
> Wolfgang Bumiller writes:
>
> > On Tue, Jan 12, 2016 at 05:52:38PM +0100, Markus Armbruster wrote:
> >> Wolfgang Bumiller writes:
> >>
> > while (1) {
> > separator = s
The parameter is called 'tls-creds', 'credid' is just the
variable name in the code.
Signed-off-by: Wolfgang Bumiller
---
ui/vnc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 09756cd..2270ac2 100644
--- a/ui/vnc.c
+++ b
On Tue, Jan 12, 2016 at 05:52:38PM +0100, Markus Armbruster wrote:
> Wolfgang Bumiller writes:
>
> >> On January 12, 2016 at 5:00 PM Markus Armbruster wrote:
> >> Will you prepare a revised patch?
> >
> > Can do that tomorrow, but which option i
> On January 12, 2016 at 5:00 PM Markus Armbruster wrote:
> separator = strchr(keys, '-');
> keyname_len = separator ? separator - keys : strlen(keys);
> pstrcpy(keyname_buf, sizeof(keyname_buf), keys);
> [...]
> keyname_buf[keyname_len] = 0;
>
> This is s
Ah I forgot to --signoff, sorry
> On January 12, 2016 at 1:52 PM Wolfgang Bumiller
> wrote:
>
>
> This pointer should be cleared in vnc_display_close()
> otherwise a use-after-free can happen when when using the
> old style 'x509' and 'tls' options rat
This pointer should be cleared in vnc_display_close()
otherwise a use-after-free can happen when when using the
old style 'x509' and 'tls' options rather than a persistent
tls-creds -object, by issuing monitor commands to change
the vnc server like so:
Start with: -vnc unix:test.socket,x509,tls
Th
> On January 12, 2016 at 9:45 AM Markus Armbruster wrote:
>
> Wolfgang Bumiller writes:
>
> > When processing 'sendkey' command, hmp_sendkey routine null
> > terminates the 'keyname_buf' array. This results in an OOB
>
> Well, it technica
me_buf, sizeof(keyname_buf), "less")
instead of a memcpy() (after all, the buffer size is known and the
contents are constant in that line).
Patch:
===
>From 8da4a3bf8fb076314f986a0d58cb94f5458e3659 Mon Sep 17 00:00:00 2001
From: Wolfgang Bumiller
Date: Mon, 11 Jan 2016 08:21:25 +0100
S
> On January 8, 2016 at 6:32 PM P J P wrote:
>
>
> +-- On Fri, 8 Jan 2016, Wolfgang Bumiller wrote --+
> | On Fri, Jan 08, 2016 at 07:29:31PM +0530, P J P wrote:
> | > + if (!strncmp(keyname_buf, "<-", 2))
> | > and remove the 'keyname_
On Fri, Jan 08, 2016 at 07:29:31PM +0530, P J P wrote:
> +-- On Fri, 8 Jan 2016, Wolfgang Bumiller wrote --+
> | Ah yes, how could I miss that. Maybe just add a min() around the
> | keyname_len computation?
> |
> | - keyname_len = separator ? separator - keys : strlen(keys);
&g
On Fri, Jan 08, 2016 at 05:49:51PM +0530, P J P wrote:
>Hello,
>
> +-- On Fri, 8 Jan 2016, Wolfgang Bumiller wrote --+
> | > if (!strncmp(keyname_buf, "<", 1) && keyname_len == 1) {
> | > pstrcpy(keyname_buf, sizeof(keyname_buf
On Thu, Dec 17, 2015 at 06:10:59PM +0530, P J P wrote:
> Hello,
>
> An OOB write issue was reported by Mr Ling Liu, CC'd here. It occurs while
> processing the 'sendkey' command, if the command argument was longer than
> the 'keyname_buf[16]' buffer.
>
> ===
> From b0363f4c0e91671064dd7ffece8a6
Hi,
We have problems with a HP ProLiant DL380 Gen9 and Vm's with large
amount of memory, grater then 30GB.
The problem is that the vm need about 10 sec to start to boot.
and when it comes to syncing the cpu clock, it takes a long time to
finish this task.
What also occurs is the vcpus need at
Thanks you for the quick reply and the good news.
Wolfgang
On 11/13/2015 04:01 PM, Paolo Bonzini wrote:
On 13/11/2015 15:55, Wolfgang Link wrote:
Hi,
We have problems with a HP ProLiant DL380 Gen9 and Vm's with large
amount of memory, grater then 30GB.
The problem is that the vm need
Public bug reported:
When using virtualization on notebooks heavily then virtual machines do
not realize that they're running on a notebook device causing high power
consumption because they're not switching into a optimized "laptop
mode". This leads to the circumstance that they are trying to do
: Wolfgang Bumiller
---
ui/vnc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 94e4f19..1483958 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2551,7 +2551,7 @@ static int protocol_client_auth_vnc(VncState *vs, uint8_t
*data, size_t len)
goto reject
> Fails to build on Windows:
>
> util/qemu-sockets.c: In function ‘inet_parse_connect_opts’:
> util/qemu-sockets.c:338: error: ‘AI_V4MAPPED’ undeclared (first use in
What's the procedure with the trivial pull-request here now. Should I
send a v2 of this patch to trivial, or a fix based on the tri
ntioned it in
the json's doc string.
Wolfgang Bumiller (1):
vvfat: add a label option
block/vvfat.c| 25 ++---
qapi/block-core.json | 6 +-
2 files changed, 27 insertions(+), 4 deletions(-)
--
2.1.4
ver aren't exposed to the user by
operating systems.
Signed-off-by: Wolfgang Bumiller
---
block/vvfat.c| 25 ++---
qapi/block-core.json | 6 +-
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index e803589..1f8a2
Till now the vvfat filesystem's label was hardcoded to be
"QEMU VVFAT", now you can pass a file.label=labelname option
to the -drive to change it.
Signed-off-by: Wolfgang Bumiller
---
block/vvfat.c| 25 ++---
qapi/block-core.json | 3 ++-
2 fi
Tanks for your tips.
2014-12-17 10:02 GMT+01:00 Markus Armbruster :
> > +if (queues == 0) {
> > +error_set(errp, QERR_DEVICE_NOT_FOUND, name);
> > +return (int64_t) -1;
> > +}
> > +
> > +nc = ncs[0];
> > +ret = ncs[0]->link_down;
> > +
> > +if (nc->peer->info->
this qmp command returns the current link state from the given nic
this is impotent if the set_link failed or get an timeout.
Signed-off-by: Wolfgang Link
---
net/net.c| 26 ++
qapi-schema.json | 15 +++
qmp-commands.hx | 22
The way I see block filter currently implemented is as a special block
device
with `is_filter` set to true.
Is this a correct characterization of the current incarnation?
If so, I was wondering if it is possible to "insert" a block filter layer
on top
of an existing block device once QEMU is exec
On Sat, Oct 12, 2013 at 1:47 AM, Fam Zheng wrote:
> While mirroring write is a good idea, doing it with drive-backup is probably
> not. The function of this command is to 'backup' the image with existing data,
> instead of new data. With your 'stream' mode, this semantic is changed.
I'm not so su
On Fri, Oct 11, 2013 at 11:38 AM, Eric Blake wrote:
> On 10/11/2013 09:18 AM, Wolfgang Richter wrote:
>> Idea: Introduce a mode for drive-backup that duplicates writes to
>> another target, not CoW. It is useful for introspecting (my use
>> case), and for keeping a remote
Idea: Introduce a mode for drive-backup that duplicates writes to
another target, not CoW. It is useful for introspecting (my use
case), and for keeping a remote block device in sync with writes
(helps with migration or backup).
Issue with current modes: All of the current modes are well-desig
On Mon, Sep 30, 2013 at 3:41 AM, Paolo Bonzini wrote:
> Il 30/09/2013 00:46, Wolfgang Richter ha scritto:
> All writes to the drive-backup source have to first copy the pre-write
> data to the target. Thus, drive-backup usually works best if you are
> using werror=stop on the source
I wanted to explore overhead with the new drive-backup command and I
noticed if I set the target to something like '/dev/null' the guest VM
starts having IO errors and loses write access to its root file
system. Here is the qmp-shell command I'm using:
> drive-backup sync=none device=virtio0 targ
Hi again,
compiled, tested, seems to work for me.
Fulfilling my own request, if that's OK for you, Alex. Download and try Alex'
packages here on your own responsibility:
http://www.wogri.at/Qemu-Ceph-Packages.343.0.html
Wolfgang
On Fri, Jun 21, 2013 at 03:41:53PM +0100, Alex B
On Wed, May 22, 2013 at 3:26 PM, Richard W.M. Jones wrote:
> On Wed, May 22, 2013 at 02:32:37PM -0400, Wolfgang Richter wrote:
> > On Wed, May 22, 2013 at 12:42 PM, Richard W.M. Jones >wrote:
> >
> > > Run up to two extra guestfish instances, with the same result.
I am in charge of a workshop happening at CMU with
21 guests currently registered.
It will be on using QEMU/KVM, coding inside those codebases,
using libvirt, and possibly OpenStack.
We will have several talks during the day on how people have
used QEMU + KVM in their own research, tips and trick
On Wed, May 22, 2013 at 12:42 PM, Richard W.M. Jones wrote:
> Run up to two extra guestfish instances, with the same result. The
> fourth guestfish instance hangs at the 'run' command until one of the
> first three is told to exit.
And your interested on being notified when a snapshot is "safe"
On Wed, May 22, 2013 at 12:11 PM, Paolo Bonzini wrote:
> > Essentially, if you're RWMJ (not me), and you're keeping a full
> > mirror, it's clear that the mirror write stream goes to an nbd server,
> > but is it possible to attach a reader to that same nbd server and read
> > things back (read-on
On Thu, May 16, 2013 at 9:44 AM, Richard W.M. Jones wrote:
> Ideally I'd like to issue some QMP commands which would set up the
> point-in-time snapshot, and then connect to this snapshot over (eg)
> NBD, then when I'm done, send some more QMP commands to tear down the
snapshot.
>
This is actual
On Wed, May 15, 2013 at 7:54 AM, Paolo Bonzini wrote:
> > But does this really cover all use cases a real synchronous active
> > mirror would provide? I understood that Wolf wants to get every single
> > guest request exposed e.g. on an NBD connection.
>
> He can use throttling to limit the guest
On Tue, May 14, 2013 at 12:45 PM, Paolo Bonzini wrote:
> No, I'll just reuse the same hooks within block/mirror.c (almost... it
> looks like I need after_write too, not just before_write :( that's a
> pity). Basically:
>
> 1) before the write, if there is space in the job's buffers, allocate a
>
On Tue, May 14, 2013 at 6:04 AM, Paolo Bonzini wrote:
> Il 14/05/2013 10:50, Kevin Wolf ha scritto:
> > Or, to translate it into our existing terminology, drive-mirror
> > implements a passive mirror, you're proposing an active one (which we
> > do want to have).
> >
> > With an active mirror, we
On Tue, May 14, 2013 at 4:50 AM, Kevin Wolf wrote:
> Or, to translate it into our existing terminology, drive-mirror
> implements a passive mirror, you're proposing an active one (which we
> do want to have).
>
> With an active mirror, we'll want to have another choice: The mirror can
> be synchr
On Tue, May 14, 2013 at 4:40 AM, Stefan Hajnoczi wrote:
> QEMU is accumulating many different approaches to snapshots and
> mirroring. They all have their pros and cons so it's not possible to
> support only one approach for all use cases.
>
> The suggested approach is writing a BlockDriver which
On May 13, 2013, at 5:46 PM, "Richard W.M. Jones" wrote:
> On Mon, May 13, 2013 at 01:50:00PM -0400, Wolfgang Richter wrote:
>> Paolo/anyone who knows -
>>
>> Are drive-mirror sync points (NBD flush commands) reflecting guest write
>> barriers? Are gu
I'm working on a new patch series which will add a new QMP command,
block-trace, which turns on tracing of writes for a specified block device
and
sends the stream unmodified to another block device. The 'trace' is meant
to
be precise meaning that writes are not lost, which differentiates this
com
Paolo/anyone who knows -
Are drive-mirror sync points (NBD flush commands) reflecting guest write
barriers? Are guest write barriers respected by drive-mirror? If so, that
would make drive-mirror much more palatable for disk introspection work (a
drop-in usable feature of QEMU!).
--
Wolf
t message, and perhaps the manual
> (STEXI..ETEXI section in qemu-options.hx).
sure, updated patch is attached (I've also updated the github repository).
Thanks, Wolfgang
---
>From 6c85a1d11ca0f8ceaf4fbf7c97a0aaa1b145acd2 Mon Sep 17 00:00:00 2001
From: Wolfgang Mauerer
Date: Tue, 7 M
Hello,
On 17/01/13 21:21, Stefan Weil wrote:
> Am 17.01.2013 18:10, schrieb Wolfgang Mauerer:
>> For slow targets and fast hosts, the emulation may be faster
>> than the actual hardware, which can be undesirable for various
>> reasons. Add a run-time option to slow dow
On Wed, Apr 24, 2013 at 1:37 AM, Stefan Hajnoczi wrote:
> I think what you really want is a "tap" block driver which mirrors
> writes to a target device (typically a NBD volume). You can model this
> on blkverify or check out Benoit Canet's quorum patches.
>
> Stefan
>
An interesting thought, w
On Wed, Apr 24, 2013 at 12:15 PM, Paolo Bonzini wrote:
> Il 24/04/2013 18:12, Wolfgang Richter ha scritto:
> > In the purest form, not to miss "updates" I'm not OK with it. But, I
> think
> > that introspection can still _mostly_ work given these relaxed
> c
On Wed, Apr 24, 2013 at 5:26 AM, Paolo Bonzini wrote:
> Il 23/04/2013 20:31, Wolfgang Richter ha scritto:
> > On Tue, Apr 23, 2013 at 2:21 PM, Stefan Hajnoczi > <mailto:stefa...@gmail.com>> wrote:
> >
> > The tracing subsystem is geared towards tracepoint in
On Wed, Apr 24, 2013 at 5:24 AM, Paolo Bonzini wrote:
> Il 24/04/2013 10:37, Stefan Hajnoczi ha scritto:
> >> > Has there been any performance analysis of drive-mirror (impact on
> executing guest)?
>
> What Stefan wrote is about block-backup.
>
> drive-mirror has a limited impact on guest perfor
On Wed, Apr 24, 2013 at 4:39 AM, Stefan Hajnoczi wrote:
> On Tue, Apr 23, 2013 at 03:11:26PM -0400, Wolfgang Richter wrote:
> > On Tue, Apr 23, 2013 at 2:31 PM, Wolfgang Richter
> wrote:
> >
> > > On Tue, Apr 23, 2013 at 2:21 PM, Stefan Hajnoczi >wrote:
> &g
On Wed, Apr 24, 2013 at 4:37 AM, Stefan Hajnoczi wrote:
> > Has there been any performance analysis of drive-mirror (impact on
> executing guest)?
>
> It slows down guest I/O for a couple of reasons:
>
> 1. Writes now require a read from the original device followed by a
>write to the target
1 - 100 of 165 matches
Mail list logo
