lkml.org 
[lkml]   [2023]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 09/12] iommu/vt-d: Add iotlb flush for nested domain
    On Fri, Aug 11, 2023 at 03:52:52AM +0000, Tian, Kevin wrote:

    > > From: Nicolin Chen <nicolinc@nvidia.com>
    > > Sent: Friday, August 11, 2023 5:03 AM
    > >
    > > > > > Is there a use case for invaliation only SW emulated rings, and do we
    > > > > > care about optimizing for the wrap around case?
    > > > >
    > > > > Hmm, why a SW emulated ring?
    > > >
    > > > That is what you are building. The VMM catches the write of the
    > > > producer pointer and the VMM SW bundles it up to call into the kernel.
    > >
    > > Still not fully getting it. Do you mean a ring that is prepared
    > > by the VMM? I think the only case that we need to handle a ring
    > > is what I did by forwarding the guest CMDQ (a ring) to the host
    > > directly. Not sure why VMM would need another ring for those
    > > linearized invalidation commands. Or maybe I misunderstood..
    > >
    >
    > iiuc the point of a ring-based native format is to maximum code reuse
    > when later in-kernel fast invalidation path (from kvm to smmu driver)
    > is enabled. Then both slow (via vmm) and fast (in-kernel) path use
    > the same logic to handle guest invalidation queue.

    I see. That's about the fast path topic. Thanks for the input.

    > But if stepping back a bit supporting an array-based non-native format
    > could simplify the uAPI design and allows code sharing for array among
    > vendor drivers. You can still keep the entry as native format then the
    > only difference with future in-kernel fast path is just on walking an array
    > vs. walking a ring. And VMM doesn't need to expose non-invalidate
    > cmds to the kernel and then be skipped.

    Ah, so we might still design the uAPI to be ring based at this
    moment, yet don't support a case CONS > 0 to leave that to an
    upgrade in the future.

    I will try estimating a bit how complicated to implement the
    ring, to see if we could just start with that. Otherwise, will
    just start with an array.

    Thanks
    Nic

    \
     
     \ /
      Last update: 2023-08-11 18:46    [W:5.194 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site