From: Cornelia Huck <cohuck@redhat.com>
To: Tiwei Bie <tiwei.bie@intel.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
stefanha@redhat.com, pbonzini@redhat.com,
virtio-dev@lists.oasis-open.org, dan.daly@intel.com,
cunming.liang@intel.com, zhihong.wang@intel.com
Subject: Re: [virtio-dev] [PATCH v3] content: enhance device requirements for feature bits
Date: Wed, 20 Jun 2018 09:54:33 +0200 [thread overview]
Message-ID: <20180620095433.7bbeceb0.cohuck@redhat.com> (raw)
In-Reply-To: <20180619163059.GA12527@debian>
On Wed, 20 Jun 2018 00:30:59 +0800
Tiwei Bie <tiwei.bie@intel.com> wrote:
> On Tue, Jun 19, 2018 at 12:46:45PM +0200, Halil Pasic wrote:
> > On 06/19/2018 11:14 AM, Tiwei Bie wrote:
> > > On Mon, Jun 18, 2018 at 07:28:33PM +0300, Michael S. Tsirkin wrote:
> [...]
> > >
> > > If it would be better to drop this patch,
> > > I'm fine with dropping it. Thanks!
> > >
> >
> > @Tiwei Bie
> > Thanks for your flexibility! What is your opinion (after considering the
> > arguments from my previous mail), is it better to include this patch in the spec or
> > is it better to drop it? Were you able to identify mistakes in my reasoning
> > (I mean points (1)-(12))?
> >
>
> Hi Halil,
>
> I think maybe you thought too much about this proposal
> (or maybe I really missed something obvious). In my
> opinion, the device requirement proposed by this patch
> is quite simple and straightforward:
>
> - It's just to make the spec explicitly require that
> a certain virtio device shouldn't fail re-negotiation
> of a feature set it has successfully accepted once.
>
> - It covers the cases of virtio device reset and system
> reset (which includes normal shutdown and start).
>
> I think the requirement is reasonable because for a
> certain virtio device, there is no reason that the
> feature bits it offers will change (because it should
> always offer all the features it understands). And we
> are just to add a device normative to make the spec be
> more explicit about that (because if a device really
> changes the features it offers after a device or
> system reset, something will go wrong). If the configs
> of an emulated virtio device are changed, maybe we
> shouldn't treat it as the same device any more, and
> IMO this case is not related to this proposal.
>
> Although we have 'Each virtio device offers all the
> features it understands', it's not an explicit device
> requirement. So I don't think it's a bad idea to
> have an explicit device requirement about this.
I think this reasoning is sane and we really should not overthink it.
The update as has been voted on looks fine to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2018-06-20 7:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 7:56 [virtio-dev] [PATCH v3] content: enhance device requirements for feature bits Tiwei Bie
2018-06-11 8:43 ` [virtio-dev] " Cornelia Huck
2018-06-11 13:24 ` Michael S. Tsirkin
2018-06-11 13:29 ` Cornelia Huck
2018-06-11 13:44 ` Michael S. Tsirkin
2018-06-11 13:44 ` Michael S. Tsirkin
2018-06-15 12:10 ` [virtio-dev] " Halil Pasic
2018-06-15 12:19 ` Michael S. Tsirkin
2018-06-15 12:42 ` Halil Pasic
2018-06-15 13:38 ` Michael S. Tsirkin
2018-06-15 15:16 ` Halil Pasic
2018-06-15 15:37 ` Michael S. Tsirkin
2018-06-18 15:08 ` Halil Pasic
2018-06-18 16:28 ` Michael S. Tsirkin
2018-06-19 9:14 ` Tiwei Bie
2018-06-19 10:46 ` Halil Pasic
2018-06-19 16:30 ` Tiwei Bie
2018-06-20 7:54 ` Cornelia Huck [this message]
2018-06-20 12:10 ` Halil Pasic
2018-06-20 1:06 ` Michael S. Tsirkin
2018-06-15 13:39 ` Tiwei Bie
2018-06-15 14:21 ` Halil Pasic
2018-06-15 15:36 ` Michael S. Tsirkin
2018-06-15 18:06 ` Halil Pasic
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=20180620095433.7bbeceb0.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=cunming.liang@intel.com \
--cc=dan.daly@intel.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=tiwei.bie@intel.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=zhihong.wang@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.