On 3/22/22 11:19, Petr Pisar wrote: > V Tue, Mar 22, 2022 at 07:30:13AM -0400, Demi Marie Obenour napsal(a): >> All kernel-mode drivers, to be specific. User-mode drivers are an >> underutilized alternative for systems that have an IOMMU/SMMU. Obviously, >> the drivers still need to be free software for Fedora to package them, but >> user-mode drivers have the advantage of not running with kernel privilege. > > That smells like a microkernel :) That’s because almost all drivers on a microkernel work that way 🙂. Interrupt controller, IOMMU, and timer drivers are the main exceptions I know of. > I did not know it's possible. I can image > one can program IOMMU to direct all reads and writes by a device into a memory > mapped into a user-space process. But how can a user space process receive > interrupts? Is there an in-kernel translation layer which presents interrupts > to the user process somehow? There is; see ‘Documentation/driver-api/vfio.rst’ in the kernel source tree. To be clear: this is not an excuse for the driver being proprietary or of low quality, but rather a way to allow the driver to run as a deprivileged userspace process. > Or does it only work with the modern MSI-like > interrupts which are a ring buffer of messages in a shared memory? > > -- Petr On x86 I believe it only supports MSI interrupts, but for a different reason: old-style interrupts cannot be remapped, and so devices that can create them cannot safely be assigned to an untrusted principal (which a userspace driver is, from the kernel’s perspective). Specifically, I believe neither Xen nor Hyper-V support device passthrough for devices with old-style interrupts, and this is equivalent (from a security perspective) to VFIO. I do not know how this works on ARM. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
