On Tue, 22 Mar 2016 13:11:05 +0100
Paolo Bonzini wrote:
> On 22/03/2016 12:59, Cornelia Huck wrote:
> >> > They can be fixed with just an extra object_ref/object_unref.
> >> >
> >> > I didn't understand that Tu Bo also needed the BH fix, and with that
> >> > information it makes sense. Passing
On 22/03/2016 12:59, Cornelia Huck wrote:
>> > They can be fixed with just an extra object_ref/object_unref.
>> >
>> > I didn't understand that Tu Bo also needed the BH fix, and with that
>> > information it makes sense. Passing the assign value ensures that
>> > ioeventfd remains always assign
On Tue, 22 Mar 2016 10:46:58 +0100
Paolo Bonzini wrote:
> On 22/03/2016 10:07, Cornelia Huck wrote:
> > So far, we had the best results with my refactoring + the mutex/bh
> > change. Two problems:
> >
> > - We don't really understand yet why my refactoring helps, but passing
> > the assign value
On 22/03/2016 10:07, Cornelia Huck wrote:
> So far, we had the best results with my refactoring + the mutex/bh
> change. Two problems:
>
> - We don't really understand yet why my refactoring helps, but passing
> the assign value is a good canditate (and it's agreed that this fixes a
> bug, I thi
(re-adding cc:s)
On Tue, 22 Mar 2016 15:18:05 +0800
Fam Zheng wrote:
> On Tue, 03/22 15:10, tu bo wrote:
> > Hi Fam:
> >
> > On 03/21/2016 06:57 PM, Fam Zheng wrote:
> > >On Thu, 03/17 19:03, tu bo wrote:
> > >>
> > >>On 03/17/2016 08:39 AM, Fam Zheng wrote:
> > >>>On Wed, 03/16 14:45, Paolo Bo
On Tue, 22 Mar 2016 07:45:19 +0800
Fam Zheng wrote:
> On Mon, 03/21 14:02, Cornelia Huck wrote:
> > On Mon, 21 Mar 2016 20:45:27 +0800
> > Fam Zheng wrote:
> >
> > > On Mon, 03/21 12:15, Cornelia Huck wrote:
> > > > On Mon, 21 Mar 2016 18:57:18 +0800
> > > > Fam Zheng wrote:
> > > >
> > > > >
On Tue, 03/22 15:10, tu bo wrote:
> Hi Fam:
>
> On 03/21/2016 06:57 PM, Fam Zheng wrote:
> >On Thu, 03/17 19:03, tu bo wrote:
> >>
> >>On 03/17/2016 08:39 AM, Fam Zheng wrote:
> >>>On Wed, 03/16 14:45, Paolo Bonzini wrote:
>
>
> On 16/03/2016 14:38, Christian Borntraeger wrote:
> >>>
Hi Fam:
On 03/21/2016 06:57 PM, Fam Zheng wrote:
On Thu, 03/17 19:03, tu bo wrote:
On 03/17/2016 08:39 AM, Fam Zheng wrote:
On Wed, 03/16 14:45, Paolo Bonzini wrote:
On 16/03/2016 14:38, Christian Borntraeger wrote:
If you just remove the calls to virtio_queue_host_notifier_read, here
and
On Mon, 03/21 15:19, Cornelia Huck wrote:
> On Mon, 21 Mar 2016 14:54:04 +0100
> Paolo Bonzini wrote:
>
> > On 21/03/2016 14:47, TU BO wrote:
> > >> I'll see if I can produce something based on Conny's patches, which are
> > >> already a start. Today I had a short day so I couldn't play with the
On Mon, 03/21 14:02, Cornelia Huck wrote:
> On Mon, 21 Mar 2016 20:45:27 +0800
> Fam Zheng wrote:
>
> > On Mon, 03/21 12:15, Cornelia Huck wrote:
> > > On Mon, 21 Mar 2016 18:57:18 +0800
> > > Fam Zheng wrote:
> > >
> > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > index 0827
On Mon, 21 Mar 2016 14:54:04 +0100
Paolo Bonzini wrote:
> On 21/03/2016 14:47, TU BO wrote:
> >> I'll see if I can produce something based on Conny's patches, which are
> >> already a start. Today I had a short day so I couldn't play with the
> >> bug; out of curiosity, does the bug reproduce wi
On 21/03/2016 14:47, TU BO wrote:
>> I'll see if I can produce something based on Conny's patches, which are
>> already a start. Today I had a short day so I couldn't play with the
>> bug; out of curiosity, does the bug reproduce with her work + patch 4
>> from this series + the reentrancy asser
On 16/3/18 下午11:03, Paolo Bonzini wrote:
On 17/03/2016 17:08, Christian Borntraeger wrote:
Good (or bad?) news is the assert also triggers on F23, it just seems
to take longer.
I guess good news, because we can rule out the kernel (not that I
believed it was a kernel problem, but the thought i
On Mon, 21 Mar 2016 20:45:27 +0800
Fam Zheng wrote:
> On Mon, 03/21 12:15, Cornelia Huck wrote:
> > On Mon, 21 Mar 2016 18:57:18 +0800
> > Fam Zheng wrote:
> >
> > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > index 08275a9..47f8043 100644
> > > --- a/hw/virtio/virtio.c
> > > +++
On Mon, 03/21 12:15, Cornelia Huck wrote:
> On Mon, 21 Mar 2016 18:57:18 +0800
> Fam Zheng wrote:
>
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 08275a9..47f8043 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -1098,7 +1098,14 @@ void virtio_queue_not
On Mon, 21 Mar 2016 17:42:06 +0800
Fam Zheng wrote:
> On Fri, 03/18 16:03, Paolo Bonzini wrote:
> >
> >
> > On 17/03/2016 17:08, Christian Borntraeger wrote:
> > > Good (or bad?) news is the assert also triggers on F23, it just seems
> > > to take longer.
> >
> > I guess good news, because we can
On Mon, 21 Mar 2016 18:57:18 +0800
Fam Zheng wrote:
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 08275a9..47f8043 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -1098,7 +1098,14 @@ void virtio_queue_notify_vq(VirtQueue *vq)
>
> void virtio_queue_notify(VirtI
On 03/21/2016 10:42 AM, Fam Zheng wrote:
> On Fri, 03/18 16:03, Paolo Bonzini wrote:
>>
>>
>> On 17/03/2016 17:08, Christian Borntraeger wrote:
>>> Good (or bad?) news is the assert also triggers on F23, it just seems
>>> to take longer.
>>
>> I guess good news, because we can rule out the kernel (
On Thu, 03/17 19:03, tu bo wrote:
>
> On 03/17/2016 08:39 AM, Fam Zheng wrote:
> >On Wed, 03/16 14:45, Paolo Bonzini wrote:
> >>
> >>
> >>On 16/03/2016 14:38, Christian Borntraeger wrote:
> If you just remove the calls to virtio_queue_host_notifier_read, here
> and in virtio_queue_aio_set_
On Fri, 03/18 16:03, Paolo Bonzini wrote:
>
>
> On 17/03/2016 17:08, Christian Borntraeger wrote:
> > Good (or bad?) news is the assert also triggers on F23, it just seems
> > to take longer.
>
> I guess good news, because we can rule out the kernel (not that I
> believed it was a kernel problem, b
On 16/03/2016 12:32, Cornelia Huck wrote:
> On Wed, 16 Mar 2016 12:09:02 +0100
> Paolo Bonzini wrote:
>
>> On 16/03/2016 11:49, Christian Borntraeger wrote:
>
>>> #3 0x800b713e in virtio_blk_data_plane_start (s=0xba232d80) at
>>> /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-bl
On 16/03/2016 12:24, Christian Borntraeger wrote:
> On 03/16/2016 12:09 PM, Paolo Bonzini wrote:
>> On 16/03/2016 11:49, Christian Borntraeger wrote:
>>> #3 0x800b713e in virtio_blk_data_plane_start (s=0xba232d80) at
>>> /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:224
>>>
On 03/16/2016 12:09 PM, Paolo Bonzini wrote:
>
>
> On 16/03/2016 11:49, Christian Borntraeger wrote:
>> Seems to lockup.
>
> That's an improvement actually. :)
>
>> Thread 3 (Thread 0x3ff888dc910 (LWP 88958)):
>> #0 0x03ff8ca90cd4 in __lll_lock_wait () at /lib64/libpthread.so.0
>> #1 0x00
On 16/03/2016 14:38, Christian Borntraeger wrote:
> > If you just remove the calls to virtio_queue_host_notifier_read, here
> > and in virtio_queue_aio_set_host_notifier_fd_handler, does it work
> > (keeping patches 2-4 in)?
>
> With these changes and patch 2-4 it does no longer locks up.
> I k
Good (or bad?) news is the assert also triggers on F23, it just seems to take
longer.
trace 1 (compiled on F20)
Thread 5 (Thread 0x3ff84b7f910 (LWP 33030)):
#0 0x03ff86a817b8 in ppoll () at /lib64/libc.so.6
#1 0x102c712e in qemu_poll_ns (fds=0x3ff80001e70, nfds=3, timeout=-1)
at /
On 17/03/2016 13:39, Christian Borntraeger wrote:
> As an interesting side note, I updated my system from F20 to F23 some days ago
> (after the initial report). While To Bo is still on a F20 system. I was not
> able
> to reproduce the original crash on f23. but going back to F20 made this
> prob
On 03/16/2016 01:55 PM, Paolo Bonzini wrote:
>
>
> On 16/03/2016 12:24, Christian Borntraeger wrote:
>> On 03/16/2016 12:09 PM, Paolo Bonzini wrote:
>>> On 16/03/2016 11:49, Christian Borntraeger wrote:
#3 0x800b713e in virtio_blk_data_plane_start (s=0xba232d80) at
/home/cborn
On Wed, 16 Mar 2016 12:32:13 +0100
Cornelia Huck wrote:
> On Wed, 16 Mar 2016 12:09:02 +0100
> Paolo Bonzini wrote:
>
> > On 16/03/2016 11:49, Christian Borntraeger wrote:
>
> > > #3 0x800b713e in virtio_blk_data_plane_start (s=0xba232d80) at
> > > /home/cborntra/REPOS/qemu/hw/block/
On Thu, 17 Mar 2016 13:39:18 +0100
Christian Borntraeger wrote:
> On 03/17/2016 01:22 PM, tu bo wrote:
> >
> > On 03/16/2016 09:38 PM, Christian Borntraeger wrote:
> >> On 03/16/2016 01:55 PM, Paolo Bonzini wrote:
> >>>
> >>>
> >>> On 16/03/2016 12:24, Christian Borntraeger wrote:
> On 03/1
On 03/17/2016 04:15 PM, Christian Borntraeger wrote:
> On 03/17/2016 04:02 PM, Paolo Bonzini wrote:
>>
>>
>> On 17/03/2016 13:39, Christian Borntraeger wrote:
>>> As an interesting side note, I updated my system from F20 to F23 some days
>>> ago
>>> (after the initial report). While To Bo is still
On Wed, 16 Mar 2016 13:49:10 +0100
Paolo Bonzini wrote:
> On 16/03/2016 13:42, Cornelia Huck wrote:
> > On Wed, 16 Mar 2016 13:32:59 +0100
> > Paolo Bonzini wrote:
> >
> >> On 16/03/2016 13:22, Cornelia Huck wrote:
> > Yeah, it doesn't help that the functions are underdocumented (as in the
On Wed, 16 Mar 2016 12:48:22 +0100
Paolo Bonzini wrote:
>
>
> On 16/03/2016 12:32, Cornelia Huck wrote:
> > On Wed, 16 Mar 2016 12:09:02 +0100
> > Paolo Bonzini wrote:
> >
> >> On 16/03/2016 11:49, Christian Borntraeger wrote:
> >
> >>> #3 0x800b713e in virtio_blk_data_plane_start (
On 16/03/2016 11:49, Christian Borntraeger wrote:
> Seems to lockup.
That's an improvement actually. :)
> Thread 3 (Thread 0x3ff888dc910 (LWP 88958)):
> #0 0x03ff8ca90cd4 in __lll_lock_wait () at /lib64/libpthread.so.0
> #1 0x03ff8ca93e74 in __lll_lock_elision () at /lib64/libpthread.
On 16/03/2016 14:04, Cornelia Huck wrote:
> > No, it would not. ioeventfd=off,vhost=on would mean: "when vhost is
> > off, use vCPU thread notification".
>
> *confused*
>
> Is ioeventfd=off supposed to mean "don't talk to the kernel, do
> everything in qemu"?
For KVM, it means do everything i
On 03/17/2016 08:39 AM, Fam Zheng wrote:
On Wed, 03/16 14:45, Paolo Bonzini wrote:
On 16/03/2016 14:38, Christian Borntraeger wrote:
If you just remove the calls to virtio_queue_host_notifier_read, here
and in virtio_queue_aio_set_host_notifier_fd_handler, does it work
(keeping patches 2-4 i
On Wed, 03/16 14:45, Paolo Bonzini wrote:
>
>
> On 16/03/2016 14:38, Christian Borntraeger wrote:
> > > If you just remove the calls to virtio_queue_host_notifier_read, here
> > > and in virtio_queue_aio_set_host_notifier_fd_handler, does it work
> > > (keeping patches 2-4 in)?
> >
> > With thes
On 03/17/2016 04:02 PM, Paolo Bonzini wrote:
>
>
> On 17/03/2016 13:39, Christian Borntraeger wrote:
>> As an interesting side note, I updated my system from F20 to F23 some days
>> ago
>> (after the initial report). While To Bo is still on a F20 system. I was not
>> able
>> to reproduce the or
On 03/17/2016 01:22 PM, tu bo wrote:
>
> On 03/16/2016 09:38 PM, Christian Borntraeger wrote:
>> On 03/16/2016 01:55 PM, Paolo Bonzini wrote:
>>>
>>>
>>> On 16/03/2016 12:24, Christian Borntraeger wrote:
On 03/16/2016 12:09 PM, Paolo Bonzini wrote:
> On 16/03/2016 11:49, Christian Borntra
On 03/17/2016 04:02 PM, Paolo Bonzini wrote:
>
>
> On 17/03/2016 13:39, Christian Borntraeger wrote:
>> As an interesting side note, I updated my system from F20 to F23 some days
>> ago
>> (after the initial report). While To Bo is still on a F20 system. I was not
>> able
>> to reproduce the or
On 16/03/2016 12:52, Cornelia Huck wrote:
> > Hm... I copied these semantics from virtio-pci, and they still seem to
> > be the same. I wonder why we never saw this on virtio-pci?
> >
> > > In dataplane, instead, all calls to
> > > virtio_queue_set_host_notifier_fd_handler and
> > > virtio_queue
On 16/03/2016 14:14, Cornelia Huck wrote:
> > And full of duplicate code. If copied code were moved to the virtio bus
> > level, it would be easier to change too.
>
> Yes, pci, ccw and mmio basically all do the same things. The only
> difference is actually wiring up the eventfd.
>
> I can att
On 16/03/2016 13:22, Cornelia Huck wrote:
>> > Yeah, it doesn't help that the functions are underdocumented (as in the
>> > "assign" parameter above).
> My understanding is:
>
> - 'assign': set up a new notifier (true) or disable it (false)
> - 'set_handler': use our handler (true) or have it ha
On Wed, 16 Mar 2016 12:59:37 +0100
Paolo Bonzini wrote:
> On 16/03/2016 12:56, Cornelia Huck wrote:
> > On Wed, 16 Mar 2016 12:48:22 +0100
> > Paolo Bonzini wrote:
> >
> >>
> >>
> >> On 16/03/2016 12:32, Cornelia Huck wrote:
> >>> On Wed, 16 Mar 2016 12:09:02 +0100
> >>> Paolo Bonzini wrote:
>
On Wed, 16 Mar 2016 14:10:29 +0100
Paolo Bonzini wrote:
> On 16/03/2016 14:04, Cornelia Huck wrote:
> > > No, it would not. ioeventfd=off,vhost=on would mean: "when vhost is
> > > off, use vCPU thread notification".
> >
> > *confused*
> >
> > Is ioeventfd=off supposed to mean "don't talk to th
On Wed, 16 Mar 2016 12:09:02 +0100
Paolo Bonzini wrote:
> On 16/03/2016 11:49, Christian Borntraeger wrote:
> > #3 0x800b713e in virtio_blk_data_plane_start (s=0xba232d80) at
> > /home/cborntra/REPOS/qemu/hw/block/dataplane/virtio-blk.c:224
> > #4 0x800b4ea0 in virtio_blk_hand
On Wed, 16 Mar 2016 13:32:59 +0100
Paolo Bonzini wrote:
> On 16/03/2016 13:22, Cornelia Huck wrote:
> >> > Yeah, it doesn't help that the functions are underdocumented (as in the
> >> > "assign" parameter above).
> > My understanding is:
> >
> > - 'assign': set up a new notifier (true) or disabl
On 17/03/2016 17:08, Christian Borntraeger wrote:
> Good (or bad?) news is the assert also triggers on F23, it just seems
> to take longer.
I guess good news, because we can rule out the kernel (not that I
believed it was a kernel problem, but the thought is always there in
the background...).
On 16/03/2016 13:42, Cornelia Huck wrote:
> On Wed, 16 Mar 2016 13:32:59 +0100
> Paolo Bonzini wrote:
>
>> On 16/03/2016 13:22, Cornelia Huck wrote:
> Yeah, it doesn't help that the functions are underdocumented (as in the
> "assign" parameter above).
>>> My understanding is:
>>>
>>> -
On 16/03/2016 12:56, Cornelia Huck wrote:
> On Wed, 16 Mar 2016 12:48:22 +0100
> Paolo Bonzini wrote:
>
>>
>>
>> On 16/03/2016 12:32, Cornelia Huck wrote:
>>> On Wed, 16 Mar 2016 12:09:02 +0100
>>> Paolo Bonzini wrote:
>>>
On 16/03/2016 11:49, Christian Borntraeger wrote:
>>>
> #3 0x
On 03/16/2016 09:38 PM, Christian Borntraeger wrote:
On 03/16/2016 01:55 PM, Paolo Bonzini wrote:
On 16/03/2016 12:24, Christian Borntraeger wrote:
On 03/16/2016 12:09 PM, Paolo Bonzini wrote:
On 16/03/2016 11:49, Christian Borntraeger wrote:
#3 0x800b713e in virtio_blk_data_plane
On 03/16/2016 11:28 AM, Paolo Bonzini wrote:
>
>
> On 16/03/2016 11:10, Fam Zheng wrote:
>> These are some ideas originated from analyzing the Christian's crash report
>> on
>> virtio-blk dataplane torture test:
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg02093.html
>>
>> The
On 16/03/2016 11:10, Fam Zheng wrote:
> These are some ideas originated from analyzing the Christian's crash report on
> virtio-blk dataplane torture test:
>
> https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg02093.html
>
> The ideas are mostly inspired/suggested by Paolo. This doesn't
These are some ideas originated from analyzing the Christian's crash report on
virtio-blk dataplane torture test:
https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg02093.html
The ideas are mostly inspired/suggested by Paolo. This doesn't fix the bug, but
the first and the last patches seem
53 matches
Mail list logo
