Re: [PATCH] content: Replace guest OS with driver

[Cornelia Huck <cohuck@redhat.com>]

On Tue, May 16 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Tue, May 16, 2023 at 10:24:12AM +0200, Cornelia Huck wrote:
>> On Tue, May 16 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> 
>> > On Tue, May 16, 2023 at 06:01:39AM +0300, Parav Pandit wrote:
>> >> diff --git a/content.tex b/content.tex
>> >> index 9df81b8..417d476 100644
>> >> --- a/content.tex
>> >> +++ b/content.tex
>> >> @@ -26,10 +26,10 @@ \section{\field{Device Status} Field}\label{sec:Basic Facilities of a Virtio Dev
>> >>  following bits are defined (listed below in the order in which
>> >>  they would be typically set):
>> >>  \begin{description}
>> >> -\item[ACKNOWLEDGE (1)] Indicates that the guest OS has found the
>> >> +\item[ACKNOWLEDGE (1)] Indicates that the driver has found the
>> >>    device and recognized it as a valid virtio device.
>> >>  
>> >> -\item[DRIVER (2)] Indicates that the guest OS knows how to drive the
>> >> +\item[DRIVER (2)] Indicates that the driver knows how to drive the
>> >>    device.
>> >>    \begin{note}
>> >>      There could be a significant (or infinite) delay before setting
>> >
>> > Actually, there is a subtle difference here that this is losing.
>> > "guest OS" really refers to e.g. Linux virtio core code here.
>> >
>> >
>> > ACKNOWLEDGE and DRIVER are used by virtio core.
>> >
>> > ACKNOWLEDGE tells you virtio core attached to device, and DRIVER
>> > tells you core found a device specific driver.
>> >
>> >
>> >
>> > If you really want to make things better, let's find a way to explain
>> > all this.
>> 
>> Agreed, this is a really old part of the spec, and likely had been
>> written with the Linux device probing sequence in mind.
>> 
>> Basically, we want to distinguish between "something on the driver side
>> has discovered the device" and "something on the driver side knows how
>> to drive this specific device". If we consider "driver" as a catch-all
>> of the whole thing talking to a device, we need to be extra descriptive
>> (and we can add examples, as this is a non-normative section.)
>> 
>> For ACKNOWLEDGE, maybe "indicates that the driver has discovered the
>> device and recognized it as a valid virtio device" (i.e. mostly what we
>> have now), but also add "For example, this can indicate that non-device
>> specific virtio driver code has attached to the device."
>> 
>> For DRIVER, maybe "indicates that the driver has discovered that it
>> knows how to drive this device specifically. For example, this can
>> indicate that device-specific driver code has attached to the device."
>
>
> I feel examples are a weak way to document it - if we can not say
> what this is specifically, what purpose does it serve?

Not really documenting, but rather illustrating it.

> Actually, we do have a distinction, between transport and device type.
> Can't we use that? It seems more consistent than "non-device
> specific" and "device specific".

What do we consider to be the "transport"? {pci,mmio,ccw} + virtio ring,
or only {pci,mmio,ccw}? This might be confusiong, since at least in the
Linux case, it is the virtio ring/generic code that sets ACKNOWLEDGE,
while the pci/mmio/ccw code is not fiddling with the status at that
stage.

> SO I propose:
>
> \item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
>     device and recognized it as a valid virtio device transport.

What is a "virtio device transport"?

>   
> \item[DRIVER (2)] Indicates that a device type specific driver was found
>     and will attempt to attach to the device.
>
>
>
> BTW somewhat related, I would maybe fix
> device-types/mem/description.tex:change
> not to say "device driver", just "driver" for brevity.

That one makes sense to me.