On Thu, Jul 28, 2022 at 01:20:26AM -0700, Si-Wei Liu wrote: > Hi Michael, > > Could you please comment on the different wording between "exist" and "valid" > in spec? Having seen quite a few relevant discussions regarding MTU validation > and VERSION_1 negotiation on s390, I was in the impression this is not the > first time people getting confused because of ambiguity of random wording > without detailed example helping to clarify around the context, or due lack of > clear definition set ahead. I like your idea to keep things consistent > (conditional depending on feature presence), however, without proper > interpretation of how spec is supposed to work, we are on a slippery slope > towards inconsistency. > > On 7/28/2022 12:36 AM, Jason Wang wrote: > > And looking at: > > "The mac address field always exists (though is only valid if > VIRTIO_NET_F_MAC is set), and status only exists if VIRTIO_NET_F_STATUS > is set." > > It appears to me there's a border line set between "exist" and "valid". > If I understand the spec wording correctly, a spec-conforming device > implementation may or may not offer valid status value in the config > space when VIRTIO_NET_F_STATUS is offered, but before the feature is > negotiated. > > That's not what I read, maybe Michael can clarify this. > > > > And Jason and I find below normatives are conflict with each other. > > "The device MUST allow reading of any device-specific configuration > field before FEATURES_OK is set by the driver. This includes fields > which are conditional on feature bits, as long as those feature bits are > offered by the device." So I proposed this back in April: https://lists.oasis-open.org/archives/virtio-comment/202201/msg00068.html I intended this for 1.2 but it quickly became clear it won't make it in time. Working on reviving the proposal and addressing the comments. > > ... > > And also there are special cases where the read of specific > configuration space field MUST be deferred to until FEATURES_OK is set: > > "If the VIRTIO_BLK_F_CONFIG_WCE feature is negotiated, the cache mode > can be read or set through the writeback field. 0 corresponds to a > writethrough cache, 1 to a writeback cache11. The cache mode after reset > can be either writeback or writethrough. The actual mode can be > determined by reading writeback after feature negotiation." > "The driver MUST NOT read writeback before setting the FEATURES_OK > device status bit." > > This seems to conflict with the normatives I quoted above, and I don't > get why we need this. > > > > Thanks, > -Siwei The last one I take to mean writeback is special. I am not sure why it should be. Paolo you proposed this text could you comment please? Thanks! -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
