On 12 November 2014 15:32, Arnd Bergmann arnd@arndb.de wrote:
On Wednesday 12 November 2014 16:01:14 Claudio Fontana wrote:
Would the last step you mention allow for guests to start with an already existing PCI interrupt map and the BAR registers preprogrammed to point to somewhere sane?
I ask because on OSv at the moment, the situation is that for x86 we don't need to reprogram anything on PCI, as everything is already nicely set up by the time the guest starts, and thus the BAR addresses can be read directly. On ARM we have to reprogram the BARs manually for all devices.
Couldn't we give an easier time to each OS guest by having everything nicely set up on AArch64 as well?
Definitely, I think having the OS manually program the BARs only makes sense in an environment where you don't have a full-featured boot loader or you don't trust it. In servers and virtual machines, the PCI bus should always come fully set up. This also implies that the OS should not have to deal with registers for setting up the translation between PCI and system address ranges.
It seems to me like complicated stuff like that definitely belongs in the UEFI/bootloader blob, though. I'd rather QEMU just modelled the hardware and let the guest (or the firmware, which is guest code from QEMU's point of view) set it up however it wants.
-- PMM