Hi, > > Is there some simple way to figure what the iommu width is (inside the > > guest)? > > If the guest firmware is exposing a DMAR table (VT-d), there's a host > address width field in that table. Otherwise there are capability > registers on the DRHD units that could be queried. AMD-Vi seems to > have similar information in the IVinfo table linked from the IVRS > table. Maybe an iterative solution is ok, starting with the most > common IOMMU types and assuming others are 64-bits wide until proven > otherwise.
Hmm. The guest firmware simply exposes the tables it gets from qemu (without parsing it). Also the acpi tables are loaded after the firmware created the address space layout, because qemu adjusts them according to the programming done by the firmware (set pci bus ranges according to bridge windows etc). So checking ACPI tables for that information doesn't look very attractive. The firmware would have to load the tables twice (once early to parse DMAR, once late for the final tables). Going for the capability registers might be possible. Can the hardware be probed for safely? Has AMD capability registers too? Third option would be using another channel to communicate the information from qemu to firmware, where using 'guest-phys-bits' would be one candidate. > Right, as Cédric notes that's sort of what happens here, but my concern > was that the we're kind of incorrectly linking the cpu address width to > the platform address width, which isn't specifically the requirement. There is a separate 'guest-phys-bits' property for that reason. The phys-bits of the CPU are not changed. take care, Gerd
