linux-kernel - RE: [RFC PATCH 2/3] vfio/ims: Support emulated interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN9PR11MB5276D9778C48BD2FD73CE9658CE3A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Fri, 25 Aug 2023 03:05:52 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     "Chatre, Reinette" <reinette.chatre@...el.com>,
        Jason Gunthorpe <jgg@...dia.com>
CC:     "yishaih@...dia.com" <yishaih@...dia.com>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        "tom.zanussi@...ux.intel.com" <tom.zanussi@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 2/3] vfio/ims: Support emulated interrupts

> From: Chatre, Reinette <reinette.chatre@...el.com>
> Sent: Friday, August 25, 2023 1:19 AM
> 
> Hi Jason,
> 
> On 8/24/2023 9:33 AM, Jason Gunthorpe wrote:
> > On Thu, Aug 24, 2023 at 09:15:21AM -0700, Reinette Chatre wrote:
> >> Access from a guest to a virtual device may be either 'direct-path',
> >> where the guest interacts directly with the underlying hardware,
> >> or 'intercepted path' where the virtual device emulates operations.
> >>
> >> Support emulated interrupts that can be used to handle 'intercepted
> >> path' operations. For example, a virtual device may use 'intercepted
> >> path' for configuration. Doing so, configuration requests intercepted
> >> by the virtual device driver are handled within the virtual device
> >> driver with completion signaled to the guest without interacting with
> >> the underlying hardware.
> >
> > Why does this have anything to do with IMS? I thought the point here
> > was that IMS was some back end to the MSI-X emulation - should a
> > purely emulated interrupt logically be part of the MSI code, not IMS?
> 
> You are correct, an emulated interrupt is not unique to IMS.
> 
> The target usage of this library is by pure(?) VFIO devices (struct
> vfio_device). These are virtual devices that are composed by separate
> VFIO drivers. For example, a single resource of an accelerator device
> can be composed into a stand-alone virtual device for use by a guest.
> 
> Through its API and implementation the current VFIO MSI
> code expects to work with actual PCI devices (struct
> vfio_pci_core_device). With the target usage not being an
> actual PCI device the VFIO MSI code was not found to be a good
> fit and thus this implementation does not build on current MSI
> support.
> 

This might be achieved by creating a structure vfio_pci_intr_ctx
included by vfio_pci_core_device and other vfio device types. Then
move vfio_pci_intr.c to operate on vfio_pci_intr_ctx instead of
vfio_pci_core_device to make MSI frontend code sharable by both
PCI devices or virtual devices (mdev or SIOV).

Then there is only one irq_ctx. Within the ctx we can abstract
backend ops, e.g. enable/disble_msi(), alloc/free_ctx(), alloc/free_irq(), etc.
to accommodate pci MSI/MSI-X, IMS, or emulation.

The unknown risk is whether a clear abstraction can be defined. If
in the end the common library contains many if-else to handle subtle
backend differences then it might not be a good choice...