On Sun, Nov 20 2022, "Michael S. Tsirkin" <[email protected]> wrote:
> Adding relevant registers needs more work and it's not > clear what the use-case will be as currently only > the PCI transport is supported. But let's keep the > door open on this. > We already say it's reserved in a central place, but it > does not hurt to remind implementers to mask it. > > Signed-off-by: Michael S. Tsirkin <[email protected]> > --- > content.tex | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/content.tex b/content.tex > index 9c74fa9..7111929 100644 > --- a/content.tex > +++ b/content.tex > @@ -2971,6 +2971,18 @@ \subsubsection{Resetting Devices}\label{sec:Virtio > Transport Options / Virtio ov > MAY also choose to verify reset completion by reading \field{device status} > via > CCW_CMD_READ_STATUS and checking whether it is 0 afterwards. > > +\subsection{Features reserved for future use}\label{sec:Virtio Transport > Options / Virtio Over MMIO / Features reserved for future use} s/MMIO/Channel I/O/ > + > +At this time, devices and drivers utilizing Virtio over channel I/O > +do not support the following features: > +\begin{itemize} > + > +\item VIRTIO_F_ADMIN_VQ There are already a few features not yet supported for ccw (queue reset, shared memory, ...) -- would it make sense to add a separate patch listing all of the features not yet supported prior to adding all of the admin vq infrastructure? Otherwise, this section is a bit misleading. (What is the situation for MMIO?) > + > +\end{itemize} > + > +These features are reserved for future use. > + > \chapter{Device Types}\label{sec:Device Types} > > On top of the queues, config space and feature negotiation facilities --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
