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.

Reply via email to