On Mon, Jun 07, 2021 at 03:30:21PM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 02.06.21 19:21, Jason Gunthorpe wrote:
>
> Hi,
>
> > Not really, once one thing in an applicate uses a large number FDs the
> > entire application is effected. If any open() can ret
On Mon, Jun 07, 2021 at 09:41:48AM -0600, Alex Williamson wrote:
> You're calling this an admin knob, which to me suggests a global module
> option, so are you trying to implement both an administrator and a user
> policy? ie. the user can create scenarios where access to wbinvd might
> be justifi
On Mon, Jun 07, 2021 at 12:59:46PM -0600, Alex Williamson wrote:
> > It is up to qemu if it wants to proceed or not. There is no issue with
> > allowing the use of no-snoop and blocking wbinvd, other than some
> > drivers may malfunction. If the user is certain they don't have
> > malfunctioning d
On Mon, Jun 07, 2021 at 01:41:28PM -0600, Alex Williamson wrote:
> > Compatibility is important, but when I look in the kernel code I see
> > very few places that call wbinvd(). Basically all DRM for something
> > relavent to qemu.
> >
> > That tells me that the vast majority of PCI devices do no
On Tue, Jun 08, 2021 at 10:54:59AM +0200, Enrico Weigelt, metux IT consult
wrote:
> Maybe the device as well as the transport could announce their
> capability (which IMHO should go via the virtio protocol), and if both
> are capable, the (guest's) virtio subsys tells the driver whether it's
> us
On Tue, Jun 08, 2021 at 12:43:38PM +0200, Enrico Weigelt, metux IT consult
wrote:
> > It is two devices, thus two files.
>
> Two separate real (hardware) devices or just two logical device nodes ?
A real PCI device and a real IOMMU block integrated into the CPU
Jason
__
On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> > > Alternatively you can add a KVM_DEV_IOASID_{ADD,DEL} pair of ioctls. But
> > > it
> > > seems useless complication compared to just using what we have now, at
> > > least
> > > while VMs only use IOASIDs via VFIO.
> >
> > The
On Tue, Jun 08, 2021 at 12:37:04PM +1000, David Gibson wrote:
> > The PPC/SPAPR support allows KVM to associate a vfio group to an IOMMU
> > page table so that it can handle iotlb programming from pre-registered
> > memory without trapping out to userspace.
>
> To clarify that's a guest side logi
On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
> Well, this sounds like a re-invention of io_uring which has already worked
> for multifds.
How so? io_uring is about sending work to the kernel, not getting
structued events back?
It is more like one of the perf rings
Jason
_
On Tue, Jun 08, 2021 at 10:44:31AM +1000, David Gibson wrote:
> When you say "not using a drivers/iommu IOMMU interface" do you
> basically mean the device doesn't do DMA?
No, I mean the device doesn't use iommu_map() to manage the DMA
mappings.
vfio_iommu_type1 has a special code path that mde
On Tue, Jun 08, 2021 at 12:47:00PM -0600, Alex Williamson wrote:
> On Tue, 8 Jun 2021 15:44:26 +0200
> Paolo Bonzini wrote:
>
> > On 08/06/21 15:15, Jason Gunthorpe wrote:
> > > On Tue, Jun 08, 2021 at 09:56:09AM +0200, Paolo Bonzini wrote:
> > >
>
On Tue, Jun 08, 2021 at 10:53:02AM +1000, David Gibson wrote:
> On Thu, Jun 03, 2021 at 08:52:24AM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 03, 2021 at 03:13:44PM +1000, David Gibson wrote:
> >
> > > > We can still consider it a single "address space" fro
On Tue, Jun 08, 2021 at 04:04:26PM +1000, David Gibson wrote:
> > What I would like is that the /dev/iommu side managing the IOASID
> > doesn't really care much, but the device driver has to tell
> > drivers/iommu what it is going to do when it attaches.
>
> By the device driver, do you mean the
On Wed, Jun 09, 2021 at 11:11:17AM +0200, Paolo Bonzini wrote:
> On 09/06/21 10:51, Enrico Weigelt, metux IT consult wrote:
> > On 08.06.21 21:00, Jason Gunthorpe wrote:
> >
> > > Eg I can do open() on a file and I get to keep that FD. I get to keep
> > > that FD
On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> Last unclosed open. Jason, you dislike symbol_get in this contract per
> earlier comment. As Alex explained, looks it's more about module
> dependency which is orthogonal to how this contract is designed. What
> is your opinion now?
G
On Wed, Jun 09, 2021 at 02:24:03PM +0200, Joerg Roedel wrote:
> On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> > - Device-centric (Jason) vs. group-centric (David) uAPI. David is not
> > fully
> > convinced yet. Based on discussion v2 will continue to have ioasid uAPI
> >
On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
> On 09/06/21 13:57, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 02:49:32AM +, Tian, Kevin wrote:
> >
> > > Last unclosed open. Jason, you dislike symbol_get in this contract per
> > > e
On Wed, Jun 09, 2021 at 03:24:11PM +0200, Paolo Bonzini wrote:
> On 09/06/21 14:47, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 02:46:05PM +0200, Paolo Bonzini wrote:
> > > On 09/06/21 13:57, Jason Gunthorpe wrote:
> > > > On Wed, Jun 09, 2021 at 02:49
On Wed, Jun 09, 2021 at 08:31:34AM -0600, Alex Williamson wrote:
> If we go back to the wbinvd ioctl mechanism, if I call that ioctl with
> an ioasidfd that contains no devices, then I shouldn't be able to
> generate a wbinvd on the processor, right? If I add a device,
> especially in a configura
On Wed, Jun 09, 2021 at 03:32:34PM +0200, Joerg Roedel wrote:
> > The group is causing all this mess because the group knows nothing
> > about what the device drivers contained in the group actually want.
>
> There are devices in the group, not drivers.
Well exactly, that is the whole problem.
On Wed, Jun 09, 2021 at 10:27:22AM -0600, Alex Williamson wrote:
> > > It is a kernel decision, because a fundamental task of the kernel is to
> > > ensure isolation between user-space tasks as good as it can. And if a
> > > device assigned to one task can interfer with a device of another task
>
On Thu, Jun 10, 2021 at 10:00:01AM +0800, Jason Wang wrote:
>
> 在 2021/6/8 下午9:20, Jason Gunthorpe 写道:
> > On Tue, Jun 08, 2021 at 09:10:42AM +0800, Jason Wang wrote:
> >
> > > Well, this sounds like a re-invention of io_uring which has already worked
> > > f
On Thu, Jun 10, 2021 at 09:38:42AM -0600, Alex Williamson wrote:
> Opening the group is not the extent of the security check currently
> required, the group must be added to a container and an IOMMU model
> configured for the container *before* the user can get a devicefd.
> Each devicefd creates
On Fri, Jun 11, 2021 at 01:38:28PM -0600, Alex Williamson wrote:
> That's fine for a serial port, but not a device that can do DMA.
> The entire point of vfio is to try to provide secure, DMA capable
> userspace drivers. If we relax enforcement of that isolation we've
> failed.
I don't understan
On Mon, Jun 14, 2021 at 03:09:31AM +, Tian, Kevin wrote:
> If a device can be always blocked from accessing memory in the IOMMU
> before it's bound to a driver or more specifically before the driver
> moves it to a new security context, then there is no need for VFIO
> to track whether IOASIDf
On Sat, Jun 12, 2021 at 10:57:11AM -0600, Alex Williamson wrote:
> On Fri, 11 Jun 2021 22:28:46 -0300
> Jason Gunthorpe wrote:
>
> > On Fri, Jun 11, 2021 at 01:38:28PM -0600, Alex Williamson wrote:
> >
> > > That's fine for a serial port, but not a device that
On Mon, Jun 14, 2021 at 10:28:14AM -0600, Alex Williamson wrote:
> > To my mind it is these three things:
> >
> > 1. The device can only do DMA to memory put into its security context
>
> System memory or device memory, yes.
>
> Corollary: The IOMMU group defines the minimum set of devices wher
On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> Hi, Jason,
>
> > From: Jason Gunthorpe
> > Sent: Thursday, June 3, 2021 9:05 PM
> >
> > On Thu, Jun 03, 2021 at 06:39:30AM +, Tian, Kevin wrote:
> > > > > Two helper functio
On Tue, Jun 15, 2021 at 10:59:06PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, June 15, 2021 11:07 PM
> >
> > On Tue, Jun 15, 2021 at 08:59:25AM +, Tian, Kevin wrote:
> > > Hi, Jason,
> > >
> > > > From: Jason
On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> which information can you elaborate? This is the area which I'm not
> familiar with thus would appreciate if you can help explain how this
> bus specific information is utilized within the attach function or
> sometime later.
This is
On Tue, Jun 15, 2021 at 11:56:28PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, June 16, 2021 7:41 AM
> >
> > On Tue, Jun 15, 2021 at 11:09:37PM +, Tian, Kevin wrote:
> >
> > > which information can you elaborate? This i
On Thu, Jun 17, 2021 at 03:02:33PM +1000, David Gibson wrote:
> In other words, do we really have use cases where we need to identify
> different devices IDs, even though we know they're not isolated.
I think when PASID is added in and all the complexity that brings, it
does become more important
On Thu, Jun 17, 2021 at 02:45:46PM +1000, David Gibson wrote:
> On Wed, Jun 09, 2021 at 09:39:19AM -0300, Jason Gunthorpe wrote:
> > On Wed, Jun 09, 2021 at 02:24:03PM +0200, Joerg Roedel wrote:
> > > On Mon, Jun 07, 2021 at 02:58:18AM +, Tian, Kevin wrote:
> > >
On Tue, Jun 15, 2021 at 10:12:15AM -0600, Alex Williamson wrote:
>
> 1) A dual-function PCIe e1000e NIC where the functions are grouped
>together due to ACS isolation issues.
>
>a) Initial state: functions 0 & 1 are both bound to e1000e driver.
>
>b) Admin uses driverctl to bind func
On Thu, Jun 17, 2021 at 03:14:52PM -0600, Alex Williamson wrote:
> I've referred to this as a limitation of type1, that we can't put
> devices within the same group into different address spaces, such as
> behind separate vRoot-Ports in a vIOMMU config, but really, who cares?
> As isolation suppor
On Thu, Jun 17, 2021 at 07:31:03AM +, Tian, Kevin wrote:
> > > Yes. function 1 is block-DMA while function 0 still attached to IOASID.
> > > Actually unbind from IOMMU fd doesn't change the security context.
> > > the change is conducted when attaching/detaching device to/from an
> > > IOASID.
On Fri, Jun 18, 2021 at 03:47:51PM +0200, Joerg Roedel wrote:
> Hi Kevin,
>
> On Thu, Jun 17, 2021 at 07:31:03AM +, Tian, Kevin wrote:
> > Now let's talk about the new IOMMU behavior:
> >
> > - A device is blocked from doing DMA to any resource outside of
> > its group when it's probed
On Fri, Jun 18, 2021 at 04:57:40PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Friday, June 18, 2021 8:20 AM
> >
> > On Thu, Jun 17, 2021 at 03:14:52PM -0600, Alex Williamson wrote:
> >
> > > I've referred to this as a limitati
On Fri, Jun 18, 2021 at 07:03:31PM +0200, Jean-Philippe Brucker wrote:
> configuration. The Arm SMMUs have a lot of small features that
> implementations can mix and match and that a user shouldn't have to care
> about, and there are lots of different implementations by various
> vendors.
This is
On Thu, Jun 24, 2021 at 02:29:29PM +1000, David Gibson wrote:
> But as I keep saying, some forms of grouping (and DMA aliasing as Alex
> mentioned) mean that changing the domain of one device can change the
> domain of another device, unavoidably. It may be rare with modern
> hardware, but we sti
On Thu, Jun 24, 2021 at 02:37:31PM +1000, David Gibson wrote:
> On Thu, Jun 17, 2021 at 08:04:38PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jun 17, 2021 at 03:02:33PM +1000, David Gibson wrote:
> >
> > > In other words, do we really have use cases where we need to
On Fri, Jun 25, 2021 at 10:27:18AM +, Tian, Kevin wrote:
> - When receiving the binding call for the 1st device in a group, iommu_fd
> calls iommu_group_set_block_dma(group, dev->driver) which does
> several things:
The whole problem here is trying to match this new world where we
On Mon, Jun 28, 2021 at 02:03:56AM +, Tian, Kevin wrote:
> Combining with the last paragraph above, are you actually suggesting
> that 1:1 group (including mdev) should use a new device-centric vfio
> uAPI (without group fd) while existing group-centric vfio uAPI is only
> kept for 1:N grou
On Mon, Jun 28, 2021 at 06:45:23AM +, Tian, Kevin wrote:
> 7) Unbinding detaches the device from the block_dma domain and
>re-attach it to the default domain. From now on the user should
>be denied from accessing the device. vfio should tear down the
>MMIO mapping at
On Mon, Jun 28, 2021 at 04:31:45PM -0600, Alex Williamson wrote:
> I'd expect that /dev/iommu will be used by multiple subsystems. All
> will want to bind devices to address spaces, so shouldn't binding a
> device to an iommufd be an ioctl on the iommufd, ie.
> IOMMU_BIND_VFIO_DEVICE_FD. Maybe w
On Mon, Jun 28, 2021 at 05:09:02PM -0600, Alex Williamson wrote:
> On Mon, 28 Jun 2021 19:48:18 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Jun 28, 2021 at 04:31:45PM -0600, Alex Williamson wrote:
> >
> > > I'd expect that /dev/iommu will be used by multiple
On Mon, Jul 05, 2021 at 02:47:36PM +0100, Robin Murphy wrote:
> On 2021-07-05 11:23, Dan Carpenter wrote:
> > [ Ancient code, but the bug seems real enough still. -dan ]
> >
> > Hello Upinder Malhi,
> >
> > The patch e3cf00d0a87f: "IB/usnic: Add Cisco VIC low-level hardware
> > driver" from Sep
On Mon, Jul 12, 2021 at 11:56:24PM +, Tian, Kevin wrote:
> Maybe I misunderstood your question. Are you specifically worried
> about establishing the security context for a mdev vs. for its
> parent?
The way to think about the cookie, and the device bind/attach in
general, is as taking contro
On Tue, Jul 13, 2021 at 10:26:07AM -0600, Alex Williamson wrote:
> Quoting this proposal again:
>
> > 1) A successful binding call for the first device in the group creates
> > the security context for the entire group, by:
> >
> > * Verifying group viability in a similar way as VFIO do
On Tue, Jul 13, 2021 at 10:48:38PM +, Tian, Kevin wrote:
> We can still bind to the parent with cookie, but with
> iommu_register_ sw_device() IOMMU fd knows that this binding doesn't
> need to establish any security context via IOMMU API.
AFAIK there is no reason to involve the parent PCI or
On Tue, Jul 13, 2021 at 11:20:12PM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, July 14, 2021 7:03 AM
> >
> > On Tue, Jul 13, 2021 at 10:48:38PM +, Tian, Kevin wrote:
> >
> > > We can still bind to the parent with cookie, b
On Fri, Aug 27, 2021 at 09:28:37AM -0400, Ross Philipson wrote:
> The Secure Launch MLE environment uses PCRs that are only accessible from
> the DRTM locality 2. By default the TPM drivers always initialize the
> locality to 0. When a Secure Launch is in progress, initialize the
> locality to 2.
>
On Mon, Sep 14, 2020 at 10:38:10AM +, Tian, Kevin wrote:
> is widely used thus can better help verify the core logic with
> many existing devices. For vSVA, vDPA support has not be started
> while VFIO support is close to be accepted. It doesn't make much
> sense by blocking the VFIO part unti
On Mon, Sep 14, 2020 at 03:31:13PM +0200, Jean-Philippe Brucker wrote:
> > Jason suggest something like /dev/sva. There will be a lot of other
> > subsystems that could benefit from this (e.g vDPA).
>
> Do you have a more precise idea of the interface /dev/sva would provide,
> how it would intera
On Mon, Sep 14, 2020 at 09:22:47AM -0700, Raj, Ashok wrote:
> Hi Jason,
>
> On Mon, Sep 14, 2020 at 10:47:38AM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 14, 2020 at 03:31:13PM +0200, Jean-Philippe Brucker wrote:
> >
> > > > Jason suggest something like /dev/
On Mon, Sep 14, 2020 at 10:58:57AM -0600, Alex Williamson wrote:
> "its own special way" is arguable, VFIO is just making use of what's
> being proposed as the uapi via its existing IOMMU interface.
I mean, if we have a /dev/sva then it makes no sense to extend the
VFIO interfaces with the same
On Mon, Sep 14, 2020 at 12:23:28PM -0600, Alex Williamson wrote:
> On Mon, 14 Sep 2020 14:41:21 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Sep 14, 2020 at 10:58:57AM -0600, Alex Williamson wrote:
> >
> > > "its own special way" is arguable, VFIO
On Mon, Sep 14, 2020 at 03:44:38PM -0700, Raj, Ashok wrote:
> Hi Jason,
>
> I thought we discussed this at LPC, but still seems to be going in
> circles :-(.
We discused mdev at LPC, not PASID.
PASID applies widely to many device and needs to be introduced with a
wide community agreement so all
On Mon, Sep 14, 2020 at 04:33:10PM -0600, Alex Williamson wrote:
> Can you explain that further, or spit-ball what you think this /dev/sva
> interface looks like and how a user might interact between vfio and
> this new interface?
When you open it you get some container, inside the container the
On Tue, Sep 15, 2020 at 11:11:54AM -0700, Raj, Ashok wrote:
> > PASID applies widely to many device and needs to be introduced with a
> > wide community agreement so all scenarios will be supportable.
>
> True, reading some of the earlier replies I was clearly confused as I
> thought you were talk
On Tue, Sep 15, 2020 at 12:26:32PM -0700, Raj, Ashok wrote:
> > Yes, there is. There is a limited pool of HW PASID's. If one user fork
> > bombs it can easially claim an unreasonable number from that pool as
> > each process will claim a PASID. That can DOS the rest of the system.
>
> Not sure ho
On Tue, Sep 15, 2020 at 03:08:51PM -0700, Jacob Pan wrote:
> > A PASID vIOMMU solution sharable with VDPA and VFIO, based on a PASID
> > control char dev (eg /dev/sva, or maybe /dev/iommu) seems like a
> > reasonable starting point for discussion.
>
> I am not sure what can really be consolidated
On Wed, Sep 16, 2020 at 01:19:18AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, September 15, 2020 10:29 PM
> >
> > > Do they need a device at all? It's not clear to me why RID based
> > > IOMMU management fits within vfio'
On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote:
> And this is the only PASID model for Arm SMMU (and AMD IOMMU, I believe):
> the PASID space of a PCI function cannot be shared between host and guest,
> so we assign the whole PASID table along with the RID. Since we need the
On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote:
> > If user space wants to bind page tables, create the PASID with
> > /dev/sva, use ioctls there to setup the page table the way it wants,
> > then pass the now configured PASID to a driver that can use it.
>
> Are we talking about
On Wed, Sep 16, 2020 at 06:20:52PM +0200, Jean-Philippe Brucker wrote:
> On Wed, Sep 16, 2020 at 11:51:48AM -0300, Jason Gunthorpe wrote:
> > On Wed, Sep 16, 2020 at 10:32:17AM +0200, Jean-Philippe Brucker wrote:
> > > And this is the only PASID model for Arm SMMU (and AM
On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote:
> On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 15, 2020 at 05:22:26PM -0700, Jacob Pan (Jun) wrote:
> > > > If user space wants to bind page tables, create the PASID with
> &g
On Wed, Sep 16, 2020 at 11:21:10AM -0700, Jacob Pan (Jun) wrote:
> Hi Jason,
> On Wed, 16 Sep 2020 14:01:13 -0300, Jason Gunthorpe
> wrote:
>
> > On Wed, Sep 16, 2020 at 09:33:43AM -0700, Raj, Ashok wrote:
> > > On Wed, Sep 16, 2020 at 12:07:54PM -0300, Jason Guntho
On Thu, Sep 17, 2020 at 11:53:49AM +0800, Jason Wang wrote:
> > > When VDPA is used by qemu it makes sense that the PASID will be an
> > > arbitary IOVA map constructed to be 1:1 with the guest vCPU physical
> > > map. /dev/sva allows a single uAPI to do this kind of setup, and qemu
> > > can suppo
On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote:
> On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> > On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
> >> #9 is obviously just for the folks interested in IMS
> >>
> >
> > I see that the tip tree (as of 9/29) has most of these patches bu
On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> Hi Jason
>
> On Mon, 2020-08-31 at 11:39 -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 26, 2020 at 01:16:52PM +0200, Thomas Gleixner wrote:
> > > From: Thomas Gleixner
> > >
> > > De
On Wed, Sep 30, 2020 at 01:08:27PM +, Derrick, Jonathan wrote:
> +Megha
>
> On Wed, 2020-09-30 at 09:57 -0300, Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 12:45:30PM +, Derrick, Jonathan wrote:
> > > Hi Jason
> > >
> > > On Mon, 2020-0
On Wed, Oct 14, 2020 at 03:16:22AM +, Tian, Kevin wrote:
> Hi, Alex and Jason (G),
>
> How about your opinion for this new proposal? For now looks both
> Jason (W) and Jean are OK with this direction and more discussions
> are possibly required for the new /dev/ioasid interface. Internally
>
On Mon, Oct 19, 2020 at 08:39:03AM +, Liu, Yi L wrote:
> Hi Jason,
>
> Good to see your response.
Ah, I was away
> > > > Second, IOMMU nested translation is a per IOMMU domain
> > > > capability. Since IOMMU domains are managed by VFIO/VDPA
> > > > (alloc/free domain, attach/detach device,
On Tue, Oct 20, 2020 at 09:40:14AM +, Liu, Yi L wrote:
> > See previous discussion with Kevin. If I understand correctly, you expect a
> > shared
> > L2 table if vDPA and VFIO device are using the same PASID.
>
> L2 table sharing is not mandatory. The mapping is the same, but no need to
> as
On Tue, Oct 20, 2020 at 10:21:41AM +, Liu, Yi L wrote:
> > I'm sure there will be some
> > weird overlaps because we can't delete any of the existing VFIO APIs, but
> > that
> > should not be a blocker.
>
> but the weird thing is what we should consider. And it perhaps not just
> overlap, it
On Tue, Oct 20, 2020 at 02:00:31PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, October 20, 2020 9:55 PM
> >
> > On Tue, Oct 20, 2020 at 09:40:14AM +, Liu, Yi L wrote:
> >
> > > > See previous discussion with Kevin. If I u
On Tue, Oct 20, 2020 at 09:24:30AM -0700, Raj, Ashok wrote:
> Hi Jason,
>
>
> On Tue, Oct 20, 2020 at 11:02:17AM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 20, 2020 at 10:21:41AM +, Liu, Yi L wrote:
> >
> > > > I'm sure there will be some
>
On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote:
> I think we agreed (or agree to disagree and commit) for device types that
> we have for SIOV, VFIO based approach works well without having to re-invent
> another way to do the same things. Not looking for a shortcut by any means,
> b
On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
> On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 20, 2020 at 12:51:46PM -0700, Raj, Ashok wrote:
> > > I think we agreed (or agree to disagree and commit) for device types that
>
On Tue, Oct 20, 2020 at 01:27:13PM -0700, Raj, Ashok wrote:
> On Tue, Oct 20, 2020 at 05:14:03PM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 20, 2020 at 01:08:44PM -0700, Raj, Ashok wrote:
> > > On Tue, Oct 20, 2020 at 04:55:57PM -0300, Jason Gunthorpe wrote:
> > > &
On Wed, Oct 21, 2020 at 10:51:46AM -0700, Raj, Ashok wrote:
> > If they didn't plan to use it, bit of a strawman argument, right?
>
> This doesn't need to continue like the debates :-) Pun intended :-)
>
> I don't think it makes any sense to have an abstract strawman argument
> design discussion
On Wed, Oct 21, 2020 at 01:03:15PM -0700, Raj, Ashok wrote:
> I'm not sure why you tie in IDXD and VDPA here. How IDXD uses native
> SVM is orthogonal to how we achieve mdev passthrough to guest and
> vSVM.
Everyone assumes that vIOMMU and SIOV aka PASID is going to be needed
on the VDPA side as
On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> So having said this, what is the benefit of exposing those SVA internals
> to user-space?
Only the device use of the PASID is device specific, the actual PASID
and everything on the IOMMU side is generic.
There is enough API there
On Tue, Nov 03, 2020 at 02:18:52PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 08:56:43AM -0400, Jason Gunthorpe wrote:
> > On Tue, Nov 03, 2020 at 10:52:09AM +0100, j...@8bytes.org wrote:
> > > So having said this, what is the benefit of exposing those SVA inter
On Tue, Nov 03, 2020 at 03:03:18PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 09:23:35AM -0400, Jason Gunthorpe wrote:
> > Userspace needs fine grained control over the composition of the page
> > table behind the PASID, 1:1 with the mm_struct is only one use case.
&g
On Tue, Nov 03, 2020 at 03:35:32PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 10:06:42AM -0400, Jason Gunthorpe wrote:
> > The point is that other places beyond VFIO need this
>
> Which and why?
>
> > Sure, but sometimes it is necessary, and in those cases
On Tue, Nov 03, 2020 at 05:55:40PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 11:22:23AM -0400, Jason Gunthorpe wrote:
> > This whole thread was brought up by IDXD which has a SVA driver and
> > now wants to add a vfio-mdev driver too. SVA devices that want to be
>
On Wed, Nov 04, 2020 at 10:50:49AM +0100, Christoph Hellwig wrote:
> +int ib_dma_virt_map_sg(struct ib_device *dev, struct scatterlist *sg, int
> nents)
> +{
> + struct scatterlist *s;
> + int i;
> +
> + for_each_sg(sg, s, nents, i) {
> + sg_dma_address(s) = (uintptr_t)sg_
On Wed, Nov 04, 2020 at 03:01:08PM +0100, Christoph Hellwig wrote:
> > Sigh. I think the proper fix is to replace addr/length with a
> > scatterlist pointer in the struct ib_sge, then have SW drivers
> > directly use the page pointer properly.
>
> The proper fix is to move the DMA mapping into th
On Wed, Nov 04, 2020 at 05:31:35PM +0100, Christoph Hellwig wrote:
> On Wed, Nov 04, 2020 at 11:52:55AM -0400, Jason Gunthorpe wrote:
> > It could work, I think a resonable ULP API would be to have some
> >
> > rdma_fill_ib_sge_from_sgl()
> > rdma_map_sge_single
On Wed, Nov 04, 2020 at 03:09:04PM +, Bernard Metzler wrote:
> lkey of zero to pass a physical buffer, only allowed for
> kernel applications? Very nice idea I think.
It already exists, it is called the local_dma_lkey, just set
IB_DEVICE_LOCAL_DMA_LKEY and provide the value you want to use
in
On Tue, Nov 03, 2020 at 08:14:29PM +0100, j...@8bytes.org wrote:
> On Tue, Nov 03, 2020 at 01:48:51PM -0400, Jason Gunthorpe wrote:
> > I think the same PCI driver with a small flag to support the PF or
> > VF is not the same as two completely different drivers in different
On Thu, Nov 05, 2020 at 08:42:02AM +0100, Christoph Hellwig wrote:
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index 5f8fd7976034e0..661e4a22b3cb81 100644
> +++ b/include/rdma/ib_verbs.h
> @@ -3950,6 +3950,8 @@ static inline int ib_req_ncomp_notif(struct ib_cq *cq,
> int wc_
On Thu, Nov 05, 2020 at 08:42:03AM +0100, Christoph Hellwig wrote:
> Now that all users of dma_virt_ops are gone we can remove the workaround
> for it in the PCI peer to peer code.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Logan Gunthorpe
> Acked-by: Bjorn Helgaas
> drivers/pci/p2pdm
On Thu, Nov 05, 2020 at 08:42:00AM +0100, Christoph Hellwig wrote:
> dma_virt_ops requires that all pages have a kernel virtual address.
> Introduce a INFINIBAND_VIRT_DMA Kconfig symbol that depends on !HIGHMEM
> and a large enough dma_addr_t, and make all three driver depend on the
> new symbol.
>
On Thu, Nov 05, 2020 at 06:08:16PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 05, 2020 at 10:34:18AM -0400, Jason Gunthorpe wrote:
> > The check is removed here, but I didn't see a matching check added to
> > the IB side? Something like:
> >
> > static int rdma
On Thu, Nov 05, 2020 at 06:29:21PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 05, 2020 at 01:23:57PM -0400, Jason Gunthorpe wrote:
> > But that depends on the calling driver doing this properly, and we
> > don't expose an API to get the PCI device of the struct ib_device
On Thu, Nov 05, 2020 at 08:42:02AM +0100, Christoph Hellwig wrote:
> @@ -1341,7 +1322,14 @@ int ib_register_device(struct ib_device *device, const
> char *name,
> if (ret)
> return ret;
>
> - setup_dma_device(device, dma_device);
> + /*
> + * If the caller does n
On Thu, Nov 05, 2020 at 06:43:06PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 05, 2020 at 01:39:30PM -0400, Jason Gunthorpe wrote:
> > Hmm. This works for real devices like mlx5, but it means the three SW
> > devices will also resolve to a real PCI device that is not the
301 - 400 of 1012 matches
Mail list logo
