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. Best regards, Tiwei Bie --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
