[virtio-dev] [PATCH] content: Replace guest OS with driver

[virtio-dev] [PATCH] content: Replace guest OS with driver

[Parav Pandit]

Currently device status field description and driver requirements
section uses mix of terminology for the driver. These two sections
sometimes call the driver as 'the guest OS' or 'the driver'.

Most of the cleanup around 'guest Os' was already done around commit
212c0cf3 in past. Clean up the remaining few references to just
refer it as 'driver'.

This is an editorial change.

Signed-off-by: Parav Pandit <parav@nvidia.com>
---
 content.tex | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

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
@@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper
 \begin{enumerate}
 \item Reset the device.
 
-\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device.
+\item Set the ACKNOWLEDGE status bit: the driver has noticed the device.
 
-\item Set the DRIVER status bit: the guest OS knows how to drive the device.
+\item Set the DRIVER status bit: the driver knows how to drive the device.
 
 \item\label{itm:General Initialization And Device Operation /
 Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits
-   understood by the OS and driver to the device.  During this step the
+   understood by the driver to the device.  During this step the
    driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it.
 
 \item\label{itm:General Initialization And Device Operation / Device Initialization / Set FEATURES-OK} Set the FEATURES_OK status bit.  The driver MUST NOT accept
-- 
2.26.2


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [virtio-comment] [PATCH] content: Replace guest OS with driver

[Jason Wang]

On Tue, May 16, 2023 at 11:02 AM Parav Pandit <parav@nvidia.com> wrote:
>
> Currently device status field description and driver requirements
> section uses mix of terminology for the driver. These two sections
> sometimes call the driver as 'the guest OS' or 'the driver'.
>
> Most of the cleanup around 'guest Os' was already done around commit
> 212c0cf3 in past. Clean up the remaining few references to just
> refer it as 'driver'.
>
> This is an editorial change.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>

Do we plan to replace the "hypervisor" with "device" as well?

Thanks

> ---
>  content.tex | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> 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
> @@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper
>  \begin{enumerate}
>  \item Reset the device.
>
> -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device.
> +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device.
>
> -\item Set the DRIVER status bit: the guest OS knows how to drive the device.
> +\item Set the DRIVER status bit: the driver knows how to drive the device.
>
>  \item\label{itm:General Initialization And Device Operation /
>  Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits
> -   understood by the OS and driver to the device.  During this step the
> +   understood by the driver to the device.  During this step the
>     driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it.
>
>  \item\label{itm:General Initialization And Device Operation / Device Initialization / Set FEATURES-OK} Set the FEATURES_OK status bit.  The driver MUST NOT accept
> --
> 2.26.2
>
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH] content: Replace guest OS with driver

[Michael S. Tsirkin]

On Tue, May 16, 2023 at 06:01:39AM +0300, Parav Pandit wrote:
> Currently device status field description and driver requirements
> section uses mix of terminology for the driver. These two sections
> sometimes call the driver as 'the guest OS' or 'the driver'.
> 
> Most of the cleanup around 'guest Os' was already done around commit
> 212c0cf3 in past. Clean up the remaining few references to just
> refer it as 'driver'.
> 
> This is an editorial change.

No, editorial changes are things like formatting, correcting cross
references, resolving simple patch conflicts.  We also have a minor
cleanups rule including spelling and typos.  I feel we've been through
this discussion, no?

I'm insisting on clarifying this because you want to be an editor, and
we could benefit from more editors, but given editors have commit access
it's important to be clear what the role of an editor is, which is not
to make decisions about content - it's a technical role.


> Signed-off-by: Parav Pandit <parav@nvidia.com>
> ---
>  content.tex | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> 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.





> @@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper
>  \begin{enumerate}
>  \item Reset the device.
>  
> -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device.
> +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device.
>  
> -\item Set the DRIVER status bit: the guest OS knows how to drive the device.
> +\item Set the DRIVER status bit: the driver knows how to drive the device.

besides the above, "drivers knows how to drive" sounds bad.

>  \item\label{itm:General Initialization And Device Operation /
>  Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits
> -   understood by the OS and driver to the device.  During this step the
> +   understood by the driver to the device.  During this step the

Again the "the OS" here referred to core virtio (e.g. ring features).
Less of a problem to remove but if we come up with
a better terminology for ACKNOWLEDGE/DRIVER then I guess we can use it
here, too.


>     driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device before accepting it.
>  
>  \item\label{itm:General Initialization And Device Operation / Device Initialization / Set FEATURES-OK} Set the FEATURES_OK status bit.  The driver MUST NOT accept
> -- 
> 2.26.2


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH] content: Replace guest OS with driver

[Cornelia Huck]

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."

Probably need some more overhaul :) Not an editorial change in any case.

