On 12/10/2020 18:09, Philippe Mathieu-Daudé wrote:
Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org>
---
hw/pci-host/sabre.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/pci-host/sabre.c b/hw/pci-host/sabre.c
index 4412e23131c..67699ac9058 100644
--- a/hw/pci-host/sabre.c
+++ b/hw/pci-host/sabre.c
@@ -122,6 +122,7 @@ static void sabre_config_write(void *opaque, hwaddr addr,
switch (addr) {
case 0x30 ... 0x4f: /* DMA error registers */
+ case 0x200 ... 0x21f: /* IOMMU registers */
qemu_log_mask(LOG_UNIMP,
"%s: Register 0x%02" HWADDR_PRIX " not implemented\n",
__func__, addr);
@@ -201,6 +202,7 @@ static uint64_t sabre_config_read(void *opaque,
switch (addr) {
case 0x30 ... 0x4f: /* DMA error registers */
+ case 0x200 ... 0x21f: /* IOMMU registers */
qemu_log_mask(LOG_UNIMP,
"%s: Register 0x%02" HWADDR_PRIX " not implemented\n",
__func__, addr);
In theory this should never happen since a reference to the IOMMU should always be
set using an object property link (i.e. it is a developer error rather than an
unimplemented error) and its memory region overlaps this space within the PCI host
bridge.
Rather than add these logging statemants and/or failing if the property is not set, I
think now it may be possible to simply embed the IOMMU device within sabre itself
using the updated QOM APIs. I can take a look to see if this approach will work later
in the week.
ATB,
Mark.