All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	David Stevens <stevensd@chromium.org>
Cc: "Zhu Lingshan" <lingshan.zhu@amd.com>,
	jasowang@redhat.com, virtio-comment@lists.linux.dev,
	"Zhu Lingshan" <lingshan.zhu@intel.com>,
	"Eugenio Pérez" <eperezma@redhat.com>
Subject: Re: [RESEND PATCH v6] virtio: introduce SUSPEND bit in device status
Date: Fri, 12 Jul 2024 13:44:19 +0200	[thread overview]
Message-ID: <87frsebzsc.fsf@redhat.com> (raw)
In-Reply-To: <20240704044403-mutt-send-email-mst@kernel.org>

On Thu, Jul 04 2024, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Jul 04, 2024 at 05:39:32PM +0900, David Stevens wrote:
>> On Wed, Jul 3, 2024 at 6:01 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>> >
>> > On Wed, Jul 03, 2024 at 11:10:57AM +0800, Zhu Lingshan wrote:
>> > > +\item The driver MUST NOT access Device Configuration Space except for the field \field {device status},
>> > > +if it is implemented in the Config Space.
>> >
>> > what is "the Config Space"? device status is never in
>> > a device configuration space, it is part of the common configuration.
>> > so what exactly are you forbidding here?
>> 
>> IIUC, referring to the common configuration here wouldn't make sense.
>> The common configuration is part of the PCI transport specification,
>> so in this part of the specification it should only be referred to via
>> the "transport specific" phrasing.
>
> Good point.  We can easily fix this for MMIO though.
>
>  
> MMIO virtio devices provide a set of memory mapped control
> registers followed by a device-specific configuration space,
> described in the table~\ref{tab:Virtio Transport Options / Virtio Over MMIO / MMIO Device Register Layout}.
>
> ->
>
> MMIO virtio devices provide memory mapped control
> including a set of common configuration
> registers followed by a device-specific configuration space,
> described in the table~\ref{tab:Virtio Transport Options / Virtio Over MMIO / MMIO Device Register Layout}.
>
>
>
> Less sure about CCW.
> Maybe:
>
> In addition to the basic channel commands, virtio-ccw defines a
> set of channel commands related to configuration and operation of
> virtio:
>
> \begin{lstlisting}
> #define CCW_CMD_SET_VQ 0x13
> #define CCW_CMD_VDEV_RESET 0x33
> #define CCW_CMD_SET_IND 0x43
> #define CCW_CMD_SET_CONF_IND 0x53
> #define CCW_CMD_SET_IND_ADAPTER 0x73
> #define CCW_CMD_READ_FEAT 0x12
> #define CCW_CMD_WRITE_FEAT 0x11
> #define CCW_CMD_READ_CONF 0x22
> #define CCW_CMD_WRITE_CONF 0x21
> #define CCW_CMD_WRITE_STATUS 0x31
> #define CCW_CMD_READ_VQ_CONF 0x32
> #define CCW_CMD_SET_VIRTIO_REV 0x83
> #define CCW_CMD_READ_STATUS 0x72
> \end{lstlisting}
>
> ->
>
>
> In addition to the basic channel commands, virtio-ccw defines
> channel commands related to configuration and operation of
> virtio - a set of commands to access common configuration of
> the device:

Hm, I'm not sure whether "common configuration" is the best wording
here; resetting a device, for example, is not something I'd call
configuration. If we don't manage to come up with anything better, I can
live with it, though.

>
> \begin{lstlisting}
> #define CCW_CMD_SET_VQ 0x13
> #define CCW_CMD_VDEV_RESET 0x33
> #define CCW_CMD_SET_IND 0x43
> #define CCW_CMD_SET_CONF_IND 0x53
> #define CCW_CMD_SET_IND_ADAPTER 0x73
> #define CCW_CMD_READ_FEAT 0x12
> #define CCW_CMD_WRITE_FEAT 0x11
> #define CCW_CMD_WRITE_STATUS 0x31
> #define CCW_CMD_READ_VQ_CONF 0x32
> #define CCW_CMD_SET_VIRTIO_REV 0x83
> #define CCW_CMD_READ_STATUS 0x72
> \end{lstlisting}
>
> and additionally, two commands to access the device
> specification configuration space:
>
> \begin{lstlisting}
> #define CCW_CMD_READ_CONF 0x22
> #define CCW_CMD_WRITE_CONF 0x21
> \end{lstlisting}
>
>
> And now we have common configuration defined for all transports.
> Cornelia, WDYT?
>
>
>> This wording appears to be taken
>> from Cornelia's feedback on v5. Specifically:
>> 
>> > > +\item The driver MUST NOT access Device Configuration Space.
>> > ...except for the status field, if it is part of the config space?
>> 
>> I asked for clarification [1], because Cornelia's feedback seems to
>> contradict your feedback here and on the (unfortunately unarchived) v3
>> patch. What is the definitive statement agreed upon by both editors of
>> the virtio specification as to whether or not the device status field
>> is part of the device configuration space?
>> 
>> [1] https://lore.kernel.org/all/CAD=HUj4RBeLS4L=ehyPGtejeu+sGZ5j8PRtrK8AvxjEgEBd5ZA@mail.gmail.com/
>> 
>> -David
>
> I don't know what did Cornelia mean. Cornelia?

What I meant (I think...) was that accessing the status field is fine,
even if it is implemented as part of the config space.


  parent reply	other threads:[~2024-07-12 11:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03  3:10 [RESEND PATCH v6] virtio: introduce SUSPEND bit in device status Zhu Lingshan
2024-07-03  9:01 ` Michael S. Tsirkin
2024-07-04  8:39   ` David Stevens
2024-07-04  8:55     ` Michael S. Tsirkin
2024-07-12  9:04       ` Zhu Lingshan
2024-07-12 11:18         ` Michael S. Tsirkin
2024-07-19  8:49           ` Zhu Lingshan
2024-07-12 11:44       ` Cornelia Huck [this message]
2024-07-12  8:55   ` Zhu Lingshan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87frsebzsc.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=lingshan.zhu@amd.com \
    --cc=lingshan.zhu@intel.com \
    --cc=mst@redhat.com \
    --cc=stevensd@chromium.org \
    --cc=virtio-comment@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.