>> @@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper
>>  \begin{enumerate}
>>  \item Reset the device.
>>  
>> -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device.
>> +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device.
>>  
>> -\item Set the DRIVER status bit: the guest OS knows how to drive the device.
>> +\item Set the DRIVER status bit: the driver knows how to drive the device.
>
> besides the above, "drivers knows how to drive" sounds bad.
>
>>  \item\label{itm:General Initialization And Device Operation /
>>  Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits
>> -   understood by the OS and driver to the device.  During this step the
>> +   understood by the driver to the device.  During this step the
>
> Again the "the OS" here referred to core virtio (e.g. ring features).
> Less of a problem to remove but if we come up with
> a better terminology for ACKNOWLEDGE/DRIVER then I guess we can use it
> here, too.

Hm, I'm not sure how far we need to distinguish between generic and
device-specific features in this case. The "driver" as the whole entity
driving the device needs to decide on the subset; at this stage, it does
not really matter which parts of the driver code accepted which
feature. We probably want to be explicit that features are ring,
transport, and device features, though.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH] content: Replace guest OS with driver

[Michael S. Tsirkin]

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?
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".


SO I propose:

\item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
    device and recognized it as a valid 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.





> Probably need some more overhaul :) Not an editorial change in any case.
> 
> >> @@ -473,13 +473,13 @@ \section{Device Initialization}\label{sec:General Initialization And Device Oper
> >>  \begin{enumerate}
> >>  \item Reset the device.
> >>  
> >> -\item Set the ACKNOWLEDGE status bit: the guest OS has noticed the device.
> >> +\item Set the ACKNOWLEDGE status bit: the driver has noticed the device.
> >>  
> >> -\item Set the DRIVER status bit: the guest OS knows how to drive the device.
> >> +\item Set the DRIVER status bit: the driver knows how to drive the device.
> >
> > besides the above, "drivers knows how to drive" sounds bad.
> >
> >>  \item\label{itm:General Initialization And Device Operation /
> >>  Device Initialization / Read feature bits} Read device feature bits, and write the subset of feature bits
> >> -   understood by the OS and driver to the device.  During this step the
> >> +   understood by the driver to the device.  During this step the
> >
> > Again the "the OS" here referred to core virtio (e.g. ring features).
> > Less of a problem to remove but if we come up with
> > a better terminology for ACKNOWLEDGE/DRIVER then I guess we can use it
> > here, too.
> 
> Hm, I'm not sure how far we need to distinguish between generic and
> device-specific features in this case. The "driver" as the whole entity
> driving the device needs to decide on the subset; at this stage, it does
> not really matter which parts of the driver code accepted which
> feature. We probably want to be explicit that features are ring,
> transport, and device features, though.

OK.

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH] content: Replace guest OS with driver

[Cornelia Huck]

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] RE: [PATCH] content: Replace guest OS with driver

[Parav Pandit]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, May 16, 2023 6:05 AM

> 
> SO I propose:
> 
> \item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
>     device and recognized it as a valid virtio device transport.
> 
> \item[DRIVER (2)] Indicates that a device type specific driver was found
>     and will attempt to attach to the device.
> 
Above bisection is a implementation specific example of Linux (though valid and widely used one).

The UEFI virtio driver doesn't even have such two drivers.
In some OS variant drivers are merged to single kernel binary.
Does driver only matter with device_driver structure or module binary?...

