lkml.org 
[lkml]   [2021]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 05/20] vfio: mdev: common lib code for setting up Interrupt Message Store
    On Tue, Jun 08, 2021 at 08:57:35AM -0700, Dave Jiang wrote:

    > In order to ensure unprivileged software doesn’t use a handle that
    > doesn’t belong to it, DSA provides a facility for system software to
    > associate a PASID with an interrupt handle, and DSA will ensure the
    > entity submitting the work is authorized to generate interrupt via
    > this interrupt handle (PASID stored in IMS array should match PASID
    > in descriptor).

    How does a SVA userspace allocate interrupt handles and make them
    affine to the proper CPU(s)?

    IIRC interrupts are quite limited per-CPU due to the x86 IDT,
    generally I would expect a kernel driver to allocate at most one IRQ
    per CPU.

    However here you say each process using SVA needs a unique interrupt
    handle with its PASID encoded in it. Since the IMS irqchip you are
    using can't share IRQs between interrupt handles does this mean that
    every time userspace creates a SVA it triggers consumption of an IMS
    and IDT entry on some CPU? How is this secure against DOS of limited
    kernel resources?

    > driver does this by having the guest driver fill the virtual MSIX
    > permission table (device specific), which contains a PASID entry for
    > each of the MSIX vectors when SVA is turned on. The MMIO write to
    > the guest vMSIXPERM table allows the host driver MMIO emulation code
    > to retrieve the guest PASID and attempt to match that with the host
    > PASID. That host PASID is programmed to the IMS entry that is
    > backing the guest MSIX vector. This cannot be done via the common
    > path and therefore requires the auxdata helper function to program
    > the IMS PASID fields.

    So a VM guest gets a SW emulated vMSIXPERM table along side MSI-X, but
    the physical driver went down this IMS adventure?

    And you had to do this because, as discussed earlier, true IMS is not
    usable in the guest due to other platform problems?

    Jason

    \
     
     \ /
      Last update: 2021-06-08 19:22    [W:2.858 / U:0.768 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site