public inbox for virtio-dev@lists.linux.dev
 help / color / mirror / Atom feed
From: Parav Pandit <parav@nvidia.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, cohuck@redhat.com,
	david.edmondson@oracle.com, sburla@marvell.com,
	jasowang@redhat.com, virtio-comment@lists.oasis-open.org,
	shahafs@nvidia.com, Yishai Hadas <yishaih@nvidia.com>,
	Maor Gottlieb <maorg@nvidia.com>
Subject: [virtio-dev] Re: [PATCH v1 1/2] transport-pci: Introduce legacy registers access commands
Date: Wed, 3 May 2023 13:21:39 -0400	[thread overview]
Message-ID: <ba053f8a-4adb-5395-ed75-ac1d0bfe20ee@nvidia.com> (raw)
In-Reply-To: <20230503124212-mutt-send-email-mst@kernel.org>



On 5/3/2023 12:48 PM, Michael S. Tsirkin wrote:

>>> As simple as it is, I feel this falls far short of describing how
>>> a device should operate.
>>> Some issues:
>>> 	- legacy device config offset changes as msi is enabled/disabled
>>> 	  suggest separate commands for device/common config
>> This is fine and covered here. The one who is making msix enable/disable
>> knows which registers to access before/after disable/enable and device also
>> knows it as it is supplying the register.
>> So they just follow the standard legacy register access behavior.
> 
> But do VFs support INT#x? I will have to re-read the spec.
> 
VFs do not support INTx.
When hypervisor knows that it cannot support msix for the guest, it can 
avoid using the VF for the guest.

>>> 	- legacy device endian-ness changes with guest
>>> 	  suggest commands to enable LE and BE mode
>> guest endianeness is not known to the device.
> 
> But is known to hypervisor.
> 
It can be an extension command in future as part of the VF 
administration command to set it by the hypervisor PF.

>> Currently it is only for the
>> LE guests who had some legacy requirement.
> 
> I don't like tying this to LE implicitly some devices might be BE only.
> With my idea device can support command to set LE, command to set BE or
> both.
> 
It can be an addition in future if needed.

>> and PCIe is LE anyway.
> 
> PCIE config endian-ness does not matter heere.
> 
>>> 	- legacy guests often assume INT#x support
>>> 	  suggest a way to tunnel that too;
>> INT#x is present on the PCI device itself. So no need to tunnel it.
>> Also INT#x is very narrow case. When MSI-X is not supported, a hypervisor
>> can choose not to even connect such device to the guest VM.
> 
> devices will support MSI. But *guest* might not support MSIX you only
> find out late when it is driving the device.
> 
It is a pathological case that may not exist because legacy drivers and 
linux kernels all the way upto 2.6.32 have msix support.

And in case if hypervisor sw wants to support for unknown scenario, it 
can use the one msix based interrupt to emulate intx.

>>> I expected to see more statements along the lines of
>>>           command ABC has the same effect as access
>>>           to register DEF of the member through the legacy pci interface
>>>
>> Yes, good point. I will add it in the theory of operation section for this
>> mapping detail.
> 
> OK, and overall if you see an existing statement about legacy do not
> copy it, just explain how it is mapped.
> 
Yes, will not copy, only the mapping part to add.

---------------------------------------------------------------------
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:[~2023-05-03 17:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03  3:26 [virtio-dev] [PATCH v1 0/2] transport-pci: Introduce legacy registers access using AQ Parav Pandit
2023-05-03  3:26 ` [virtio-dev] [PATCH v1 1/2] transport-pci: Introduce legacy registers access commands Parav Pandit
2023-05-03  5:42   ` [virtio-dev] " Michael S. Tsirkin
2023-05-03 14:47     ` Parav Pandit
2023-05-03 16:48       ` Michael S. Tsirkin
2023-05-03 17:21         ` Parav Pandit [this message]
2023-05-04  6:30           ` Michael S. Tsirkin
2023-05-03  5:50   ` Michael S. Tsirkin
2023-05-03 14:49     ` Parav Pandit
2023-05-03 16:49       ` Michael S. Tsirkin
2023-05-03 17:23         ` Parav Pandit
2023-05-04  6:30           ` Michael S. Tsirkin
2023-05-03 19:21   ` Michael S. Tsirkin
2023-05-03 19:38     ` Parav Pandit
2023-05-03 20:08       ` Michael S. Tsirkin
2023-05-03 20:13         ` Parav Pandit
2023-05-05  3:26   ` Jason Wang
2023-05-05 12:48     ` [virtio-dev] " Parav Pandit
2023-05-06  2:24       ` [virtio-dev] " Jason Wang
2023-05-06  2:25         ` Jason Wang
2023-05-03  3:26 ` [virtio-dev] [PATCH v1 2/2] transport-pci: Add legacy register access conformance section Parav Pandit
2023-05-03  5:48   ` [virtio-dev] " Michael S. Tsirkin
2023-05-03 14:53     ` [virtio-dev] Re: [virtio-comment] " Parav Pandit
2023-05-03 19:18       ` Michael S. Tsirkin
2023-05-03 19:56         ` [virtio-dev] " Parav Pandit
2023-05-03 10:16 ` [virtio-dev] Re: [PATCH v1 0/2] transport-pci: Introduce legacy registers access using AQ Michael S. Tsirkin
2023-05-03 14:57   ` Parav Pandit

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=ba053f8a-4adb-5395-ed75-ac1d0bfe20ee@nvidia.com \
    --to=parav@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=david.edmondson@oracle.com \
    --cc=jasowang@redhat.com \
    --cc=maorg@nvidia.com \
    --cc=mst@redhat.com \
    --cc=sburla@marvell.com \
    --cc=shahafs@nvidia.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=yishaih@nvidia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox