qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Jason Wang <jasowang@redhat.com>,
	qemu-stable <qemu-stable@nongnu.org>,
	QEMU-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [2.2 PATCH V2 for-4.5] virtio-net: fix unmap leak
Date: Mon, 1 Dec 2014 15:32:27 -0500	[thread overview]
Message-ID: <20141201203227.GA22021@laptop.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1411271740120.14135@kaball.uk.xensource.com>

On Thu, Nov 27, 2014 at 05:46:28PM +0000, Stefano Stabellini wrote:
> On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote:
> > On Nov 27, 2014 10:26 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > >
> > > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote: 
> > > > On Nov 27, 2014 9:58 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: 
> > > > > 
> > > > > On Thu, 27 Nov 2014, Konrad Rzeszutek Wilk wrote: 
> > > > > > On Nov 27, 2014 7:46 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote: 
> > > > > > > 
> > > > > > > Konrad, I think we should have this fix in 4.5: without it 
> > > > > > > vif=[ 'model=virtio-net' ] crashes QEMU. 
> > > > > > > 
> > > > > > 
> > > > > > Is it an regression? 
> > > > > 
> > > > > Good question: I was trying to investigate that. 
> > > > > 
> > > > > virtio-net is currently *not* documented in the xl interface: 
> > > > > 
> > > > > 
> > > > > ### model 
> > > > > 
> > > > > This keyword is valid for HVM guest devices with `type=ioemu` only. 
> > > > > 
> > > > > Specifies the type device to emulated for this guest. Valid values 
> > > > > are: 
> > > > > 
> > > > >   * `rtl8139` (default) -- Realtek RTL8139 
> > > > >   * `e1000` -- Intel E1000 
> > > > >   * in principle any device supported by your device model 
> > > > > 
> > > > > 
> > > > > The last working version of virtio-net on Xen is QEMU v1.4.0. That means 
> > > > > that the bug affects Xen 4.4 too (but it should work in Xen 4.3). 
> > > > 
> > > > Not a regression compared to 4.4 but it has been for two releases. 
> > >
> > > That is true. On the plus side, virtio-net has never been properly 
> > > documented as working in the first place. 
> > >
> > >
> > > > So if nobody noticed it for two releases will they notice it if it not fixed in this release either? And can it be fixed in the next one? 
> > >
> > > We can fix the crash even in this release by backporting this rather 
> > > simple patch. However the patch would just avoid the crash: virtio-net 
> > > would still be not working once the guest is booted. I haven't figured 
> > > out the cause of that problem yet. 
> > >
> > 
> > Perhaps then the hack^H^Hfix is to return an error if user is using virtio-net then?
> > 
> > And then in later releases make it work right.
> 
> Sorry, I take it back: the fix is enough to get virtio-net working, I
> had a configuration error that was confusing my test results.
> 
> Given that the fix is very simple, I think we should backport it to Xen 4.5
> and Xen 4.4.

OK.
>From 4.5 perspective: Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> 
> > > > > > > On Thu, 27 Nov 2014, Peter Maydell wrote: 
> > > > > > > > On 27 November 2014 at 12:33, Michael S. Tsirkin <mst@redhat.com> wrote: 
> > > > > > > > > On Thu, Nov 27, 2014 at 06:04:03PM +0800, 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 and using a temp variable 
> > > > > > > > >> in those functions. 
> > > > > > > > >> 
> > > > > > > > >> Cc: Wen Congyang <wency@cn.fujitsu.com> 
> > > > > > > > >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> 
> > > > > > > > >> Cc: qemu-stable@nongnu.org 
> > > > > > > > >> Signed-off-by: Jason Wang <jasowang@redhat.com> 
> > > > > > > > > 
> > > > > > > > > Reviewed-by: Michael S. Tsirkin <mst@redhat.com> 
> > > > > > > > > 
> > > > > > > > > Peter, can you pick this up or do you want a pull request? 
> > > > > > > > 
> > > > > > > > I can pick it up. I was waiting a bit to check that everybody 
> > > > > > > > was happy that this is the correct way to fix the bug and the 
> > > > > > > > patch is ok... 
> > > > > > 
> > > >

  reply	other threads:[~2014-12-01 22:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-27 15:31 [Qemu-devel] [2.2 PATCH V2 for-4.5] virtio-net: fix unmap leak Konrad Rzeszutek Wilk
2014-11-27 17:46 ` Stefano Stabellini
2014-12-01 20:32   ` Konrad Rzeszutek Wilk [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-11-27 15:05 Konrad Rzeszutek Wilk
2014-11-27 15:26 ` Stefano Stabellini
2014-11-27 14:53 Konrad Rzeszutek Wilk
2014-11-27 14:58 ` Stefano Stabellini
2014-11-27 10:04 [Qemu-devel] [2.2 PATCH V2] " Jason Wang
2014-11-27 12:33 ` Michael S. Tsirkin
2014-11-27 12:42   ` Peter Maydell
2014-11-27 12:46     ` [Qemu-devel] [2.2 PATCH V2 for-4.5] " Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141201203227.GA22021@laptop.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=jasowang@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).