- The session covers the basics of the Input/Output Memory Management Unit (IOMMU) and virtual IOMMU, and why there is a need for a new secure data transfer model.
- The IOMMU is a hardware unit that handles I/O translation and device isolation. A virtual IOMMU acts like a real one.
- The current data transfer model involves exposing the entire guest memory address space to the driver, which could potentially be exploited by malicious programs.
- This is why there is a need for a new secure data transfer model.
- The new secure data transfer model introduces an IOMMU to the guest.
- This effectively switches the guest physical address to an I/O virtual address, which can be achieved using DMA API in the guest kernel.
- However, this model introduces a new concern - the increase in overhead from the QEMU, which could impact system performance.
- A further optimization is introduced to address the performance impact with the Address Translation Services (ATS).
- ATS is a PCI SIG specification that allows a specific PCIe device to synchronize its IOTLB entries with IOMMU, enabling direct memory access without interference from IOMMU.
- Interrupt remapping is also covered, which provides protection against malicious interrupts.
- Two types of interrupts are used in x86 systems, line-based interrupts and signal-based interrupts.
- Interrupt remapping involves interrupt remapping hardware (IRH), which is able to trap and report malicious interrupts.
- This is achieved by supporting two types of interrupts and emulating certain chipsets.
- Making interrupt remapping faster involves supporting the Virtual Advanced Programmable Interrupt Controller (vAPIC) and Virtual I/O APIC (vIOAPIC).
- This is achieved by having an interrupt cache inside the kernel.# Overview
- The translation is slightly different from the email related one.
- For this, we translate on the fly. For example, if there is an interrupt generated, we translate and deliver.
- For the VA pick support, we cache the translated result into the GI side routing table which is quicker.
- We do the translation beforehand, so when the interrupt is triggered, we do not need to translate it at all.
- The full colonel microchip support cannot be supported because we cannot trap it in Kumu.
- However, split is quite okay for us because for one thing it is fast and for the other thing it is safer.
- This is done based on GI side routing table.
- We set up routing table first, set up our QFT and everything works.
- Q is responsible to set up everything, set up the V host back-end, set up GSI routing table and insert every MSN messages.
- When the interrupt comes, we just got an event which is an interrupt to be host.
- The whole work is for deep DK and the BTK only, mostly for static DMA mapping DB decay trees DMA addresses.
- For TBD k case, our work works quite well. We get safety and we drop 5% performance.
- For dynamic DMA mapping, the performance is dramatically worse.
- Most of the patches emerged upstream except recent ones.
- There are still lots of works to be done.
- For dynamic DMA mapping, the performance needs to be improved.
- For the full colonel microchip support, a solution to trap it in Kumu needs to be found.