From: Cornelia Huck <cohuck@redhat.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>
Cc: sebott@linux.ibm.com, gerald.schaefer@de.ibm.com,
pasic@linux.ibm.com, borntraeger@de.ibm.com,
walling@linux.ibm.com, linux-s390@vger.kernel.org,
iommu@lists.linux-foundation.org, joro@8bytes.org,
linux-kernel@vger.kernel.org, alex.williamson@redhat.com,
kvm@vger.kernel.org, heiko.carstens@de.ibm.com,
robin.murphy@arm.com, gor@linux.ibm.com, pmorel@linux.ibm.com
Subject: Re: [PATCH v4 3/4] vfio: zpci: defining the VFIO headers
Date: Tue, 8 Oct 2019 15:30:04 +0200 [thread overview]
Message-ID: <20191008153004.6be0e095.cohuck@redhat.com> (raw)
In-Reply-To: <86647083-7f94-44aa-8856-103836906f36@linux.ibm.com>
On Fri, 20 Sep 2019 11:14:28 -0400
Matthew Rosato <mjrosato@linux.ibm.com> wrote:
> On 9/20/19 10:02 AM, Cornelia Huck wrote:
> > On Thu, 19 Sep 2019 16:55:57 -0400
> > Matthew Rosato <mjrosato@linux.ibm.com> wrote:
> >
> >> On 9/19/19 11:20 AM, Cornelia Huck wrote:
> >>> On Fri, 6 Sep 2019 20:13:50 -0400
> >>> Matthew Rosato <mjrosato@linux.ibm.com> wrote:
> >>>
> >>>> From: Pierre Morel <pmorel@linux.ibm.com>
> >>>>
> >>>> We define a new device region in vfio.h to be able to
> >>>> get the ZPCI CLP information by reading this region from
> >>>> userland.
> >>>>
> >>>> We create a new file, vfio_zdev.h to define the structure
> >>>> of the new region we defined in vfio.h
> >>>>
> >>>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> >>>> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> >>>> ---
> >>>> include/uapi/linux/vfio.h | 1 +
> >>>> include/uapi/linux/vfio_zdev.h | 35 +++++++++++++++++++++++++++++++++++
> >>>> 2 files changed, 36 insertions(+)
> >>>> create mode 100644 include/uapi/linux/vfio_zdev.h
> >
> >>>> diff --git a/include/uapi/linux/vfio_zdev.h b/include/uapi/linux/vfio_zdev.h
> >>>> new file mode 100644
> >>>> index 0000000..55e0d6d
> >>>> --- /dev/null
> >>>> +++ b/include/uapi/linux/vfio_zdev.h
> >>>> @@ -0,0 +1,35 @@
> >>>> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> >>>> +/*
> >>>> + * Region definition for ZPCI devices
> >>>> + *
> >>>> + * Copyright IBM Corp. 2019
> >>>> + *
> >>>> + * Author(s): Pierre Morel <pmorel@linux.ibm.com>
> >>>> + */
> >>>> +
> >>>> +#ifndef _VFIO_ZDEV_H_
> >>>> +#define _VFIO_ZDEV_H_
> >>>> +
> >>>> +#include <linux/types.h>
> >>>> +
> >>>> +/**
> >>>> + * struct vfio_region_zpci_info - ZPCI information.
> >>>
> >>> Hm... probably should also get some more explanation. E.g. is that
> >>> derived from a hardware structure?
> >>>
> >>
> >> The structure itself is not mapped 1:1 to a hardware structure, but it
> >> does serve as a collection of information that was derived from other
> >> hardware structures.
> >>
> >> "Used for passing hardware feature information about a zpci device
> >> between the host and guest" ?
> >
> > "zPCI specific hardware feature information for a device"?
> >
> > Are we reasonably sure that this is complete for now? I'm not sure if
> > expanding this structure would work; adding another should always be
> > possible, though (if a bit annoying).
> >
>
> I think trying to make the structure expandable would be best... If we
> allow arbitrary-sized reads of the info, and only add new fields onto
> the end it should be OK, no? (older qemu doesn't get the info it doesn't
> ask for / understand).... But I guess that's not compatible with having
> util_str[] size being defined dynamically. Another caveat would be if
> CLP_UTIL_STR_LEN were to grow in size in the future, and assuming
> util_str[] was no longer at the end of the structure, I guess the
> additional data would have to end up in a
> util_str2[CLP_UTIL_STR_LEN_NEW-CLP_UTIL_STR_LEN_OLD]... To explain what
> I mean, something like:
>
> struct vfio_region_zpci_info {
> <..>
> __u8 util_str[CLP_UTIL_STR_LEN_OLD];
> /* END OF V1 */
> __u8 foo;
> /* END OF V2 */
> __u8 util_str2[CLP_UTIL_STR_LEN_NEW-CLP_UTIL_STR_LEN_OLD];
> /* END OF V3 */
> } __packed;
[Sorry about the late response -- was on PTO]
That sounds a bit too complicated to me, and I'd prefer the "add
another region if we missed something" approach. If we put anything
looking potentially useful in here now, that "add another region" event
is hopefully far in the future.
>
>
> >>
> >>>> + *
> >>>> + */
> >>>> +struct vfio_region_zpci_info {
> >>>> + __u64 dasm;
> >>>> + __u64 start_dma;
> >>>> + __u64 end_dma;
> >>>> + __u64 msi_addr;
> >>>> + __u64 flags;
> >>>> + __u16 pchid;
> >>>> + __u16 mui;
> >>>> + __u16 noi;
> >>>> + __u16 maxstbl;
> >>>> + __u8 version;
> >>>> + __u8 gid;
> >>>> +#define VFIO_PCI_ZDEV_FLAGS_REFRESH 1
> >>>> + __u8 util_str[];
> >>>> +} __packed;
> >>>> +
> >>>> +#endif
> >>>
> >>>
> >>
> >
>
next prev parent reply other threads:[~2019-10-08 13:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-07 0:13 [PATCH v4 0/4] Retrieving zPCI specific info with VFIO Matthew Rosato
2019-09-07 0:13 ` [PATCH v4 1/4] s390: pci: Exporting access to CLP PCI function and PCI group Matthew Rosato
2019-09-07 0:13 ` [PATCH v4 2/4] s390: pci: Define the maxstbl CLP response entry Matthew Rosato
2019-09-07 0:13 ` [PATCH v4 3/4] vfio: zpci: defining the VFIO headers Matthew Rosato
2019-09-19 15:20 ` Cornelia Huck
2019-09-19 20:55 ` Matthew Rosato
2019-09-19 22:27 ` Alex Williamson
2019-09-19 22:49 ` Alex Williamson
2019-09-20 14:46 ` Matthew Rosato
2019-09-20 14:02 ` Cornelia Huck
2019-09-20 15:14 ` Matthew Rosato
2019-10-08 13:30 ` Cornelia Huck [this message]
2019-09-07 0:13 ` [PATCH v4 4/4] vfio: pci: Using a device region to retrieve zPCI information Matthew Rosato
2019-09-19 15:25 ` Cornelia Huck
2019-09-19 20:57 ` Matthew Rosato
2019-09-20 14:26 ` Cornelia Huck
2019-09-20 15:53 ` Matthew Rosato
2019-09-19 22:57 ` Alex Williamson
2019-09-20 14:57 ` Matthew Rosato
2019-09-19 1:36 ` [PATCH v4 0/4] Retrieving zPCI specific info with 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=20191008153004.6be0e095.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=gerald.schaefer@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=robin.murphy@arm.com \
--cc=sebott@linux.ibm.com \
--cc=walling@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox