From: Cornelia Huck <cohuck@redhat.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
schnelle@linux.ibm.com, pmorel@linux.ibm.com,
borntraeger@de.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
gerald.schaefer@linux.ibm.com, linux-s390@vger.kernel.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/5] vfio-pci/zdev: define the vfio_zdev header
Date: Mon, 5 Oct 2020 18:01:07 +0200 [thread overview]
Message-ID: <20201005180107.5d027441.cohuck@redhat.com> (raw)
In-Reply-To: <8a71af3b-f8fc-48b2-45c6-51222fd2455b@linux.ibm.com>
On Mon, 5 Oct 2020 09:52:25 -0400
Matthew Rosato <mjrosato@linux.ibm.com> wrote:
> On 10/2/20 5:44 PM, Alex Williamson wrote:
> > Can you discuss why a region with embedded capability chain is a better
> > solution than extending the VFIO_DEVICE_GET_INFO ioctl to support a
> > capability chain and providing this info there? This all appears to be
> > read-only info, so what's the benefit of duplicating yet another
>
> It is indeed read-only info, and the device region was defined as such.
>
> I would not necessarily be opposed to extending VFIO_DEVICE_GET_INFO
> with these defined as capabilities; I'd say a primary motivating factor
> to putting these in their own region was to avoid stuffing a bunch of
> s390-specific capabilities into a general-purpose ioctl response.
Can't you make the zdev code register the capabilities? That would put
them nicely into their own configurable part.
>
> But if you're OK with that notion, I can give that a crack in v3.
>
> > capability chain in a region? It would also be possible to define four
> > separate device specific regions, one for each of these capabilities
> > rather than creating this chain. It just seems like a strange approach
>
> I'm not sure if creating separate regions would be the right approach
> though; these are just the first 4. There will definitely be additional
> capabilities in support of new zPCI features moving forward, I'm not
> sure how many regions we really want to end up with. Some might be as
> small as a single field, which seems more in-line with capabilities vs
> an entire region.
If we are expecting more of these in the future, going with GET_INFO
capabilities when adding new ones seems like the best approach.
next prev parent reply other threads:[~2020-10-05 16:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 20:00 [PATCH v2 0/5] Pass zPCI hardware information via VFIO Matthew Rosato
2020-10-02 20:00 ` [PATCH v2 1/5] s390/pci: stash version in the zpci_dev Matthew Rosato
2020-10-02 20:00 ` [PATCH v2 2/5] s390/pci: track whether util_str is valid " Matthew Rosato
2020-10-06 15:24 ` Cornelia Huck
2020-10-02 20:00 ` [PATCH v2 3/5] vfio-pci/zdev: define the vfio_zdev header Matthew Rosato
2020-10-02 21:44 ` Alex Williamson
2020-10-05 13:52 ` Matthew Rosato
2020-10-05 16:01 ` Cornelia Huck [this message]
2020-10-05 16:16 ` Matthew Rosato
2020-10-05 16:28 ` Cornelia Huck
2020-10-02 20:00 ` [PATCH v2 4/5] vfio-pci/zdev: use a device region to retrieve zPCI information Matthew Rosato
2020-10-02 20:00 ` [PATCH v2 5/5] MAINTAINERS: Add entry for s390 vfio-pci Matthew Rosato
2020-10-06 15:27 ` Cornelia Huck
2020-10-02 20:18 ` [PATCH v2 0/5] Pass zPCI hardware information via VFIO Matthew Rosato
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=20201005180107.5d027441.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=schnelle@linux.ibm.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 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.