From: Jason Wang <jasowang@redhat.com> To: "Tian, Kevin" <kevin.tian@intel.com>, Alex Williamson <alex.williamson@redhat.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org> Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "dev@dpdk.org" <dev@dpdk.org>, "mtosatti@redhat.com" <mtosatti@redhat.com>, "thomas@monjalon.net" <thomas@monjalon.net>, "bluca@debian.org" <bluca@debian.org>, "jerinjacobk@gmail.com" <jerinjacobk@gmail.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, "cohuck@redhat.com" <cohuck@redhat.com> Subject: Re: [PATCH v2 0/7] vfio/pci: SR-IOV support Date: Tue, 25 Feb 2020 14:09:07 +0800 [thread overview] Message-ID: <a6c04bac-0a37-f4c0-876e-e5cf2a8a6c3f@redhat.com> (raw) In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19D79A8A7@SHSMSX104.ccr.corp.intel.com> On 2020/2/25 上午10:33, Tian, Kevin wrote: >> From: Alex Williamson >> Sent: Thursday, February 20, 2020 2:54 AM >> >> Changes since v1 are primarily to patch 3/7 where the commit log is >> rewritten, along with option parsing and failure logging based on >> upstream discussions. The primary user visible difference is that >> option parsing is now much more strict. If a vf_token option is >> provided that cannot be used, we generate an error. As a result of >> this, opening a PF with a vf_token option will serve as a mechanism of >> setting the vf_token. This seems like a more user friendly API than >> the alternative of sometimes requiring the option (VFs in use) and >> sometimes rejecting it, and upholds our desire that the option is >> always either used or rejected. >> >> This also means that the VFIO_DEVICE_FEATURE ioctl is not the only >> means of setting the VF token, which might call into question whether >> we absolutely need this new ioctl. Currently I'm keeping it because I >> can imagine use cases, for example if a hypervisor were to support >> SR-IOV, the PF device might be opened without consideration for a VF >> token and we'd require the hypservisor to close and re-open the PF in >> order to set a known VF token, which is impractical. >> >> Series overview (same as provided with v1): > Thanks for doing this! > >> The synopsis of this series is that we have an ongoing desire to drive >> PCIe SR-IOV PFs from userspace with VFIO. There's an immediate need >> for this with DPDK drivers and potentially interesting future use > Can you provide a link to the DPDK discussion? > >> cases in virtualization. We've been reluctant to add this support >> previously due to the dependency and trust relationship between the >> VF device and PF driver. Minimally the PF driver can induce a denial >> of service to the VF, but depending on the specific implementation, >> the PF driver might also be responsible for moving data between VFs >> or have direct access to the state of the VF, including data or state >> otherwise private to the VF or VF driver. > Just a loud thinking. While the motivation of VF token sounds reasonable > to me, I'm curious why the same concern is not raised in other usages. > For example, there is no such design in virtio framework, where the > virtio device could also be restarted, putting in separate process (vhost-user), > and even in separate VM (virtio-vhost-user), etc. AFAIK, the restart could only be triggered by either VM or qemu. But yes, the datapath could be offloaded. But I'm not sure introducing another dedicated mechanism is better than using the exist generic POSIX mechanism to make sure the connection (AF_UINX) is secure. > Of course the para- > virtualized attribute of virtio implies some degree of trust, but as you > mentioned many SR-IOV implementations support VF->PF communication > which also implies some level of trust. It's perfectly fine if VFIO just tries > to do better than other sub-systems, but knowing how other people > tackle the similar problem may make the whole picture clearer. 😊 > > +Jason. I'm not quite sure e.g allowing userspace PF driver with kernel VF driver would not break the assumption of kernel security model. At least we should forbid a unprivileged PF driver running in userspace. Thanks
WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com> To: "Tian, Kevin" <kevin.tian@intel.com>, Alex Williamson <alex.williamson@redhat.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org> Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "dev@dpdk.org" <dev@dpdk.org>, "mtosatti@redhat.com" <mtosatti@redhat.com>, "thomas@monjalon.net" <thomas@monjalon.net>, "bluca@debian.org" <bluca@debian.org>, "jerinjacobk@gmail.com" <jerinjacobk@gmail.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, "cohuck@redhat.com" <cohuck@redhat.com> Subject: Re: [dpdk-dev] [PATCH v2 0/7] vfio/pci: SR-IOV support Date: Tue, 25 Feb 2020 14:09:07 +0800 [thread overview] Message-ID: <a6c04bac-0a37-f4c0-876e-e5cf2a8a6c3f@redhat.com> (raw) In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19D79A8A7@SHSMSX104.ccr.corp.intel.com> On 2020/2/25 上午10:33, Tian, Kevin wrote: >> From: Alex Williamson >> Sent: Thursday, February 20, 2020 2:54 AM >> >> Changes since v1 are primarily to patch 3/7 where the commit log is >> rewritten, along with option parsing and failure logging based on >> upstream discussions. The primary user visible difference is that >> option parsing is now much more strict. If a vf_token option is >> provided that cannot be used, we generate an error. As a result of >> this, opening a PF with a vf_token option will serve as a mechanism of >> setting the vf_token. This seems like a more user friendly API than >> the alternative of sometimes requiring the option (VFs in use) and >> sometimes rejecting it, and upholds our desire that the option is >> always either used or rejected. >> >> This also means that the VFIO_DEVICE_FEATURE ioctl is not the only >> means of setting the VF token, which might call into question whether >> we absolutely need this new ioctl. Currently I'm keeping it because I >> can imagine use cases, for example if a hypervisor were to support >> SR-IOV, the PF device might be opened without consideration for a VF >> token and we'd require the hypservisor to close and re-open the PF in >> order to set a known VF token, which is impractical. >> >> Series overview (same as provided with v1): > Thanks for doing this! > >> The synopsis of this series is that we have an ongoing desire to drive >> PCIe SR-IOV PFs from userspace with VFIO. There's an immediate need >> for this with DPDK drivers and potentially interesting future use > Can you provide a link to the DPDK discussion? > >> cases in virtualization. We've been reluctant to add this support >> previously due to the dependency and trust relationship between the >> VF device and PF driver. Minimally the PF driver can induce a denial >> of service to the VF, but depending on the specific implementation, >> the PF driver might also be responsible for moving data between VFs >> or have direct access to the state of the VF, including data or state >> otherwise private to the VF or VF driver. > Just a loud thinking. While the motivation of VF token sounds reasonable > to me, I'm curious why the same concern is not raised in other usages. > For example, there is no such design in virtio framework, where the > virtio device could also be restarted, putting in separate process (vhost-user), > and even in separate VM (virtio-vhost-user), etc. AFAIK, the restart could only be triggered by either VM or qemu. But yes, the datapath could be offloaded. But I'm not sure introducing another dedicated mechanism is better than using the exist generic POSIX mechanism to make sure the connection (AF_UINX) is secure. > Of course the para- > virtualized attribute of virtio implies some degree of trust, but as you > mentioned many SR-IOV implementations support VF->PF communication > which also implies some level of trust. It's perfectly fine if VFIO just tries > to do better than other sub-systems, but knowing how other people > tackle the similar problem may make the whole picture clearer. 😊 > > +Jason. I'm not quite sure e.g allowing userspace PF driver with kernel VF driver would not break the assumption of kernel security model. At least we should forbid a unprivileged PF driver running in userspace. Thanks
next prev parent reply other threads:[~2020-02-25 6:09 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-19 18:53 [PATCH v2 0/7] vfio/pci: SR-IOV support Alex Williamson 2020-02-19 18:53 ` [dpdk-dev] " Alex Williamson 2020-02-19 18:53 ` [PATCH v2 1/7] vfio: Include optional device match in vfio_device_ops callbacks Alex Williamson 2020-02-19 18:53 ` [dpdk-dev] " Alex Williamson 2020-02-19 18:54 ` [PATCH v2 2/7] vfio/pci: Implement match ops Alex Williamson 2020-02-19 18:54 ` [dpdk-dev] " Alex Williamson 2020-02-19 18:54 ` [PATCH v2 3/7] vfio/pci: Introduce VF token Alex Williamson 2020-02-19 18:54 ` [dpdk-dev] " Alex Williamson 2020-02-25 2:59 ` Tian, Kevin 2020-02-25 2:59 ` [dpdk-dev] " Tian, Kevin 2020-03-05 18:17 ` Alex Williamson 2020-03-05 18:17 ` [dpdk-dev] " Alex Williamson 2020-03-06 8:32 ` Tian, Kevin 2020-03-06 8:32 ` [dpdk-dev] " Tian, Kevin 2020-03-06 15:39 ` Alex Williamson 2020-03-06 15:39 ` [dpdk-dev] " Alex Williamson 2020-03-07 1:04 ` Tian, Kevin 2020-03-07 1:04 ` [dpdk-dev] " Tian, Kevin 2020-03-09 0:46 ` Alex Williamson 2020-03-09 0:46 ` [dpdk-dev] " Alex Williamson 2020-03-09 1:22 ` Tian, Kevin 2020-03-09 1:22 ` [dpdk-dev] " Tian, Kevin 2020-03-09 1:33 ` Tian, Kevin 2020-03-09 1:33 ` [dpdk-dev] " Tian, Kevin 2020-03-09 15:35 ` Alex Williamson 2020-03-09 15:35 ` [dpdk-dev] " Alex Williamson 2020-02-19 18:54 ` [PATCH v2 4/7] vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user Alex Williamson 2020-02-19 18:54 ` [dpdk-dev] " Alex Williamson 2020-02-27 17:34 ` Cornelia Huck 2020-02-27 17:34 ` [dpdk-dev] " Cornelia Huck 2020-03-05 20:51 ` Alex Williamson 2020-03-05 20:51 ` [dpdk-dev] " Alex Williamson 2020-02-19 18:54 ` [PATCH v2 5/7] vfio/pci: Add sriov_configure support Alex Williamson 2020-02-19 18:54 ` [dpdk-dev] " Alex Williamson 2020-02-25 3:08 ` Tian, Kevin 2020-02-25 3:08 ` [dpdk-dev] " Tian, Kevin 2020-03-05 18:22 ` Alex Williamson 2020-03-05 18:22 ` [dpdk-dev] " Alex Williamson 2020-03-05 20:08 ` Ajit Khaparde 2020-03-06 7:57 ` Tian, Kevin 2020-03-06 7:57 ` [dpdk-dev] " Tian, Kevin 2020-03-06 22:17 ` Alex Williamson 2020-03-06 22:17 ` [dpdk-dev] " Alex Williamson 2020-03-07 1:35 ` Tian, Kevin 2020-03-07 1:35 ` [dpdk-dev] " Tian, Kevin 2020-03-09 0:46 ` Alex Williamson 2020-03-09 0:46 ` [dpdk-dev] " Alex Williamson 2020-03-09 1:48 ` Tian, Kevin 2020-03-09 1:48 ` [dpdk-dev] " Tian, Kevin 2020-03-09 14:56 ` Alex Williamson 2020-03-09 14:56 ` [dpdk-dev] " Alex Williamson 2020-03-06 9:45 ` Tian, Kevin 2020-03-06 9:45 ` [dpdk-dev] " Tian, Kevin 2020-03-06 15:50 ` Alex Williamson 2020-03-06 15:50 ` [dpdk-dev] " Alex Williamson 2020-02-19 18:54 ` [PATCH v2 6/7] vfio/pci: Remove dev_fmt definition Alex Williamson 2020-02-19 18:54 ` [dpdk-dev] " Alex Williamson 2020-02-19 18:54 ` [PATCH v2 7/7] vfio/pci: Cleanup .probe() exit paths Alex Williamson 2020-02-19 18:54 ` [dpdk-dev] " Alex Williamson 2020-02-25 2:33 ` [PATCH v2 0/7] vfio/pci: SR-IOV support Tian, Kevin 2020-02-25 2:33 ` [dpdk-dev] " Tian, Kevin 2020-02-25 6:09 ` Jason Wang [this message] 2020-02-25 6:09 ` Jason Wang 2020-03-05 17:14 ` Alex Williamson 2020-03-05 17:14 ` [dpdk-dev] " Alex Williamson 2020-03-06 3:35 ` Jason Wang 2020-03-06 3:35 ` [dpdk-dev] " Jason Wang 2020-03-06 16:24 ` Alex Williamson 2020-03-06 16:24 ` [dpdk-dev] " Alex Williamson 2020-03-09 3:36 ` Jason Wang 2020-03-09 3:36 ` [dpdk-dev] " Jason Wang 2020-03-09 14:45 ` Alex Williamson 2020-03-09 14:45 ` [dpdk-dev] " Alex Williamson 2020-03-05 17:33 ` Alex Williamson 2020-03-05 17:33 ` [dpdk-dev] " Alex Williamson 2020-03-06 9:21 ` Tian, Kevin 2020-03-06 9:21 ` [dpdk-dev] " Tian, Kevin 2020-03-05 6:38 ` Vamsi Krishna Attunuru 2020-03-05 6:38 ` Vamsi Krishna Attunuru
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=a6c04bac-0a37-f4c0-876e-e5cf2a8a6c3f@redhat.com \ --to=jasowang@redhat.com \ --cc=alex.williamson@redhat.com \ --cc=bluca@debian.org \ --cc=bruce.richardson@intel.com \ --cc=cohuck@redhat.com \ --cc=dev@dpdk.org \ --cc=jerinjacobk@gmail.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=mtosatti@redhat.com \ --cc=thomas@monjalon.net \ /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.