All of lore.kernel.org
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@bytedance.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, mst@redhat.com,
	ndragazis@arrikto.com, fam.zheng@bytedance.com,
	liangma@liangbit.com
Subject: [virtio-dev] Re: [PATCH 3/4] content: Introduce driver/device auxiliary notifications for MMIO
Date: Fri, 8 Apr 2022 18:51:15 +0100	[thread overview]
Message-ID: <58a4e70c-a0a8-d52c-4bc6-dd4037da1ce0@bytedance.com> (raw)
In-Reply-To: <YkrmU/w46Fz9EVqT@stefanha-x1.localdomain>



On 04/04/2022 13:36, Stefan Hajnoczi wrote:
> On Wed, Mar 30, 2022 at 04:26:58PM +0100, Usama Arif wrote:
>> @@ -2074,6 +2077,16 @@ \subsection{MMIO Device Register Layout}\label{sec:Virtio Transport Options / Vi
>>       apply to the queue selected by writing to \field{QueueSel}.
>>     }
>>     \hline
>> +  \mmioreg{DeviceAuxiliaryNotification}{Device Auxiliary Notifier}{0xd0}{W}{
>> +    Writing a value to this register triggers a
>> +    notification to the device. The value written to this register is
>> +    interpreted as a device auxiliary notification index. The mapping of device auxiliary notifications to
>> +    device auxiliary notification indices is device-specific. One possible mapping would be
>> +    to use the integers 0 to N-1 as the device auxiliary notification indices for a total of
>> +    N device auxiliary notifications. The total number of device auxiliary notifications exposed by the device is
>> +    also device-specific.
>> +  }
> 
> Hmm...this is slightly different from the PCI transport's approach.
> There each dev aux notification has its own hardware register. That has
> advantages:
> 1. The notification may carry a value with it because the driver writes
>     a value to the register and the device can interpret that value. That
>     can be used as a performance optimization to reduce the number of
>     hardware register writes performed by the driver or DMA transfers
>     initiated by the device.
> 2. The dev aux notification registers can be laid out on separate memory
>     pages. This is useful in passthrough scenarios like nested
>     virtualization or slicing up a device in software and passing a
>     subset to an untrusted process. The MMU only offers page-level
>     protection, so MMIO registers that are colocated within the same
>     memory page cannot be selectively passed through to untrusted
>     software.
> 
> It would be nice if PCI and MMIO exposed dev aux notifications in a
> similar way.
> 
> I haven't followed the history of virtio-mmio closely, so I'm not sure
> if the same approach that was used for PCI is feasible here. Maybe
> someone else can comment?
> 
> Stefan


Agree with the points above. I have split the mmio implementation into 2 
registers in v2. DeviceAuxNotificationIndex to indicate the device 
auxiliary notification index and DeviceAuxNotificationData writing to 
which actually does the notification and carries the data which is 
device specific.

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


  reply	other threads:[~2022-04-08 17:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 15:26 [virtio-dev] [PATCH 0/4] Introduce aux. notifications and virtio-vhost-user Usama Arif
2022-03-30 15:26 ` [virtio-dev] [PATCH 1/4] content: Introduce driver/device auxiliary notifications Usama Arif
2022-04-04 10:06   ` [virtio-dev] " Stefan Hajnoczi
2022-03-30 15:26 ` [virtio-dev] [PATCH 2/4] content: Introduce driver/device aux. notification cfg type for PCI Usama Arif
2022-04-04 10:27   ` [virtio-dev] " Stefan Hajnoczi
2022-04-08 17:50     ` Usama Arif
2022-03-30 15:26 ` [virtio-dev] [PATCH 3/4] content: Introduce driver/device auxiliary notifications for MMIO Usama Arif
2022-04-04 12:36   ` [virtio-dev] " Stefan Hajnoczi
2022-04-08 17:51     ` Usama Arif [this message]
2022-03-30 15:26 ` [virtio-dev] [PATCH 4/4] vhost-user: add vhost-user device type Usama Arif
2022-04-04 13:05   ` [virtio-dev] " Stefan Hajnoczi
2022-04-08 17:56     ` Usama Arif

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=58a4e70c-a0a8-d52c-4bc6-dd4037da1ce0@bytedance.com \
    --to=usama.arif@bytedance.com \
    --cc=fam.zheng@bytedance.com \
    --cc=liangma@liangbit.com \
    --cc=mst@redhat.com \
    --cc=ndragazis@arrikto.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    /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.