From: Kirti Wankhede <kwankhede@nvidia.com> To: Alex Williamson <alex.williamson@redhat.com> Cc: <pbonzini@redhat.com>, <kraxel@redhat.com>, <cjia@nvidia.com>, <qemu-devel@nongnu.org>, <kvm@vger.kernel.org>, <kevin.tian@intel.com>, <jike.song@intel.com>, <bjsdjshi@linux.vnet.ibm.com>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags Date: Fri, 21 Oct 2016 08:30:53 +0530 [thread overview] Message-ID: <3a51ce1c-1396-676f-3a9b-9faa8390c632@nvidia.com> (raw) In-Reply-To: <20161020152220.57f6ee06@t450s.home> On 10/21/2016 2:52 AM, Alex Williamson wrote: > On Fri, 21 Oct 2016 02:44:37 +0530 > Kirti Wankhede <kwankhede@nvidia.com> wrote: > ... >>>>>> >>>>>> +extern const char *vfio_device_api_string(u32 flags); >>>>>> + >>>>>> struct pci_dev; >>>>>> #ifdef CONFIG_EEH >>>>>> extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev); >>>>> >>>>> Couldn't this simply be a #define in the uapi header? >>>>> >>>>> #define VFIO_DEVICE_PCI_API_STRING "vfio-pci" >>>>> >>>>> I don't really see why we need a lookup function. >>>>> >>>> >>>> String is tightly coupled with the FLAG, right? >>>> Instead user need to take care of making sure to return proper string, >>>> and don't mis-match the string, I think having function is easier. >>> >>> That's exactly why I proposed putting the #define string in the uapi, >>> by that I mean the vfio uapi header. That keeps the tight coupling to >>> the flag, they're both defined in the same place, plus it gives >>> userspace a reference so they're not just inventing a string to compare >>> against. IOW, the vendor driver simply does an sprintf of >>> VFIO_DEVICE_PCI_API_STRING and userspace (ie. libvirt) can do a strcmp >>> with VFIO_DEVICE_PCI_API_STRING from the same header and everybody >>> arrives at the same result. >>> >>>> Vendor driver should decide the type of device they want to expose and >>>> set the flag, using this function vendor driver would return string >>>> which is based on flag they set. >>> >>> Being a function adds no intrinsic value and being in a uapi header does >>> add value to userspace. Thanks, >>> >> >> Ok. The strings should be in uapi, but having function (like below) to >> return proper string based on flag would be good to have for vendor driver. >> >> +const char *vfio_device_api_string(u32 flags) >> +{ >> + if (flags & VFIO_DEVICE_FLAGS_PCI) >> + return VFIO_DEVICE_API_PCI_STRING; >> + >> + if (flags & VFIO_DEVICE_FLAGS_PLATFORM) >> + return VFIO_DEVICE_API_PLATFORM_STRING; >> + >> + if (flags & VFIO_DEVICE_FLAGS_AMBA) >> + return VFIO_DEVICE_API_AMBA_STRING; >> + >> + return ""; >> +} >> +EXPORT_SYMBOL(vfio_device_api_string); > > I disagree, it's pointless maintenance overhead. It's yet another > function that we need to care about for kABI and it offers almost no > value. Thanks, > If any vendor driver sets VFIO_DEVICE_FLAGS_PLATFORM flag but sets VFIO_DEVICE_API_PCI_STRING, we don't have a way to verify this in kernel driver. Is that acceptable? Kirti
WARNING: multiple messages have this Message-ID (diff)
From: Kirti Wankhede <kwankhede@nvidia.com> To: Alex Williamson <alex.williamson@redhat.com> Cc: pbonzini@redhat.com, kraxel@redhat.com, cjia@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com, jike.song@intel.com, bjsdjshi@linux.vnet.ibm.com, linux-kernel@vger.kernel.org Subject: Re: [Qemu-devel] [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags Date: Fri, 21 Oct 2016 08:30:53 +0530 [thread overview] Message-ID: <3a51ce1c-1396-676f-3a9b-9faa8390c632@nvidia.com> (raw) In-Reply-To: <20161020152220.57f6ee06@t450s.home> On 10/21/2016 2:52 AM, Alex Williamson wrote: > On Fri, 21 Oct 2016 02:44:37 +0530 > Kirti Wankhede <kwankhede@nvidia.com> wrote: > ... >>>>>> >>>>>> +extern const char *vfio_device_api_string(u32 flags); >>>>>> + >>>>>> struct pci_dev; >>>>>> #ifdef CONFIG_EEH >>>>>> extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev); >>>>> >>>>> Couldn't this simply be a #define in the uapi header? >>>>> >>>>> #define VFIO_DEVICE_PCI_API_STRING "vfio-pci" >>>>> >>>>> I don't really see why we need a lookup function. >>>>> >>>> >>>> String is tightly coupled with the FLAG, right? >>>> Instead user need to take care of making sure to return proper string, >>>> and don't mis-match the string, I think having function is easier. >>> >>> That's exactly why I proposed putting the #define string in the uapi, >>> by that I mean the vfio uapi header. That keeps the tight coupling to >>> the flag, they're both defined in the same place, plus it gives >>> userspace a reference so they're not just inventing a string to compare >>> against. IOW, the vendor driver simply does an sprintf of >>> VFIO_DEVICE_PCI_API_STRING and userspace (ie. libvirt) can do a strcmp >>> with VFIO_DEVICE_PCI_API_STRING from the same header and everybody >>> arrives at the same result. >>> >>>> Vendor driver should decide the type of device they want to expose and >>>> set the flag, using this function vendor driver would return string >>>> which is based on flag they set. >>> >>> Being a function adds no intrinsic value and being in a uapi header does >>> add value to userspace. Thanks, >>> >> >> Ok. The strings should be in uapi, but having function (like below) to >> return proper string based on flag would be good to have for vendor driver. >> >> +const char *vfio_device_api_string(u32 flags) >> +{ >> + if (flags & VFIO_DEVICE_FLAGS_PCI) >> + return VFIO_DEVICE_API_PCI_STRING; >> + >> + if (flags & VFIO_DEVICE_FLAGS_PLATFORM) >> + return VFIO_DEVICE_API_PLATFORM_STRING; >> + >> + if (flags & VFIO_DEVICE_FLAGS_AMBA) >> + return VFIO_DEVICE_API_AMBA_STRING; >> + >> + return ""; >> +} >> +EXPORT_SYMBOL(vfio_device_api_string); > > I disagree, it's pointless maintenance overhead. It's yet another > function that we need to care about for kABI and it offers almost no > value. Thanks, > If any vendor driver sets VFIO_DEVICE_FLAGS_PLATFORM flag but sets VFIO_DEVICE_API_PCI_STRING, we don't have a way to verify this in kernel driver. Is that acceptable? Kirti
next prev parent reply other threads:[~2016-10-21 3:01 UTC|newest] Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-17 21:22 [PATCH v9 00/12] Add Mediated device support Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-17 21:22 ` [PATCH v9 01/12] vfio: Mediated device Core driver Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-18 23:16 ` Alex Williamson 2016-10-18 23:16 ` [Qemu-devel] " Alex Williamson 2016-10-19 19:16 ` Kirti Wankhede 2016-10-19 19:16 ` [Qemu-devel] " Kirti Wankhede 2016-10-19 22:20 ` Alex Williamson 2016-10-19 22:20 ` [Qemu-devel] " Alex Williamson 2016-10-19 22:20 ` Alex Williamson 2016-10-20 7:23 ` Jike Song 2016-10-20 7:23 ` [Qemu-devel] " Jike Song 2016-10-20 17:12 ` Alex Williamson 2016-10-20 17:12 ` [Qemu-devel] " Alex Williamson 2016-10-21 2:41 ` Jike Song 2016-10-21 2:41 ` [Qemu-devel] " Jike Song 2016-10-27 5:56 ` Jike Song 2016-10-27 5:56 ` [Qemu-devel] " Jike Song 2016-10-26 6:52 ` Tian, Kevin 2016-10-26 6:52 ` [Qemu-devel] " Tian, Kevin 2016-10-26 14:58 ` Kirti Wankhede 2016-10-26 14:58 ` [Qemu-devel] " Kirti Wankhede 2016-10-17 21:22 ` [PATCH v9 02/12] vfio: VFIO based driver for Mediated devices Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-26 6:57 ` Tian, Kevin 2016-10-26 6:57 ` [Qemu-devel] " Tian, Kevin 2016-10-26 15:01 ` Kirti Wankhede 2016-10-26 15:01 ` [Qemu-devel] " Kirti Wankhede 2016-10-17 21:22 ` [PATCH v9 03/12] vfio: Rearrange functions to get vfio_group from dev Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-19 17:26 ` Alex Williamson 2016-10-19 17:26 ` [Qemu-devel] " Alex Williamson 2016-10-17 21:22 ` [PATCH v9 04/12] vfio iommu: Add support for mediated devices Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-17 21:22 ` Kirti Wankhede 2016-10-19 21:02 ` Alex Williamson 2016-10-19 21:02 ` [Qemu-devel] " Alex Williamson 2016-10-20 20:17 ` Kirti Wankhede 2016-10-20 20:17 ` [Qemu-devel] " Kirti Wankhede 2016-10-24 2:32 ` Alex Williamson 2016-10-24 2:32 ` [Qemu-devel] " Alex Williamson 2016-10-26 7:19 ` Tian, Kevin 2016-10-26 7:19 ` [Qemu-devel] " Tian, Kevin 2016-10-26 15:06 ` Kirti Wankhede 2016-10-26 15:06 ` [Qemu-devel] " Kirti Wankhede 2016-10-26 7:53 ` Tian, Kevin 2016-10-26 7:53 ` [Qemu-devel] " Tian, Kevin 2016-10-26 15:16 ` Alex Williamson 2016-10-26 15:16 ` [Qemu-devel] " Alex Williamson 2016-10-26 7:54 ` Tian, Kevin 2016-10-26 7:54 ` [Qemu-devel] " Tian, Kevin 2016-10-26 15:19 ` Alex Williamson 2016-10-26 15:19 ` [Qemu-devel] " Alex Williamson 2016-10-21 7:49 ` Jike Song 2016-10-21 7:49 ` [Qemu-devel] " Jike Song 2016-10-21 14:36 ` Alex Williamson 2016-10-21 14:36 ` [Qemu-devel] " Alex Williamson 2016-10-24 10:35 ` Kirti Wankhede 2016-10-24 10:35 ` [Qemu-devel] " Kirti Wankhede 2016-10-27 7:20 ` Alexey Kardashevskiy 2016-10-27 12:31 ` Kirti Wankhede 2016-10-27 12:31 ` Kirti Wankhede 2016-10-27 12:31 ` Kirti Wankhede 2016-10-27 14:30 ` [Qemu-devel] " Alex Williamson 2016-10-27 14:30 ` Alex Williamson 2016-10-27 14:30 ` Alex Williamson 2016-10-27 15:59 ` [Qemu-devel] " Kirti Wankhede 2016-10-27 15:59 ` Kirti Wankhede 2016-10-28 2:18 ` Alexey Kardashevskiy 2016-11-01 14:01 ` Kirti Wankhede 2016-11-01 14:01 ` Kirti Wankhede 2016-11-02 1:24 ` Alexey Kardashevskiy 2016-11-02 3:29 ` Kirti Wankhede 2016-11-02 3:29 ` Kirti Wankhede 2016-11-02 4:09 ` Alexey Kardashevskiy 2016-11-02 12:21 ` Jike Song 2016-11-02 12:21 ` Jike Song 2016-11-02 12:41 ` [Qemu-devel] " Kirti Wankhede 2016-11-02 12:41 ` Kirti Wankhede 2016-11-02 13:00 ` Jike Song 2016-11-02 13:18 ` Kirti Wankhede 2016-11-02 13:18 ` Kirti Wankhede 2016-11-02 13:35 ` Jike Song 2016-11-02 13:35 ` Jike Song 2016-11-03 4:29 ` [Qemu-devel] " Alexey Kardashevskiy 2016-11-03 4:29 ` Alexey Kardashevskiy 2016-10-17 21:22 ` [PATCH v9 05/12] vfio: Introduce common function to add capabilities Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-20 19:24 ` Alex Williamson 2016-10-20 19:24 ` [Qemu-devel] " Alex Williamson 2016-10-24 21:27 ` Kirti Wankhede 2016-10-24 21:27 ` [Qemu-devel] " Kirti Wankhede 2016-10-24 21:39 ` Alex Williamson 2016-10-24 21:39 ` [Qemu-devel] " Alex Williamson 2016-10-17 21:22 ` [PATCH v9 06/12] vfio_pci: Update vfio_pci to use vfio_info_add_capability() Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-20 19:24 ` Alex Williamson 2016-10-20 19:24 ` [Qemu-devel] " Alex Williamson 2016-10-24 21:22 ` Kirti Wankhede 2016-10-24 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-24 21:37 ` Alex Williamson 2016-10-24 21:37 ` [Qemu-devel] " Alex Williamson 2016-10-17 21:22 ` [PATCH v9 07/12] vfio: Introduce vfio_set_irqs_validate_and_prepare() Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-17 21:22 ` [PATCH v9 08/12] vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare() Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-17 21:22 ` [PATCH v9 09/12] vfio_platform: " Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-17 21:22 ` [PATCH v9 10/12] vfio: Add function to get device_api string from vfio_device_info.flags Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-20 19:34 ` Alex Williamson 2016-10-20 19:34 ` [Qemu-devel] " Alex Williamson 2016-10-20 20:29 ` Kirti Wankhede 2016-10-20 20:29 ` [Qemu-devel] " Kirti Wankhede 2016-10-20 21:05 ` Alex Williamson 2016-10-20 21:05 ` [Qemu-devel] " Alex Williamson 2016-10-20 21:14 ` Kirti Wankhede 2016-10-20 21:14 ` [Qemu-devel] " Kirti Wankhede 2016-10-20 21:22 ` Alex Williamson 2016-10-20 21:22 ` [Qemu-devel] " Alex Williamson 2016-10-21 3:00 ` Kirti Wankhede [this message] 2016-10-21 3:00 ` Kirti Wankhede 2016-10-21 3:20 ` Alex Williamson 2016-10-21 3:20 ` [Qemu-devel] " Alex Williamson 2016-10-17 21:22 ` [PATCH v9 11/12] docs: Add Documentation for Mediated devices Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-25 16:17 ` Alex Williamson 2016-10-25 16:17 ` [Qemu-devel] " Alex Williamson 2016-10-17 21:22 ` [PATCH v9 12/12] docs: Sample driver to demonstrate how to use Mediated device framework Kirti Wankhede 2016-10-17 21:22 ` [Qemu-devel] " Kirti Wankhede 2016-10-18 2:54 ` Dong Jia Shi 2016-10-18 17:17 ` Alex Williamson 2016-10-18 17:17 ` [Qemu-devel] " Alex Williamson 2016-10-19 19:19 ` Kirti Wankhede 2016-10-19 19:19 ` [Qemu-devel] " Kirti Wankhede 2016-10-18 2:54 ` Dong Jia Shi 2016-10-17 21:41 ` [PATCH v9 00/12] Add Mediated device support Alex Williamson 2016-10-17 21:41 ` [Qemu-devel] " Alex Williamson 2016-10-24 7:07 ` Jike Song 2016-10-24 7:07 ` [Qemu-devel] " Jike Song 2016-12-05 17:44 ` Gerd Hoffmann 2016-12-05 17:44 ` [Qemu-devel] " Gerd Hoffmann 2016-12-05 17:44 ` Gerd Hoffmann 2016-12-06 2:24 ` Jike Song 2016-12-06 2:24 ` [Qemu-devel] " Jike Song 2016-12-07 14:40 ` Gerd Hoffmann 2016-12-07 14:40 ` [Qemu-devel] " Gerd Hoffmann
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=3a51ce1c-1396-676f-3a9b-9faa8390c632@nvidia.com \ --to=kwankhede@nvidia.com \ --cc=alex.williamson@redhat.com \ --cc=bjsdjshi@linux.vnet.ibm.com \ --cc=cjia@nvidia.com \ --cc=jike.song@intel.com \ --cc=kevin.tian@intel.com \ --cc=kraxel@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.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: linkBe 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.