Driver is largely the software entity that drives the device.
I think we can keep the spec simple enough to not mix these details and just call it a "driver".

> 
> BTW somewhat related, I would maybe fix
> device-types/mem/description.tex:change
> not to say "device driver", just "driver" for brevity.
> 
Ok. will fix.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH] content: Replace guest OS with driver

[Michael S. Tsirkin]

On Tue, May 16, 2023 at 07:50:48PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, May 16, 2023 6:05 AM
> 
> > 
> > SO I propose:
> > 
> > \item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
> >     device and recognized it as a valid virtio device transport.
> > 
> > \item[DRIVER (2)] Indicates that a device type specific driver was found
> >     and will attempt to attach to the device.
> > 
> Above bisection is a implementation specific example of Linux (though valid and widely used one).
> 
> The UEFI virtio driver doesn't even have such two drivers.
> In some OS variant drivers are merged to single kernel binary.

which one?

> Does driver only matter with device_driver structure or module binary?...

Can't parse your question.

> Driver is largely the software entity that drives the device.
> I think we can keep the spec simple enough to not mix these details and just call it a "driver".

Not just linux there are lots of drivers like this.  the two bits pass
useful information the way you changed it this distinction is lots.
I agree it is worth thinking what exactly does it mean.
Since you researched it - what exactly do drivers
such as uefi and the unnamed "some OS variant" do exactly?
when do they set ACKNOWLEDGE and when DRIVER?




> > 
> > BTW somewhat related, I would maybe fix
> > device-types/mem/description.tex:change
> > not to say "device driver", just "driver" for brevity.
> > 
> Ok. will fix.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] RE: [PATCH] content: Replace guest OS with driver

[Parav Pandit]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, May 16, 2023 4:48 PM
> 
> On Tue, May 16, 2023 at 07:50:48PM +0000, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Tuesday, May 16, 2023 6:05 AM
> >
> > >
> > > SO I propose:
> > >
> > > \item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
> > >     device and recognized it as a valid virtio device transport.
> > >
> > > \item[DRIVER (2)] Indicates that a device type specific driver was found
> > >     and will attempt to attach to the device.
> > >
> > Above bisection is a implementation specific example of Linux (though valid
> and widely used one).
> >
> > The UEFI virtio driver doesn't even have such two drivers.
> > In some OS variant drivers are merged to single kernel binary.
> 
> which one?
> 
Flavor of a RHEL has inbuilt.

> > Does driver only matter with device_driver structure or module binary?...
> 
> Can't parse your question.
> 
> > Driver is largely the software entity that drives the device.
> > I think we can keep the spec simple enough to not mix these details and just
> call it a "driver".
> 
> Not just linux there are lots of drivers like this.  the two bits pass useful
> information the way you changed it this distinction is lots.
> I agree it is worth thinking what exactly does it mean.
> Since you researched it - what exactly do drivers such as uefi and the unnamed
> "some OS variant" do exactly?
There is just one "driver" virtio_net_pci that has sets the required bits.

> when do they set ACKNOWLEDGE and when DRIVER?
> 
Not any different flow.
Entity is one.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH] content: Replace guest OS with driver

[Michael S. Tsirkin]

On Tue, May 16, 2023 at 08:59:32PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, May 16, 2023 4:48 PM
> > 
> > On Tue, May 16, 2023 at 07:50:48PM +0000, Parav Pandit wrote:
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Tuesday, May 16, 2023 6:05 AM
> > >
> > > >
> > > > SO I propose:
> > > >
> > > > \item[ACKNOWLEDGE (1)] Indicates that a transport driver has found the
> > > >     device and recognized it as a valid virtio device transport.
> > > >
> > > > \item[DRIVER (2)] Indicates that a device type specific driver was found
> > > >     and will attempt to attach to the device.
> > > >
> > > Above bisection is a implementation specific example of Linux (though valid
> > and widely used one).
> > >
> > > The UEFI virtio driver doesn't even have such two drivers.
> > > In some OS variant drivers are merged to single kernel binary.
> > 
> > which one?
> > 
> Flavor of a RHEL has inbuilt.

