From: "Michael S. Tsirkin" <mst@redhat.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
dev@dpdk.org, qemu-devel@nongnu.org
Subject: Re: [PATCH 1/2] vhost: enable any layout feature
Date: Mon, 10 Oct 2016 02:20:22 +0300 [thread overview]
Message-ID: <20161010014900-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20160928022848.GE1597@yliu-dev.sh.intel.com>
On Wed, Sep 28, 2016 at 10:28:48AM +0800, Yuanhan Liu wrote:
> On Tue, Sep 27, 2016 at 10:56:40PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Sep 27, 2016 at 11:11:58AM +0800, Yuanhan Liu wrote:
> > > On Mon, Sep 26, 2016 at 10:24:55PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Sep 26, 2016 at 11:01:58AM -0700, Stephen Hemminger wrote:
> > > > > I assume that if using Version 1 that the bit will be ignored
> > >
> > > Yes, but I will just quote what you just said: what if the guest
> > > virtio device is a legacy device? I also gave my reasons in another
> > > email why I consistently set this flag:
> > >
> > > - we have to return all features we support to the guest.
> > >
> > > We don't know the guest is a modern or legacy device. That means
> > > we should claim we support both: VERSION_1 and ANY_LAYOUT.
> > >
> > > Assume guest is a legacy device and we just set VERSION_1 (the current
> > > case), ANY_LAYOUT will never be negotiated.
> > >
> > > - I'm following the way Linux kernel takes: it also set both features.
> > >
> > > Maybe, we could unset ANY_LAYOUT when VERSION_1 is _negotiated_?
> > >
> > > The unset after negotiation I proposed turned out it won't work: the
> > > feature is already negotiated; unsetting it only in vhost side doesn't
> > > change anything. Besides, it may break the migration as Michael stated
> > > below.
> >
> > I think the reverse. Teach vhost user that for future machine types
> > only VERSION_1 implies ANY_LAYOUT.
So I guess at this point, we can teach vhost-user in qemu
that version 1 implies any_layout but only for machine types
qemu 2.8 and up. It sets a bad precedent but oh well.
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
dev@dpdk.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] vhost: enable any layout feature
Date: Mon, 10 Oct 2016 02:20:22 +0300 [thread overview]
Message-ID: <20161010014900-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20160928022848.GE1597@yliu-dev.sh.intel.com>
On Wed, Sep 28, 2016 at 10:28:48AM +0800, Yuanhan Liu wrote:
> On Tue, Sep 27, 2016 at 10:56:40PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Sep 27, 2016 at 11:11:58AM +0800, Yuanhan Liu wrote:
> > > On Mon, Sep 26, 2016 at 10:24:55PM +0300, Michael S. Tsirkin wrote:
> > > > On Mon, Sep 26, 2016 at 11:01:58AM -0700, Stephen Hemminger wrote:
> > > > > I assume that if using Version 1 that the bit will be ignored
> > >
> > > Yes, but I will just quote what you just said: what if the guest
> > > virtio device is a legacy device? I also gave my reasons in another
> > > email why I consistently set this flag:
> > >
> > > - we have to return all features we support to the guest.
> > >
> > > We don't know the guest is a modern or legacy device. That means
> > > we should claim we support both: VERSION_1 and ANY_LAYOUT.
> > >
> > > Assume guest is a legacy device and we just set VERSION_1 (the current
> > > case), ANY_LAYOUT will never be negotiated.
> > >
> > > - I'm following the way Linux kernel takes: it also set both features.
> > >
> > > Maybe, we could unset ANY_LAYOUT when VERSION_1 is _negotiated_?
> > >
> > > The unset after negotiation I proposed turned out it won't work: the
> > > feature is already negotiated; unsetting it only in vhost side doesn't
> > > change anything. Besides, it may break the migration as Michael stated
> > > below.
> >
> > I think the reverse. Teach vhost user that for future machine types
> > only VERSION_1 implies ANY_LAYOUT.
So I guess at this point, we can teach vhost-user in qemu
that version 1 implies any_layout but only for machine types
qemu 2.8 and up. It sets a bad precedent but oh well.
--
MST
next prev parent reply other threads:[~2016-10-09 23:20 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 6:40 [PATCH 0/2] enables vhost/virtio any layout feature Yuanhan Liu
2016-09-26 6:40 ` [PATCH 1/2] vhost: enable " Yuanhan Liu
2016-09-26 18:01 ` Stephen Hemminger
2016-09-26 19:24 ` Michael S. Tsirkin
2016-09-26 19:24 ` [Qemu-devel] " Michael S. Tsirkin
2016-09-27 3:11 ` Yuanhan Liu
2016-09-27 3:11 ` [Qemu-devel] " Yuanhan Liu
2016-09-27 19:48 ` Stephen Hemminger
2016-09-27 19:48 ` [Qemu-devel] " Stephen Hemminger
2016-09-27 19:56 ` Michael S. Tsirkin
2016-09-27 19:56 ` [Qemu-devel] " Michael S. Tsirkin
2016-09-28 2:28 ` Yuanhan Liu
2016-09-28 2:28 ` [Qemu-devel] " Yuanhan Liu
2016-09-29 15:30 ` Maxime Coquelin
2016-09-29 17:57 ` Michael S. Tsirkin
2016-09-29 20:05 ` Maxime Coquelin
2016-09-29 20:21 ` Michael S. Tsirkin
2016-09-29 21:23 ` Maxime Coquelin
2016-09-30 12:05 ` Maxime Coquelin
2016-09-30 19:16 ` Michael S. Tsirkin
2016-10-10 4:05 ` Yuanhan Liu
2016-10-10 4:17 ` Michael S. Tsirkin
2016-10-10 4:22 ` Yuanhan Liu
2016-10-10 4:25 ` Michael S. Tsirkin
2016-10-10 12:40 ` Maxime Coquelin
2016-10-10 14:42 ` Yuanhan Liu
2016-10-10 14:54 ` Maxime Coquelin
2016-10-11 6:04 ` Yuanhan Liu
2016-10-11 6:39 ` Maxime Coquelin
2016-10-11 6:49 ` Yuanhan Liu
2016-10-03 14:20 ` Maxime Coquelin
2016-10-10 3:37 ` Yuanhan Liu
2016-10-10 3:46 ` Michael S. Tsirkin
2016-10-10 3:59 ` Yuanhan Liu
2016-10-10 4:16 ` Wang, Zhihong
2016-10-10 4:24 ` Michael S. Tsirkin
2016-10-10 4:39 ` Michael S. Tsirkin
2016-10-11 6:57 ` Yuanhan Liu
2016-10-12 3:21 ` Yuanhan Liu
2016-10-12 3:21 ` [Qemu-devel] [dpdk-dev] " Yuanhan Liu
[not found] ` <F5DF4F0E3AFEF648ADC1C3C33AD4DBF16C2409EB@SHSMSX101.ccr.corp.intel.com>
2016-10-13 2:52 ` [Qemu-devel] " Yang, Zhiyong
2016-10-13 2:52 ` [Qemu-devel] [dpdk-dev] " Yang, Zhiyong
2016-10-10 3:50 ` [Qemu-devel] " Yuanhan Liu
2016-10-09 23:20 ` Michael S. Tsirkin [this message]
2016-10-09 23:20 ` Michael S. Tsirkin
2016-10-10 3:03 ` Yuanhan Liu
2016-10-10 3:03 ` [Qemu-devel] " Yuanhan Liu
2016-10-10 3:04 ` Michael S. Tsirkin
2016-10-10 3:04 ` [Qemu-devel] " Michael S. Tsirkin
2016-10-10 3:10 ` Yuanhan Liu
2016-10-10 3:10 ` [Qemu-devel] " Yuanhan Liu
2016-09-26 6:40 ` [PATCH 2/2] net/virtio: " Yuanhan Liu
2016-09-26 18:04 ` Stephen Hemminger
2016-09-29 18:00 ` Michael S. Tsirkin
2016-09-29 18:01 ` Michael S. Tsirkin
2016-11-10 15:18 ` [PATCH 0/2] enables vhost/virtio " Michael S. Tsirkin
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=20161010014900-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stephen@networkplumber.org \
--cc=yuanhan.liu@linux.intel.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 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.