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