What does this mean exactly? That virtio core is compiled into kernel?
That does not matter at all.

> > > Does driver only matter with device_driver structure or module binary?...
> > 
> > Can't parse your question.
> > 
> > > Driver is largely the software entity that drives the device.
> > > I think we can keep the spec simple enough to not mix these details and just
> > call it a "driver".
> > 
> > Not just linux there are lots of drivers like this.  the two bits pass useful
> > information the way you changed it this distinction is lots.
> > I agree it is worth thinking what exactly does it mean.
> > Since you researched it - what exactly do drivers such as uefi and the unnamed
> > "some OS variant" do exactly?
> There is just one "driver" virtio_net_pci that has sets the required bits.
> 
> > when do they set ACKNOWLEDGE and when DRIVER?
> > 
> Not any different flow.
> Entity is one.

question is, what happens
- before ACKNOWLEDGE
- after ACKNOWLEDGE before DRIVER 
?


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] RE: [PATCH] content: Replace guest OS with driver

[Parav Pandit]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, May 16, 2023 5:25 PM

> > Flavor of a RHEL has inbuilt.
> 
> What does this mean exactly? That virtio core is compiled into kernel?
> That does not matter at all.
> 
Why does it does not matter? What is the definition of driver, is the device_structure structure or module binary?

> > > > Does driver only matter with device_driver structure or module binary?...
> > >
> > > Can't parse your question.
> > >
> > > > Driver is largely the software entity that drives the device.
> > > > I think we can keep the spec simple enough to not mix these
> > > > details and just
> > > call it a "driver".
> > >
> > > Not just linux there are lots of drivers like this.  the two bits
> > > pass useful information the way you changed it this distinction is lots.
> > > I agree it is worth thinking what exactly does it mean.
> > > Since you researched it - what exactly do drivers such as uefi and
> > > the unnamed "some OS variant" do exactly?
> > There is just one "driver" virtio_net_pci that has sets the required bits.
> >
> > > when do they set ACKNOWLEDGE and when DRIVER?
> > >
> > Not any different flow.
> > Entity is one.
> 
> question is, what happens
> - before ACKNOWLEDGE
> - after ACKNOWLEDGE before DRIVER
> ?
It follows the same sequence described in the spec as "driver" not as "guest OS".


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: [PATCH] content: Replace guest OS with driver

[Michael S. Tsirkin]

On Tue, May 16, 2023 at 09:31:43PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, May 16, 2023 5:25 PM
> 
> > > Flavor of a RHEL has inbuilt.
> > 
> > What does this mean exactly? That virtio core is compiled into kernel?
> > That does not matter at all.
> > 
> Why does it does not matter? What is the definition of driver, is the device_structure structure or module binary?

Neither. It's the part that handles transport or specific device.




> > > > > Does driver only matter with device_driver structure or module binary?...
> > > >
> > > > Can't parse your question.
> > > >
> > > > > Driver is largely the software entity that drives the device.
> > > > > I think we can keep the spec simple enough to not mix these
> > > > > details and just
> > > > call it a "driver".
> > > >
> > > > Not just linux there are lots of drivers like this.  the two bits
> > > > pass useful information the way you changed it this distinction is lots.
> > > > I agree it is worth thinking what exactly does it mean.
> > > > Since you researched it - what exactly do drivers such as uefi and
> > > > the unnamed "some OS variant" do exactly?
> > > There is just one "driver" virtio_net_pci that has sets the required bits.
> > >
> > > > when do they set ACKNOWLEDGE and when DRIVER?
> > > >
> > > Not any different flow.
> > > Entity is one.
> > 
> > question is, what happens
> > - before ACKNOWLEDGE
> > - after ACKNOWLEDGE before DRIVER
> > ?
> It follows the same sequence described in the spec as "driver" not as "guest OS".


Looks like my description is spot on then - check vendor ID,
set ACKNOWLEDGE, check device ID, see that it's a known good value
matching device type we expect, set DRIVER.

Maybe replace with "transport part of the driver" and
"device type specific part of the driver"? A bit verbose but if
it rocks your boat ...

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org