virtio — archive

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Sun, 8 Feb 2015 11:21:18 +0100 "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Fri, Oct 31, 2014 at 03:26:18PM +0100, Cornelia Huck wrote: > > We don't want the VERSION_1 feature bit unless at least revision 1 > > has been negotiated. Make this a requirement. > > > > VIRTIO-119 > > > > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> > > Sorry about the delay in response. > I think I disagree with this one. > > I think this discusses how transitional devices work when > using the legacy interface? > In that case, this needs to go into a separate section, > explicitly labelled "legacy". Hmm... but a legacy device does not actually know about VERSION_1, does it? Or am I misunderstanding what you mean? > Looking into this deeper, how do devices "not accept" > bits when using a legacy interface? A legacy device can't accept the VERSION_1 bit, as it only has 32 feature bits. It will fail the ccw for the second half of the feature bits. > > Also, the wording here seems wrong to me. Could you elaborate? > > > @@ -2656,6 +2656,14 @@ For communicating its supported features to the device, the driver > > uses the CCW_CMD_WRITE_FEAT command, denoting a \field{features}/\field{index} > > combination. > > > > +\devicenormative{\paragraph}{Handling Device Features}{Virtio Transport Options / Virtio over channel I/O / Device Initialization / Handling Device Features} > > + > > +The device MUST NOT offer VIRTIO_F_VERSION_1 if not at least revision 1 has > > +been negociated. > > + > > +The device MUST NOT accept VIRTIO_F_VERSION_1 if not at least revision 1 has > > +been negociated. I think this all boils down to whether revision handling is enough to designate a device as non-legacy, no? > > + > > \subsubsection{Device Configuration}\label{sec:Virtio Transport Options / Virtio over channel I/O / Device Initialization / Device Configuration} > > > > The device's configuration space is located in host memory.