On Thu, Dec 08, 2022 at 06:37:42PM -0500, Matthew Rosato wrote: > On 12/8/22 3:26 PM, Jason Gunthorpe wrote: > > > - S390 has unconditionally claimed it has secure MSI through the iommu > > driver. I'm not sure how it works, or if it even does. Perhaps > > zpci_set_airq() pushes the "zdev->gias" to the hypervisor which > > limits a device's MSI to only certain KVM contexts (though if true > > this would be considered insecure by VFIO) > > > > There are a few layers here. Interrupt isolation and mapping on > s390 is accomplished via a mapping table used by a layer of firmware > (and can be shared by a hypervisor e.g. qemu/kvm) that sits between > the device and the kernel/driver (s390 linux always runs on at least > this 'bare-metal hypervisor' firmware layer). Indeed the initial > relationship is established via zpci_set_airq -- the "zdev->fh" > identifies the device, the "zdev->gisa" (if applicable) identifies > the single KVM context that is eligible to receive interrupts > related to the specified device as well as the single KVM context > allowed to access the device via any zPCI instructions (e.g. config > space access). The aibv/noi indicate the vector mappings that are > authorized for that device; firmware will typically route the > interrupts to the guest without hypervisor involvement once this is > established, but the table is shared by the hypervisor so that it > can be tapped to complete delivery when necessary. This > registration process enables a firmware intermediary that will only > pass along MSI from the device that has an associated, > previously-authorized vector, associated with either the 'bare-metal > hypervisor' (gisa = 0) and/or a specific VM (gisa != 0), depending > what was registered as zpci_set_airq. I suspected something like this - it technically isn't the same "secure msi" thing since a VFIO userspace with no KVM can trigger bogus MSIs against the kernel. But it has been this way for a long time, let's just document it and leave it be. Jason
