Joerg Roedel
2020-Mar-03 15:53 UTC
[PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
On Tue, Mar 03, 2020 at 09:00:05AM -0500, Michael S. Tsirkin wrote:> Not necessarily. E.g. some power systems have neither. > There are also systems looking to bypass ACPI e.g. for boot speed.If there is no firmware layer between the hardware and the OS the necessary information the OS needs to run on the hardware is probably hard-coded into the kernel? In that case the same can be done with virtio-iommu tolopology.> That sentence doesn't really answer the question, does it?To be more elaborate, putting this information into config space is a layering violation. Hardware is never completly self-descriptive and that is why there is the firmware which provides the information about the hardware to the OS in a generic way.> Frankly with platform specific interfaces like ACPI, virtio-iommu is > much less compelling. Describing topology as part of the device in a > way that is first, portable, and second, is a good fit for hypervisors, > is to me one of the main reasons virtio-iommu makes sense at all.Virtio-IOMMU makes sense in the first place because it is much faster than emulating one of the hardware IOMMUs. And an ACPI table is also portable to all ACPI platforms, same with device-tree. Regards, Joerg
Michael S. Tsirkin
2020-Mar-03 16:09 UTC
[PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
On Tue, Mar 03, 2020 at 04:53:19PM +0100, Joerg Roedel wrote:> On Tue, Mar 03, 2020 at 09:00:05AM -0500, Michael S. Tsirkin wrote: > > Not necessarily. E.g. some power systems have neither. > > There are also systems looking to bypass ACPI e.g. for boot speed. > > If there is no firmware layer between the hardware and the OS the > necessary information the OS needs to run on the hardware is probably > hard-coded into the kernel?No. It's coded into the hardware. Which might even be practical for bare-metal (e.g. on-board flash), but is very practical when the device is part of a hypervisor.> In that case the same can be done with > virtio-iommu tolopology. > > > That sentence doesn't really answer the question, does it? > > To be more elaborate, putting this information into config space is a > layering violation. Hardware is never completly self-descriptiveThis "hardware" is actually part of hypervisor so there's no reason it can't be completely self-descriptive. It's specified by the same entity as the "firmware".> and > that is why there is the firmware which provides the information about > the hardware to the OS in a generic way. > > > Frankly with platform specific interfaces like ACPI, virtio-iommu is > > much less compelling. Describing topology as part of the device in a > > way that is first, portable, and second, is a good fit for hypervisors, > > is to me one of the main reasons virtio-iommu makes sense at all. > > Virtio-IOMMU makes sense in the first place because it is much faster > than emulating one of the hardware IOMMUs.I don't see why it would be much faster. The interface isn't that different from command queues of VTD.> And an ACPI table is also > portable to all ACPI platforms, same with device-tree. > > Regards, > > JoergMaking ACPI meet the goals of embedded projects such as kata containers would be a gigantic task with huge stability implications. By comparison this 400-line parser is well contained and does the job. I didn't yet see compelling reasons not to merge this, but I'll be interested to see some more specific concerns. -- MST
Auger Eric
2020-Mar-03 16:21 UTC
[PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
Hi Michael, Joerg, On 3/3/20 5:09 PM, Michael S. Tsirkin wrote:> On Tue, Mar 03, 2020 at 04:53:19PM +0100, Joerg Roedel wrote: >> On Tue, Mar 03, 2020 at 09:00:05AM -0500, Michael S. Tsirkin wrote: >>> Not necessarily. E.g. some power systems have neither. >>> There are also systems looking to bypass ACPI e.g. for boot speed. >> >> If there is no firmware layer between the hardware and the OS the >> necessary information the OS needs to run on the hardware is probably >> hard-coded into the kernel? > > No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor. > >> In that case the same can be done with >> virtio-iommu tolopology. >> >>> That sentence doesn't really answer the question, does it? >> >> To be more elaborate, putting this information into config space is a >> layering violation. Hardware is never completly self-descriptive > > > This "hardware" is actually part of hypervisor so there's no > reason it can't be completely self-descriptive. It's specified > by the same entity as the "firmware".Yes in the QEMU case the machine code would fill this information as it knows all the devices connected to the iommu. In the same way it would generate the DT description or the ACPI tables> >> and >> that is why there is the firmware which provides the information about >> the hardware to the OS in a generic way. >> >>> Frankly with platform specific interfaces like ACPI, virtio-iommu is >>> much less compelling. Describing topology as part of the device in a >>> way that is first, portable, and second, is a good fit for hypervisors, >>> is to me one of the main reasons virtio-iommu makes sense at all. >> >> Virtio-IOMMU makes sense in the first place because it is much faster >> than emulating one of the hardware IOMMUs. > > I don't see why it would be much faster. The interface isn't that > different from command queues of VTD.> >> And an ACPI table is also >> portable to all ACPI platforms, same with device-tree. >> >> Regards, >> >> Joerg > > Making ACPI meet the goals of embedded projects such as kata containers > would be a gigantic task with huge stability implications. By > comparison this 400-line parser is well contained and does the job. I > didn't yet see compelling reasons not to merge this, but I'll be > interested to see some more specific concerns. > >Thanks Eric
Joerg Roedel
2020-Mar-04 13:37 UTC
[PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
Hi Michael, On Tue, Mar 03, 2020 at 11:09:41AM -0500, Michael S. Tsirkin wrote:> No. It's coded into the hardware. Which might even be practical > for bare-metal (e.g. on-board flash), but is very practical > when the device is part of a hypervisor.If its that way on PPC, than fine for them. But since this is enablement for x86, it should follow the x86 platform best practices, and that means describing hardware through ACPI.> This "hardware" is actually part of hypervisor so there's no > reason it can't be completely self-descriptive. It's specified > by the same entity as the "firmware".That is just an implementation detail. Yes, QEMU emulates the hardware and builds the ACPI tables. But it could also be implemented in a way where the ACPI tables are build by guest firmware.> I don't see why it would be much faster. The interface isn't that > different from command queues of VTD.VirtIO IOMMU doesn't need to build page-tables that the hypervisor then has to shadow, which makes things much faster. If you emulate one of the other IOMMUs (VT-d or AMD-Vi) the code has to shadow the full page-table at once when device passthrough is used. VirtIO-IOMMU doesn't need that, and that makes it much faster and efficient.> Making ACPI meet the goals of embedded projects such as kata containers > would be a gigantic task with huge stability implications. By > comparison this 400-line parser is well contained and does the job. I > didn't yet see compelling reasons not to merge this, but I'll be > interested to see some more specific concerns.An ACPI table parse wouldn't need more lines of code. For embedded systems there is still the DT way of describing things. Regards, Joerg
Joerg Roedel
2020-Mar-04 17:34 UTC
[PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
On Wed, Mar 04, 2020 at 07:48:54AM -0800, Jacob Pan wrote:> For emulated VT-d IOMMU, GIOVA can also be build as first level page > tables then pass to the host IOMMU to bind. There is no need to shadow > in this case, pIOMMU will do nested translation and walk guest page > tables.Right, but that requires hardware support. A pure software emulation of VT-d requires the full shadow of the guest io-page-table.> I thought we have the universal device properties to abstract DT and > ACPI (via _DSD). Is that an option?I don't know whether this was considered, Jean-Philippe? Regards, Joerg
Maybe Matching Threads
- [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
- [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
- [RFC 00/13] virtio-iommu on non-devicetree platforms
- [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space
- [PATCH v2 1/3] iommu/virtio: Add topology description to virtio-iommu config space