I just noticed that after I applied the latest updates (apt-get dist-
ugrade) to my Ubuntu 14.04 system that USB redirection is now failing on
THIS system as well - just like the 14.10 system failed.
FWIW, I do not see any apparomor denial messages in /var/log/syslog or
anywhere else. So far I've
Hi,
I notice that Qemu supports dump virtual memory of Guest OS. As this
page suggests:
http://doc.opensuse.org/products/draft/SLES/SLES-kvm_sd_draft/cha.qemu.monitor.html
To save the content of the virtual machine memory to a disk or console
output, use the following commands:
memsave
Am 28.11.2014 um 15:12 schrieb Paolo Bonzini:
> From: Peter Lieven
>
> Placing coroutines on the global pool should be preferrable, because it
> can help all threads. But if the global pool is full, we can still
> try to save some allocations by stashing completed coroutines on the
> local pool.
Am 28.11.2014 um 15:17 schrieb Paolo Bonzini:
>
> On 28/11/2014 14:17, Peter Lieven wrote:
>> The release_pool is not cleanup up on termination I think.
That's not necessary, it is global.
>> I don't see where you iterate over release_pool and destroy all coroutines?
> The OS does that fo
On 28/11/2014 19:34, Kevin Wolf wrote:
>>> > > Not sure if speculations about the future belong into commit messages,
>>> > > but while it may turn out that a bypass is required in the end (I hope
>>> > > it doesn't), the part about AIOCBs is wrong if you really consistently
>>> > > use coroutine
Am 28.11.2014 um 18:31 hat Paolo Bonzini geschrieben:
>
>
> On 28/11/2014 17:40, Kevin Wolf wrote:
> >> > I still believe we will end with some kind of coroutine bypass scheme
> >> > (even coroutines _do_ allocate an AIOCB, so calling bdrv_aio_readv
> >> > directly can help), but hey it cannot hu
On 28/11/2014 17:40, Kevin Wolf wrote:
>> > I still believe we will end with some kind of coroutine bypass scheme
>> > (even coroutines _do_ allocate an AIOCB, so calling bdrv_aio_readv
>> > directly can help), but hey it cannot hurt to optimize hot code.
>
> Not sure if speculations about the fu
On 28/11/2014 17:40, Kevin Wolf wrote:
>> > I still believe we will end with some kind of coroutine bypass scheme
>> > (even coroutines _do_ allocate an AIOCB, so calling bdrv_aio_readv
>> > directly can help), but hey it cannot hurt to optimize hot code.
>
> Not sure if speculations about the fu
On 28/11/2014 16:55, Markus Armbruster wrote:
> Copying Luiz.
>
> Max Reitz writes:
>
>> This series does not add new functionality. Adding a QMP monitor with
>> prettily formatted JSON output can be done as follows:
>>
>> $ qemu -chardev stdio,id=mon0 -mon chardev=mon0,mode=control,pretty=on
Am 28.11.2014 um 15:12 hat Paolo Bonzini geschrieben:
> I still believe we will end with some kind of coroutine bypass scheme
> (even coroutines _do_ allocate an AIOCB, so calling bdrv_aio_readv
> directly can help), but hey it cannot hurt to optimize hot code.
Not sure if speculations about the f
On 28 November 2014 at 11:43, Stefan Hajnoczi wrote:
> Right, the test case explicitly tests different descriptor layouts,
> even though virtio-blk-pci does not set the ANY_LAYOUT feature bit.
>
> Either the test case needs to check ANY_LAYOUT before using the
> 2-descriptor layout or it needs to
Copying Luiz.
Max Reitz writes:
> This series does not add new functionality. Adding a QMP monitor with
> prettily formatted JSON output can be done as follows:
>
> $ qemu -chardev stdio,id=mon0 -mon chardev=mon0,mode=control,pretty=on
>
> However, this is rather cumbersome, so this series (its
Kevin Wolf writes:
> Am 20.11.2014 um 13:44 hat Max Reitz geschrieben:
>> The 'change' QMP and HMP command allows replacing the medium in drives
>> which support this, e.g. floppy disk drives. For some drives, the medium
>> carries information about whether it can be written to or not (again,
>>
Am 28.11.2014 um 15:45 hat Markus Armbruster geschrieben:
> Paolo Bonzini writes:
>
> > ELF thread local storage is about 10% faster on tests/test-coroutine's
> > perf/cost test. The timing on my machine is 160ns per iteration with
> > pthread TLS, 145 with ELF TLS.
> >
> > Based on a patch by K
On 28 November 2014 at 11:47, Greg Kurz wrote:
> FWIW I think it should. Commit 3902d49e13c2428bd6381cfdf183103ca4477c1f is
> clearly bad: virtio-rng does not need the .load callback obviously... and
> the fact it breaks migration makes it even worse... :(
>
> Please apply to 2.2.
Applied to mast
Paolo Bonzini writes:
> ELF thread local storage is about 10% faster on tests/test-coroutine's
> perf/cost test. The timing on my machine is 160ns per iteration with
> pthread TLS, 145 with ELF TLS.
>
> Based on a patch by Kevin Wolf and Peter Lieven, but redone to follow
> the model of coroutin
On Fri, 28 Nov 2014 07:53:41 +0200
Marcel Apfelbaum wrote:
> On Fri, 2014-11-28 at 09:50 +0800, Zhu Guihua wrote:
> > On Thu, 2014-11-27 at 15:48 +0200, Marcel Apfelbaum wrote:
> > > On Thu, 2014-11-27 at 13:38 +0100, Igor Mammedov wrote:
> > > > On Thu, 27 Nov 2014 13:41:07 +0200
> > > > Marcel
On 28 November 2014 at 14:12, Paolo Bonzini wrote:
> +/* This function is marked noinline to prevent GCC from inlining it
> + * into coroutine_trampoline(). If we allow it to do that then it
> + * hoists the code to get the address of the TLS variable "current"
> + * out of the while() loop. This
On 28/11/2014 14:17, Peter Lieven wrote:
>>> >> The release_pool is not cleanup up on termination I think.
>> > That's not necessary, it is global.
> I don't see where you iterate over release_pool and destroy all coroutines?
The OS does that for us when we exit.
Paolo
From: Peter Lieven
Placing coroutines on the global pool should be preferrable, because it
can help all threads. But if the global pool is full, we can still
try to save some allocations by stashing completed coroutines on the
local pool. This is quite cheap too, because it does not require
ato
On 28/11/2014 14:46, Iwan Budi Kusnanto wrote:
> On Fri, Nov 28, 2014 at 7:47 PM, Stefan Hajnoczi wrote:
>> On Fri, Nov 28, 2014 at 01:55:00PM +0700, Iwan Budi Kusnanto wrote:
>>> I meant, does the coroutine will do yield internally when it get
>>> blocked on send(3)?
>>
>> No. In general, QEMU
On Thu, Nov 20, 2014 at 06:06:34PM +0100, Max Reitz wrote:
> @@ -2674,6 +2743,7 @@ static int qcow2_amend_options(BlockDriverState *bs,
> QemuOpts *opts,
> bool encrypt;
> int ret;
> QemuOptDesc *desc = opts->list->desc;
> +Qcow2AmendHelperCBInfo helper_cb_info;
>
> while
This is not needed anymore. The new TLS-based algorithm is adaptive.
Signed-off-by: Paolo Bonzini
---
block/block-backend.c | 4
include/block/coroutine.h | 10 --
qemu-coroutine.c | 4
3 files changed, 18 deletions(-)
diff --git a/block/block-backend.c b/block
This patch removes the mutex by using fancy lock-free manipulation of
the pool. Lock-free stacks and queues are not hard, but they can suffer
from the ABA problem so they are better avoided unless you have some
deferred reclamation scheme like RCU. Otherwise you have to stick
with adding to a lis
These operations are trivial to implement and do not have ABA problems.
They are enough to implement simple multiple-producer, single consumer
lock-free lists or, as in the next patch, the multiple consumers can
steal a whole batch of elements and process them at their leisure.
Signed-off-by: Paol
Destructors are the main additional feature of pthread TLS compared
to __thread. If we were using C++ (hint, hint!) we could have used
thread-local objects with a destructor. Since we are not, instead,
we add a simple Notifier-based API.
Note that the notifier must be per-thread as well. We can
ELF thread local storage is about 10% faster on tests/test-coroutine's
perf/cost test. The timing on my machine is 160ns per iteration with
pthread TLS, 145 with ELF TLS.
Based on a patch by Kevin Wolf and Peter Lieven, but redone to follow
the model of coroutine-win32.c (including the important
As discussed in the other thread, this brings speedups from
dropping the coroutine mutex (which serializes multiple iothreads,
too) and using ELF thread-local storage.
The speedup in perf/cost is about 30% (190->145). Windows port tested
with tests/test-coroutine.exe under Wine.
Paolo
Paolo Bon
unsigned long is not large enough to represent 10 * duration there.
Just use floating point.
Signed-off-by: Paolo Bonzini
---
tests/test-coroutine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/test-coroutine.c b/tests/test-coroutine.c
index e22fae1..27d1b6f
El Fri, 28 Nov 2014 11:43:59 +
Stefan Hajnoczi escribió:
> On Fri, Nov 28, 2014 at 7:05 AM, Jason Wang
> wrote:
> >
> >
> > On Fri, Nov 28, 2014 at 9:16 AM, Fam Zheng wrote:
> >>
> >> On Thu, 11/27 23:13, Michael S. Tsirkin wrote:
> >>>
> >>> On Thu, Nov 27, 2014 at 07:21:35PM +, Stefan
Hi all,
I have some questions regarding developing async network protocol
based block driver for qemu.
The network file server has async client library, and i think it will
be good if i can use it.
1. Is it OK to use libevent inside block driver.
What make me worried is that qemu itself said to b
On 11/28/14 14:33, Mark Rutland wrote:
> On Fri, Nov 28, 2014 at 01:22:29PM +, Laszlo Ersek wrote:
>> On 11/28/14 13:59, Arnd Bergmann wrote:
>>> We don't normally list contiguous registers separately. Maybe just round
>>> up to one page and make the register property
>>>
>>> reg = <0x0 0x
On 11/28/14 14:17, Mark Rutland wrote:
> Hi,
>
> On Fri, Nov 28, 2014 at 12:26:44PM +, Laszlo Ersek wrote:
>> Peter Maydell suggested that we describe new devices / DTB nodes in the
>> kernel Documentation tree that we expose to arm "virt" guests in QEMU.
>>
>> Although the kernel is not requi
On Fri, Nov 28, 2014 at 7:47 PM, Stefan Hajnoczi wrote:
> On Fri, Nov 28, 2014 at 01:55:00PM +0700, Iwan Budi Kusnanto wrote:
>> I meant, does the coroutine will do yield internally when it get
>> blocked on send(3)?
>
> No. In general, QEMU will use non-blocking file descriptors so the
> blockin
Am 28.11.2014 um 13:57 hat Kevin Wolf geschrieben:
> Am 27.11.2014 um 10:50 hat Peter Lieven geschrieben:
> > On 26.11.2014 15:46, Kevin Wolf wrote:
> > >This improves the performance of requests because an ACB doesn't need to
> > >be allocated on the heap any more. It also makes the code nicer and
Stefan Hajnoczi writes:
> On Wed, Nov 26, 2014 at 03:01:02PM +0100, Paolo Bonzini wrote:
>> Use the external qemu-timer API instead.
>>
>> Cc: kw...@redhat.com
>> Cc: stefa...@redhat.com
>> Signed-off-by: Paolo Bonzini
>> ---
>> block/accounting.c | 6 --
>> block/raw-posix.c | 8
Ekaterina Tumanova writes:
> On 11/28/2014 01:35 PM, Stefan Hajnoczi wrote:
>> On Wed, Nov 26, 2014 at 01:16:48PM +0300, Ekaterina Tumanova wrote:
>>> On 11/25/2014 04:01 PM, Stefan Hajnoczi wrote:
On Wed, Nov 19, 2014 at 11:17:50AM +0100, Ekaterina Tumanova wrote:
3. Why does s390 need
On 27 May 2014 at 22:38, Peter Maydell wrote:
> I'm seeing this test failure intermittently on 'make check':
>
> ERROR:/root/qemu/tests/acpi-test.c:618:test_acpi_one: assertion failed
> (signature == SIGNATURE): (0x == 0xdead)
> GTester: last random seed: R02S8d0d60963e4442ce284a81d20c
On Fri, Nov 28, 2014 at 01:22:29PM +, Laszlo Ersek wrote:
> On 11/28/14 13:59, Arnd Bergmann wrote:
> > On Friday 28 November 2014 13:26:44 Laszlo Ersek wrote:
> >> +Example:
> >> +
> >> +/ {
> >> + #size-cells = <0x2>;
> >> + #address-cells = <0x2>;
> >> +
> >> + fw-cfg@90200
On Thu, Nov 20, 2014 at 06:06:29PM +0100, Max Reitz wrote:
> Progress may regress; this should be displayed correctly by
> qemu_progress_print().
>
> Signed-off-by: Max Reitz
> ---
> util/qemu-progress.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Stefan Hajnoczi
pgpPiR00qqiIx.pgp
D
On 21.11.2014 19:55, Stefan Hajnoczi wrote:
Active dirty bitmaps should migrate too. I'm thinking now that the
appropriate thing is to add live migration of dirty bitmaps to QEMU
(regardless of whether they are active or not).
I think, we should migrate named dirty bitmaps, which are not used no
On 11/28/2014 03:52 PM, Markus Armbruster wrote:
Ekaterina Tumanova writes:
Suggest function comment
/**
* Return logical block size, or zero if we can't figure it out
*/
{
-BDRVRawState *s = bs->opaque;
-char *buf;
-unsigned int sector_size;
-
-/* Fo
On Thu, Nov 20, 2014 at 06:06:33PM +0100, Max Reitz wrote:
> If the image version should be upgraded, that is the first we should do;
> if it should be downgraded, that is the last we should do. So split the
> version change block into an upgrade part at the start and a downgrade
> part at the end.
On 11/28/14 13:59, Arnd Bergmann wrote:
> On Friday 28 November 2014 13:26:44 Laszlo Ersek wrote:
>> +Example:
>> +
>> +/ {
>> + #size-cells = <0x2>;
>> + #address-cells = <0x2>;
>> +
>> + fw-cfg@902 {
>> + reg = <0x0 0x902 0x0 0x2 0x0 0x9020002 0x0 0x1>;
>>
On Thu, Nov 20, 2014 at 06:06:32PM +0100, Max Reitz wrote:
> Signed-off-by: Max Reitz
> Reviewed-by: Eric Blake
> ---
> block/qcow2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Stefan Hajnoczi
pgpwibsjgMgJ0.pgp
Description: PGP signature
On Thu, Nov 20, 2014 at 06:06:31PM +0100, Max Reitz wrote:
> Signed-off-by: Max Reitz
> Reviewed-by: Eric Blake
> ---
> block/qcow2.c | 14 ++
> tests/qemu-iotests/061.out | 14 +++---
> 2 files changed, 13 insertions(+), 15 deletions(-)
Reviewed-by: Stefan Hajn
Hi,
On Fri, Nov 28, 2014 at 12:26:44PM +, Laszlo Ersek wrote:
> Peter Maydell suggested that we describe new devices / DTB nodes in the
> kernel Documentation tree that we expose to arm "virt" guests in QEMU.
>
> Although the kernel is not required to access the fw_cfg interface,
> "Documenta
Am 28.11.2014 um 13:45 schrieb Paolo Bonzini:
>
> On 28/11/2014 13:39, Peter Lieven wrote:
>> Am 28.11.2014 um 13:26 schrieb Paolo Bonzini:
>>> On 28/11/2014 12:46, Peter Lieven wrote:
> I get:
> Run operation 4000 iterations 9.883958 s, 4046K operations/s, 247ns
> per coroutine
>>
On Thu, Nov 20, 2014 at 06:06:28PM +0100, Max Reitz wrote:
> Add a creation option to qcow2 for setting the refcount order of images
> to be created, and respect that option's value.
>
> This breaks some test outputs, fix them.
>
> Signed-off-by: Max Reitz
> Reviewed-by: Eric Blake
> ---
> blo
Am 28.11.2014 um 13:39 schrieb Peter Lieven:
> Am 28.11.2014 um 13:26 schrieb Paolo Bonzini:
>> On 28/11/2014 12:46, Peter Lieven wrote:
I get:
Run operation 4000 iterations 9.883958 s, 4046K operations/s, 247ns
per coroutine
>>> Ok, understood, it "steals" the whole pool, right
On Thu, Nov 20, 2014 at 06:06:27PM +0100, Max Reitz wrote:
> Some tests do not work well with certain refcount widths (i.e. you
> cannot create internal snapshots with refcount_width=1), so make those
> widths unsupported.
>
> Furthermore, add another filter to _filter_img_create in common.filter
In KVM ARM64 one can choose to run guest in 32bit mode i.e EL1 in AARCH32 mode.
This patch adds qemu support for running guest EL1 in AARCH32 mode with
virt as a machine model.
This patch also adds a support to run Image (along with zImage) for arm32.
One can specify about 32bit kernel Image by us
On 27 November 2014 at 10:04, Jason Wang wrote:
> virtio_net_handle_ctrl() and other functions that process control vq
> request call iov_discard_front() which will shorten the iov. This will
> lead unmapping in virtqueue_push() leaks mapping.
>
> Fixes this by keeping the original iov untouched a
On Friday 28 November 2014 13:26:44 Laszlo Ersek wrote:
> +Example:
> +
> +/ {
> + #size-cells = <0x2>;
> + #address-cells = <0x2>;
> +
> + fw-cfg@902 {
> + reg = <0x0 0x902 0x0 0x2 0x0 0x9020002 0x0 0x1>;
> + compatible = "fw-cfg,mmio";
> +
Ekaterina Tumanova writes:
> On 11/28/2014 01:10 PM, Markus Armbruster wrote:
>> Ekaterina Tumanova writes:
>>
>>> hd_geometry_guess function autodetects the drive geometry. This patch
>>> adds a block backend call, that probes the backing device geometry.
>>> If the inner driver method is imple
Am 27.11.2014 um 10:50 hat Peter Lieven geschrieben:
> On 26.11.2014 15:46, Kevin Wolf wrote:
> >This improves the performance of requests because an ACB doesn't need to
> >be allocated on the heap any more. It also makes the code nicer and
> >smaller.
> >
> >As a side effect, the codepath taken by
On 28/11/2014 13:49, Peter Lieven wrote:
>>> Idea:
>>> >> If the release_pool is full why not put the coroutine in the thread
>>> >> alloc_pool instead of throwing it away? :-)
>> > Because you can only waste 64 coroutines per thread. But numbers cannot
s/only//
>> > be sneezed at, so it's w
Ekaterina Tumanova writes:
>>
>> Suggest function comment
>>
>> /**
>> * Return logical block size, or zero if we can't figure it out
>> */
>>
>>> {
>>> -BDRVRawState *s = bs->opaque;
>>> -char *buf;
>>> -unsigned int sector_size;
>>> -
>>> -/* For /dev/sg devic
Am 28.11.2014 um 13:45 schrieb Paolo Bonzini:
>
> On 28/11/2014 13:39, Peter Lieven wrote:
>> Am 28.11.2014 um 13:26 schrieb Paolo Bonzini:
>>> On 28/11/2014 12:46, Peter Lieven wrote:
> I get:
> Run operation 4000 iterations 9.883958 s, 4046K operations/s, 247ns
> per coroutine
>>
On Fri, Nov 28, 2014 at 01:55:00PM +0700, Iwan Budi Kusnanto wrote:
> I meant, does the coroutine will do yield internally when it get
> blocked on send(3)?
No. In general, QEMU will use non-blocking file descriptors so the
blocking case does not apply. (You can't use blocking file descriptors
i
Am 28.11.2014 um 13:42 schrieb Stefan Hajnoczi:
> On Thu, Nov 27, 2014 at 11:27:04AM +0100, Peter Lieven wrote:
>> This reverts commit ac2662a913ee5854b1269256adbdc14e57ba480a.
> Justification?
>
> Won't we hit the same problem as the global pool: either pool size is
> too large or too small. If y
On 28/11/2014 13:39, Peter Lieven wrote:
> Am 28.11.2014 um 13:26 schrieb Paolo Bonzini:
>>
>> On 28/11/2014 12:46, Peter Lieven wrote:
I get:
Run operation 4000 iterations 9.883958 s, 4046K operations/s, 247ns
per coroutine
>>> Ok, understood, it "steals" the whole pool, righ
On Thu, Nov 27, 2014 at 01:21:54PM +, Peter Maydell wrote:
> On 27 November 2014 at 12:29, Stefan Hajnoczi wrote:
> > 1. Convert all cpu_physical_memory_*_dirty() callers to use the API
> > atomically.
> >There are TCG callers who things along the lines of:
> >
> > if (!cpu_physical_
On Thu, Nov 27, 2014 at 11:27:04AM +0100, Peter Lieven wrote:
> This reverts commit ac2662a913ee5854b1269256adbdc14e57ba480a.
Justification?
Won't we hit the same problem as the global pool: either pool size is
too large or too small. If you exceed the pool size performance drops
dramatically.
On Thu, Nov 27, 2014 at 11:27:06AM +0100, Peter Lieven wrote:
> diff --git a/iothread.c b/iothread.c
> index 342a23f..b53529b 100644
> --- a/iothread.c
> +++ b/iothread.c
> @@ -15,6 +15,7 @@
> #include "qom/object_interfaces.h"
> #include "qemu/module.h"
> #include "block/aio.h"
> +#include "blo
On 28/11/2014 12:28, Pavel Dovgaluk wrote:
> Not so easy :)
> cpu_get_clock() checks vm_clock_seqlock which is locked in icount_warp_rt().
> And after locking it requests the value of QEMU_CLOCK_VIRTUAL_RT:
>
> seqlock_write_lock(&timers_state.vm_clock_seqlock);
> if (runstate_is_running
Am 28.11.2014 um 13:26 schrieb Paolo Bonzini:
>
> On 28/11/2014 12:46, Peter Lieven wrote:
>>> I get:
>>> Run operation 4000 iterations 9.883958 s, 4046K operations/s, 247ns per
>>> coroutine
>> Ok, understood, it "steals" the whole pool, right? Isn't that bad if we have
>> more
>> than one t
v2 was: with RFC. Since last review round I dropped the tag
because I think now all the open points are addressed.
v1 was: "add watermark reporting for block devices", but
"watermark" is incorrectly unused. Hence the change in subject.
Changes since v2:
-
addressed reviewers comme
Managing applications, like oVirt (http://www.ovirt.org), make extensive
use of thin-provisioned disk images.
To let the guest run smoothly and be not unnecessarily paused, oVirt sets
a disk usage threshold (so called 'high water mark') based on the occupation
of the device, and automatically exte
Peter Maydell suggested that we describe new devices / DTB nodes in the
kernel Documentation tree that we expose to arm "virt" guests in QEMU.
Although the kernel is not required to access the fw_cfg interface,
"Documentation/devicetree/bindings/arm" is probably the best central spot
to keep the f
On 28/11/2014 12:46, Peter Lieven wrote:
> > I get:
> > Run operation 4000 iterations 9.883958 s, 4046K operations/s, 247ns per
> > coroutine
>
> Ok, understood, it "steals" the whole pool, right? Isn't that bad if we have
> more
> than one thread in need of a lot of coroutines?
Overall th
Am 28.11.2014 um 13:21 schrieb Paolo Bonzini:
>
> On 28/11/2014 12:32, Peter Lieven wrote:
>> Am 28.11.2014 um 12:23 schrieb Paolo Bonzini:
>>> On 28/11/2014 12:21, Peter Lieven wrote:
Am 28.11.2014 um 12:14 schrieb Paolo Bonzini:
>> master:
>> Run operation 4000 iterations 12.8514
On 28/11/2014 12:32, Peter Lieven wrote:
> Am 28.11.2014 um 12:23 schrieb Paolo Bonzini:
>>
>> On 28/11/2014 12:21, Peter Lieven wrote:
>>> Am 28.11.2014 um 12:14 schrieb Paolo Bonzini:
> master:
> Run operation 4000 iterations 12.851414 s, 3112K operations/s, 321ns
> per corouti
Am 28.11.2014 um 12:49 hat Stefan Hajnoczi geschrieben:
> On Wed, Nov 26, 2014 at 03:46:42PM +0100, Kevin Wolf wrote:
> > +while (data.n > 0) {
> > +main_loop_wait(false);
> > +}
>
> Why is this false (non-blocking)? This is why you get the main loop
> spun warning message.
>
> U
On Wed, Nov 26, 2014 at 03:46:42PM +0100, Kevin Wolf wrote:
> +while (data.n > 0) {
> +main_loop_wait(false);
> +}
Why is this false (non-blocking)? This is why you get the main loop
spun warning message.
Using true (blocking) seems like the right thing. data.n changes as
part o
On Fri, 28 Nov 2014 09:14:46 +
Peter Maydell wrote:
> On 27 November 2014 at 09:26, Markus Armbruster wrote:
> > David Gibson writes:
> >
> >> VirtIO devices now remember which endianness they're operating in in order
> >> to support targets which may have guests of either endianness, such a
Am 28.11.2014 um 12:32 schrieb Peter Lieven:
> Am 28.11.2014 um 12:23 schrieb Paolo Bonzini:
>> On 28/11/2014 12:21, Peter Lieven wrote:
>>> Am 28.11.2014 um 12:14 schrieb Paolo Bonzini:
> master:
> Run operation 4000 iterations 12.851414 s, 3112K operations/s, 321ns
> per coroutin
On Fri, Nov 28, 2014 at 09:14:46AM +, Peter Maydell wrote:
> On 27 November 2014 at 09:26, Markus Armbruster wrote:
> > David Gibson writes:
> >
> >> VirtIO devices now remember which endianness they're operating in in order
> >> to support targets which may have guests of either endianness,
On Fri, Nov 28, 2014 at 7:05 AM, Jason Wang wrote:
>
>
> On Fri, Nov 28, 2014 at 9:16 AM, Fam Zheng wrote:
>>
>> On Thu, 11/27 23:13, Michael S. Tsirkin wrote:
>>>
>>> On Thu, Nov 27, 2014 at 07:21:35PM +, Stefan Hajnoczi wrote:
>>> > On Thu, Nov 27, 2014 at 4:33 PM, Michael S. Tsirkin
>>>
On Wed, Nov 26, 2014 at 03:01:02PM +0100, Paolo Bonzini wrote:
> Use the external qemu-timer API instead.
>
> Cc: kw...@redhat.com
> Cc: stefa...@redhat.com
> Signed-off-by: Paolo Bonzini
> ---
> block/accounting.c | 6 --
> block/raw-posix.c | 8
> 2 files changed, 8 insertions(+)
On Tue, Nov 25, 2014 at 06:12:39PM +0100, Kevin Wolf wrote:
> v2:
> - Added two patches to make the test case actually work properly and not
> just by accident on my laptop. [Max]
> - Fixed comment in test case [Max]
>
> Kevin Wolf (3):
> qcow2: Fix header extension size check
> qcow2.py: Ad
Am 28.11.2014 um 12:23 schrieb Paolo Bonzini:
>
> On 28/11/2014 12:21, Peter Lieven wrote:
>> Am 28.11.2014 um 12:14 schrieb Paolo Bonzini:
master:
Run operation 4000 iterations 12.851414 s, 3112K operations/s, 321ns
per coroutine
paolo:
Run operation 4000 ite
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> On 26/11/2014 11:40, Pavel Dovgalyuk wrote:
> > This patch introduces new QEMU_CLOCK_VIRTUAL_RT clock, which
> > should be used for icount warping. Separate timer is needed
> > for replaying the execution, because warping callbacks should
> > be
Am 28.11.2014 um 12:23 schrieb Paolo Bonzini:
>
> On 28/11/2014 12:21, Peter Lieven wrote:
>> Am 28.11.2014 um 12:14 schrieb Paolo Bonzini:
master:
Run operation 4000 iterations 12.851414 s, 3112K operations/s, 321ns
per coroutine
paolo:
Run operation 4000 ite
On Thu, Nov 27, 2014 at 04:32:52PM +0100, Max Reitz wrote:
> On 2014-11-27 at 16:21, Stefan Hajnoczi wrote:
> >On Thu, Nov 20, 2014 at 06:06:23PM +0100, Max Reitz wrote:
> >>@@ -583,7 +608,12 @@ static int QEMU_WARN_UNUSED_RESULT
> >>update_refcount(BlockDriverState *bs,
> >> /* we can up
Am 28.11.2014 um 03:27 hat Ming Lei geschrieben:
> Hi Kevin,
>
> On Wed, Nov 26, 2014 at 7:27 PM, Kevin Wolf wrote:
> > Am 25.11.2014 um 08:23 hat Ming Lei geschrieben:
> >> Previously -EAGAIN is simply ignored for !s->io_q.plugged case,
> >> and sometimes it is easy to cause -EIO to VM, such as
On 28/11/2014 12:21, Peter Lieven wrote:
> Am 28.11.2014 um 12:14 schrieb Paolo Bonzini:
>>> master:
>>> Run operation 4000 iterations 12.851414 s, 3112K operations/s, 321ns
>>> per coroutine
>>>
>>> paolo:
>>> Run operation 4000 iterations 11.951720 s, 3346K operations/s, 298ns
>>> per
Am 28.11.2014 um 12:14 schrieb Paolo Bonzini:
>> master:
>> Run operation 4000 iterations 12.851414 s, 3112K operations/s, 321ns per
>> coroutine
>>
>> paolo:
>> Run operation 4000 iterations 11.951720 s, 3346K operations/s, 298ns per
>> coroutine
> Nice. :)
>
> Can you please try "corout
On Fri, Nov 28, 2014 at 11:49:48AM +0100, Laszlo Ersek wrote:
> On 11/28/14 11:43, Laszlo Ersek wrote:
> > On 11/28/14 11:38, Andrew Jones wrote:
> >> On Fri, Nov 28, 2014 at 12:18:27AM +0100, Laszlo Ersek wrote:
> >>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> >>> pp
On 11/28/2014 01:35 PM, Stefan Hajnoczi wrote:
On Wed, Nov 26, 2014 at 01:16:48PM +0300, Ekaterina Tumanova wrote:
On 11/25/2014 04:01 PM, Stefan Hajnoczi wrote:
On Wed, Nov 19, 2014 at 11:17:50AM +0100, Ekaterina Tumanova wrote:
3. Why does s390 need to customize hd_geometry_guess()?
Since h
> master:
> Run operation 4000 iterations 12.851414 s, 3112K operations/s, 321ns per
> coroutine
>
> paolo:
> Run operation 4000 iterations 11.951720 s, 3346K operations/s, 298ns per
> coroutine
Nice. :)
Can you please try "coroutine: Use __thread … " together, too? I still
see 11% t
On Thu, Nov 27, 2014 at 04:11:12PM +0100, Max Reitz wrote:
> On 2014-11-27 at 16:09, Stefan Hajnoczi wrote:
> >On Thu, Nov 20, 2014 at 06:06:22PM +0100, Max Reitz wrote:
> >>+/**
> >>+ * Reallocates *array so that it can hold new_size entries. *size must
> >>contain
> >>+ * the current number of e
On Thu, Nov 20, 2014 at 06:06:23PM +0100, Max Reitz wrote:
> @@ -1711,7 +1746,7 @@ static int calculate_refcounts(BlockDriverState *bs,
> BdrvCheckResult *res,
> static void compare_refcounts(BlockDriverState *bs, BdrvCheckResult *res,
>BdrvCheckMode fix, bool *reb
Suggest function comment
/**
* Return logical block size, or zero if we can't figure it out
*/
{
-BDRVRawState *s = bs->opaque;
-char *buf;
-unsigned int sector_size;
-
-/* For /dev/sg devices the alignment is not really used.
- With buffered I/O, we
Ekaterina Tumanova writes:
> On 11/25/2014 04:01 PM, Stefan Hajnoczi wrote:
[...]
>> 3. Why does s390 need to customize hd_geometry_guess()?
>>
> Since hd_geometry_guess contains semantics of x86-specific LBA
> translation, we have to modify it not to get in the way of z
> architecture
I already
On 11/28/2014 01:10 PM, Markus Armbruster wrote:
Ekaterina Tumanova writes:
hd_geometry_guess function autodetects the drive geometry. This patch
adds a block backend call, that probes the backing device geometry.
If the inner driver method is implemented and succeeds (currently only DASDs),
t
On Fri, Nov 28, 2014 at 11:43:32AM +0100, Laszlo Ersek wrote:
> On 11/28/14 11:38, Andrew Jones wrote:
> > On Fri, Nov 28, 2014 at 12:18:27AM +0100, Laszlo Ersek wrote:
> >> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> >> ppc/mac_oldworld.c, sparc/sun4m.c); we can easil
On 11/28/14 11:43, Laszlo Ersek wrote:
> On 11/28/14 11:38, Andrew Jones wrote:
>> On Fri, Nov 28, 2014 at 12:18:27AM +0100, Laszlo Ersek wrote:
>>> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
>>> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
>>>
Ekaterina Tumanova writes:
> Signed-off-by: Ekaterina Tumanova
> ---
> hw/block/hd-geometry.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/hw/block/hd-geometry.c b/hw/block/hd-geometry.c
> index b462225..905d2c6 100644
> --- a/hw/block/hd-geometry.c
> +++ b/hw/
Ekaterina Tumanova writes:
> For target-s390x, the behaviour is chosen as follows:
> If no geo could be guessed from backing device, guess_disk_lchs (partition
> table guessing) is called.
> If this is not successful (e.g. image files) geometry is derived from the
> size of the disk (as before).
1 - 100 of 125 matches
Mail list logo
