From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH-RFC 13/13] virtio-net: connect to vhost net backend
Date: Wed, 24 Feb 2010 14:40:16 +0200 [thread overview]
Message-ID: <20100224124016.GA1195@redhat.com> (raw)
In-Reply-To: <201002241226.53893.paul@codesourcery.com>
On Wed, Feb 24, 2010 at 12:26:53PM +0000, Paul Brook wrote:
> > > If we do have a software
> > > fallback then the feature bit is just for backwards compatibility, and
> > > should be enabled unconditionally (on current machine types).
> >
> > Software fallback might turn out to be slower than disabling the feature
> > in the guest. For example, and extra pass over packet might cause extra CPU
> > cache thrashing. In that case, it's not obvious whether enabling it
> > unconditionally will turn out to be a good idea. But we'll have to have
> > that code to be able to tell.
>
> IMO once you accept that these things can change, consistency is more
> important than trying to guess what the "best" option may be.
Yes, SW fallback might be nice to have. What's important is likely to
depend on specific user.
> Starting qemu on machine A and migrating to machine B should give the same
> guest environment as starting on machine B.
>
> Paul
So currently, the way we try to ensure this is by checking feature bits
against the list supported by backend, and failing migration if there's
a discrepancy.
--
MST
next prev parent reply other threads:[~2010-02-24 12:43 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1263230079.git.mst@redhat.com>
2010-01-11 17:16 ` [Qemu-devel] [PATCH-RFC 01/13] virtio: export virtqueue structure Michael S. Tsirkin
2010-01-12 22:32 ` [Qemu-devel] " Anthony Liguori
2010-01-25 19:10 ` Michael S. Tsirkin
2010-01-25 19:23 ` Anthony Liguori
2010-01-11 17:17 ` [Qemu-devel] [PATCH-RFC 02/13] kvm: add API to set ioeventfd Michael S. Tsirkin
2010-01-12 22:35 ` [Qemu-devel] " Anthony Liguori
2010-01-25 19:20 ` Michael S. Tsirkin
2010-01-25 19:28 ` Anthony Liguori
2010-01-25 19:28 ` Michael S. Tsirkin
2010-01-25 19:44 ` Anthony Liguori
2010-01-11 17:17 ` [Qemu-devel] [PATCH-RFC 03/13] virtio: add iofd/irqfd support Michael S. Tsirkin
2010-01-12 22:36 ` [Qemu-devel] " Anthony Liguori
2010-01-13 10:50 ` Michael S. Tsirkin
2010-01-11 17:17 ` [Qemu-devel] [PATCH-RFC 04/13] virtio-pci: fill in irqfd/queufd support Michael S. Tsirkin
2010-01-11 17:19 ` [Qemu-devel] [PATCH-RFC 05/13] syborg_virtio: add irqfd/eventfd support Michael S. Tsirkin
2010-01-11 17:20 ` [Qemu-devel] [PATCH-RFC 06/13] s390-virtio: fill in irqfd support Michael S. Tsirkin
2010-01-11 17:20 ` [Qemu-devel] [PATCH-RFC 07/13] virtio: move typedef to qemu-common Michael S. Tsirkin
2010-01-11 17:20 ` [Qemu-devel] [PATCH-RFC 08/13] net/tap: add interface to get device fd Michael S. Tsirkin
2010-01-11 17:22 ` [Qemu-devel] [PATCH-RFC 09/13] tap: add vhost/vhostfd options Michael S. Tsirkin
2010-01-12 22:39 ` [Qemu-devel] " Anthony Liguori
2010-01-13 10:59 ` Michael S. Tsirkin
2010-01-12 22:42 ` Anthony Liguori
2010-01-11 17:22 ` [Qemu-devel] [PATCH-RFC 10/13] tap: add API to retrieve vhost net header Michael S. Tsirkin
2010-01-11 17:23 ` [Qemu-devel] [PATCH-RFC 12/13] virtio: add status change callback Michael S. Tsirkin
2010-01-11 17:23 ` [Qemu-devel] [PATCH-RFC 13/13] virtio-net: connect to vhost net backend Michael S. Tsirkin
2010-01-25 19:58 ` [Qemu-devel] " Anthony Liguori
2010-01-25 20:27 ` Michael S. Tsirkin
2010-01-25 21:00 ` Anthony Liguori
2010-01-25 21:01 ` Michael S. Tsirkin
2010-01-25 21:05 ` Michael S. Tsirkin
2010-01-25 21:11 ` Anthony Liguori
2010-02-24 3:14 ` Paul Brook
2010-02-24 5:29 ` Michael S. Tsirkin
2010-02-24 11:30 ` Paul Brook
2010-02-24 11:46 ` Michael S. Tsirkin
2010-02-24 12:26 ` Paul Brook
2010-02-24 12:40 ` Michael S. Tsirkin [this message]
2010-02-24 15:16 ` Anthony Liguori
2010-02-24 14:51 ` Anthony Liguori
2010-01-11 17:23 ` [Qemu-devel] [PATCH-RFC 11/13] vhost net support Michael S. Tsirkin
2010-01-12 22:45 ` [Qemu-devel] " Anthony Liguori
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=20100224124016.GA1195@redhat.com \
--to=mst@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.