Re: [Qemu-devel] [PATCH 1/3] ich9: call ich9_lpc_update_pic for disabled pirqs

[Ефимов Василий]

20.06.2016 17:39, Paolo Bonzini wrote:

An asserted pirq can be disabled and the corresponding GSIs
should then go down to 0.  However, because of the conditional in
ich9_lpc_update_by_pirq, the legacy 8259 pin could remain stuck to 1.

Signed-off-by: Paolo Bonzini 
---
  hw/isa/lpc_ich9.c | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 213741b..b116e1b 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -234,9 +234,6 @@ static void ich9_lpc_update_by_pirq(ICH9LPCState *lpc, int 
pirq)

  ich9_lpc_pic_irq(lpc, pirq, _irq, _dis);
  assert(pic_irq < ICH9_LPC_PIC_NUM_PINS);
-if (pic_dis) {
-return;
-}

  ich9_lpc_update_pic(lpc, pic_irq);
  }


Reviewed-by: Efimov Vasily 

Re: [Qemu-devel] [PATCH 3/3] ich9: unify pic and ioapic IRQ vectors

[Ефимов Василий]

20.06.2016 17:39, Paolo Bonzini wrote:

ich9->pic and ich9->ioapic differ for the first 16 GSIs (because
ich9->pic is wired to 8259+IOAPIC but ich9->ioapic is wired to
IOAPIC only).  However, ich9->ioapic is never used for the first
16 GSIs, so the two vectors can be merged.

Signed-off-by: Paolo Bonzini 
---
  hw/i386/pc_q35.c   | 3 +--
  hw/isa/lpc_ich9.c  | 4 ++--
  include/hw/i386/ich9.h | 3 +--
  3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e4b541f..78afd4f 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -184,8 +184,7 @@ static void pc_q35_init(MachineState *machine)
   PC_MACHINE_ACPI_DEVICE_PROP, _abort);

  ich9_lpc = ICH9_LPC_DEVICE(lpc);
-ich9_lpc->pic = gsi;
-ich9_lpc->ioapic = gsi_state->ioapic_irq;
+ich9_lpc->gsi = gsi;
  pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
   ICH9_LPC_NB_PIRQS);
  pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 446797b..7703357 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -225,7 +225,7 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int gsi)
  pic_level |= lpc->sci_level;
  }

-qemu_set_irq(lpc->pic[gsi], pic_level);
+qemu_set_irq(lpc->gsi[gsi], pic_level);
  }

  /* APIC mode: GSIx: PIRQ[A-H] -> GSI 16, ... no pirq shares same APIC pins. */
@@ -250,7 +250,7 @@ static void ich9_lpc_update_apic(ICH9LPCState *lpc, int gsi)
  level |= lpc->sci_level;
  }

-qemu_set_irq(lpc->ioapic[gsi], level);
+qemu_set_irq(lpc->gsi[gsi], level);
  }

  void ich9_lpc_set_irq(void *opaque, int pirq, int level)
diff --git a/include/hw/i386/ich9.h b/include/hw/i386/ich9.h
index 88233c3..11243e5 100644
--- a/include/hw/i386/ich9.h
+++ b/include/hw/i386/ich9.h
@@ -68,8 +68,7 @@ typedef struct ICH9LPCState {
  MemoryRegion rcrb_mem; /* root complex register block */
  Notifier machine_ready;

-qemu_irq *pic;
-qemu_irq *ioapic;
+qemu_irq *gsi;
  } ICH9LPCState;

  Object *ich9_lpc_find(void);


Reviewed-by: Efimov Vasily 

Re: [Qemu-devel] [PATCH 2/3] ich9: clean up ich9_lpc_update_pic/ich9_lpc_update_apic and callers

[Ефимов Василий]

20.06.2016 17:39, Paolo Bonzini wrote:

Make ich9_lpc_update_pic take care only of GSIs 0-15, and
ich9_lpc_update_apic take care only of GSIs 16-23.  Assert
that they are called with the correct GSI indices.

Signed-off-by: Paolo Bonzini 
---
  hw/isa/lpc_ich9.c | 39 ---
  1 file changed, 16 insertions(+), 23 deletions(-)

diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index b116e1b..446797b 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -204,38 +204,28 @@ static void ich9_lpc_pic_irq(ICH9LPCState *lpc, int 
pirq_num,
  abort();
  }

-/* pic_irq: i8254 irq 0-15 */
-static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
+/* gsi: i8259 irq 0-15, otherwise ignored */
+static void ich9_lpc_update_pic(ICH9LPCState *lpc, int gsi)
  {
  int i, pic_level;

+assert(gsi < ICH9_LPC_PIC_NUM_PINS);
+
  /* The pic level is the logical OR of all the PCI irqs mapped to it */
  pic_level = 0;
  for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
  int tmp_irq;
  int tmp_dis;
  ich9_lpc_pic_irq(lpc, i, _irq, _dis);
-if (!tmp_dis && pic_irq == tmp_irq) {
+if (!tmp_dis && tmp_irq == gsi) {
  pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
  }
  }
-if (pic_irq == ich9_lpc_sci_irq(lpc)) {
+if (gsi == ich9_lpc_sci_irq(lpc)) {
  pic_level |= lpc->sci_level;
  }

-qemu_set_irq(lpc->pic[pic_irq], pic_level);
-}
-
-/* pirq: pirq[A-H] 0-7*/
-static void ich9_lpc_update_by_pirq(ICH9LPCState *lpc, int pirq)
-{
-int pic_irq;
-int pic_dis;
-
-ich9_lpc_pic_irq(lpc, pirq, _irq, _dis);
-assert(pic_irq < ICH9_LPC_PIC_NUM_PINS);
-
-ich9_lpc_update_pic(lpc, pic_irq);
+qemu_set_irq(lpc->pic[gsi], pic_level);
  }

  /* APIC mode: GSIx: PIRQ[A-H] -> GSI 16, ... no pirq shares same APIC pins. */
@@ -253,9 +243,9 @@ static void ich9_lpc_update_apic(ICH9LPCState *lpc, int gsi)
  {
  int level = 0;

-if (gsi >= ICH9_LPC_PIC_NUM_PINS) {
-level |= pci_bus_get_irq_level(lpc->d.bus, ich9_gsi_to_pirq(gsi));
-}
+assert(gsi >= ICH9_LPC_PIC_NUM_PINS);
+
+level |= pci_bus_get_irq_level(lpc->d.bus, ich9_gsi_to_pirq(gsi));
  if (gsi == ich9_lpc_sci_irq(lpc)) {
  level |= lpc->sci_level;
  }
@@ -266,12 +256,14 @@ static void ich9_lpc_update_apic(ICH9LPCState *lpc, int 
gsi)
  void ich9_lpc_set_irq(void *opaque, int pirq, int level)
  {
  ICH9LPCState *lpc = opaque;
+int pic_irq, pic_dis;

  assert(0 <= pirq);
  assert(pirq < ICH9_LPC_NB_PIRQS);

  ich9_lpc_update_apic(lpc, ich9_pirq_to_gsi(pirq));
-ich9_lpc_update_by_pirq(lpc, pirq);
+ich9_lpc_pic_irq(lpc, pirq, _irq, _dis);
+ich9_lpc_update_pic(lpc, pic_irq);
  }

  /* return the pirq number (PIRQ[A-H]:0-7) corresponding to
@@ -362,8 +354,9 @@ static void ich9_set_sci(void *opaque, int irq_num, int 
level)
  return;
  }

-ich9_lpc_update_apic(lpc, irq);
-if (irq < ICH9_LPC_PIC_NUM_PINS) {
+if (irq >= ICH9_LPC_PIC_NUM_PINS) {
+ich9_lpc_update_apic(lpc, irq);
+} else {
  ich9_lpc_update_pic(lpc, irq);
  }
  }


Reviewed-by: Efimov Vasily 

Re: [Qemu-devel] [PATCH 11/13] ICH9 LPC: move call of isa_bus_irqs to 'realize' method

[Ефимов Василий]

20.06.2016 17:40, Paolo Bonzini wrote:


I've sent a patch series for you to rebase patch 10 and 11 on.  Let me
know what you think!
I see no problems with the patch series. In second version, I'll create 
named GPIO ("gsi") for the new IRQ vector gsi (patch 10). The vector 
will be used to set up ISA bus IRQs with isa_bus_irqs (patch 11).


Paolo



Vasily

Re: [Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to documentation

[Ефимов Василий]

07.09.2015 15:50, Paolo Bonzini пишет:


Hi Vasily,

I agree that this patch is an improvement compared to the earlier
versions, but it's still a bit of an abstraction violation and I'm not
sure if it works with KVM.

It does not work with KVM. BIOS freezes on 0xCAA26 on
mov %ax,%es
instruction (according to QEMU disassembler).

Last debug messages are:

Booting from ROM...
Booting from ca80:003c

So, a lot of BIOS code is executed. I will investigate the problem.


Let's see if we can improve things.  Please correct me on the following:

1) For the "Make current PAM region a ROM" case, we can get the
ram_addr_t directly from the pc.bios and pc.rom MemoryRegions, and poke
into pam->region[1] and pam->region[2] when we create them.

Yes, we can. But what if another region is at the address? The -pflash
option is an example.

By default and with -bios option mtree is:

address-space: memory
  - (prio 0, RW): system
-07ff (prio 0, RW): alias ram-below-4g
   @pc.ram -07ff
- (prio -1, RW): pci
  000c-000d (prio 1, RW): pc.rom
  000e-000f (prio 1, R-): alias isa-bios
  @pc.bios 0002-0003
  fffc- (prio 0, R-): pc.bios

With -pflash option mtree is:

address-space: memory
  - (prio 0, RW): system
-07ff (prio 0, RW): alias ram-below-4g
   @pc.ram -07ff
- (prio -1, RW): pci
  000c-000d (prio 1, RW): pc.rom
  000e-000f (prio 1, R-): isa-bios
fffc- (prio 0, R-): system.flash0

There is significant difference about isa-bios at least.

In general, new PAM redirects access to region at the address but
not exactly to pc.bios/isa-bios or pc.rom.

In other words, I suggest more generic solution.

We also can set up redirection at machine initialization, but using of
listener makes sure redirection is actual at runtime. I do not know
case in which regions at the PAM addresses are changed dynamically
during guest work. But even during machine initialization the memory
tree is changed multiple times. So, listener at least ensures the last
version of tree is used for redirection choice.


2) For the "Make current PAM region an I/O region" case, you could add
an IOMMU region that to 0xc-0xf.  The listener would disable
pam->region[1] if address_space_translate returns an I/O region and
enable it if it returns RAM/ROM.

As I see, IOMMU cannot be used for CPU access to memory because of
assertion (!section->mr->iommu_ops) in
exec.c: address_space_translate_for_iotlb
IOMMU is used for redirection of device and debug access through
address_space_translate. Please correct me if I miss something.

However, I cannot understand or
remember what is the case where you get an I/O region.

There is no known case in which an I/O region is at PAM addresses.
But it is theoretically possible. Hence, I decide to implement it
instead of insert an assertion. Also note, the code also covers
case of simple container memory region at the address.


Paolo

Re: [Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to documentation

[Ефимов Василий]

Ping

Vasily

Re: [Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to documentation

[Ефимов Василий]

22.07.2015 19:37, Kevin O'Connor пишет:
Hi,


Hi,

Is the motivation of this patch to improve the correctness of the
hardware emulation or is there some feature that the current QEMU
implementation prevents?

The motivation is to improve correctness. The current QEMU PAM
implementation prevents executing any guest that behave
closer to specs about PAM than SeaBIOS.


There has been some interest recently in making SeaBIOS boot faster on
QEMU and the shadow ram fixups in SeaBIOS have been shown to consume a
notable amount of bootup time (~12ms on my machine).

Will changing the PAM support improve overall boot times?  I wonder if
going from mode 0 - mode 2 - mode 3 would be more expensive
than the current SeaBIOS mode 0 - mode 3 mechanism.

The patch does not touch emulation of modes 0 and 3. SeaBIOS still
can use they, so no fixups are required in SeaBIOS. The SeaBIOS patch I
listed in letter is only to show difference between current and new
PAM implementations. An open-source BIOS is just simple way to do
that.

I measured time between QEMU start and original SeaBIOS attempt
to boot from hard disk. With original PAM it equals 267ms against 269ms
with new PAM. 100 measurements are made. Standard deviation is 15ms.
Measurements are based on QEMU_CLOCK_REALTIME and SeaBIOS I/O 0x402
port output. I patched isa-debugcon device to add per-line
timestamps.

Onetime 2ms slowdown seems to be acceptable tradeoff.


Also note that SeaBIOS would still need to copy from the high memory
location even if the PAM registers were fully implemented as SeaBIOS
often exceeds 128K - the mode 2 overwrite oneself trick would only
work for the last 128K of the rom.

Thanks,
-Kevin


Vasily

Re: [Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to documentation

[Ефимов Василий]

21.07.2015 10:46, Paolo Bonzini пишет:


Out of curiosity, would it be necessary to flush the TLB when the PAM
registers change?

In QEMU, the TLB also has the function of a cache in some sense
(because, by pointing to a ram_addr_t, it prevents reads, writes or
fetches from going through the slow MMIO path).

There is exec.c: tcg_commit callback. It calls
cpu-exec.c: cpu_reload_memory_map that calls cputlb.c:tlb_flush.

When PAM register is changed pam_update is called. Its call is
surrounded by memory_region_transaction_begin/_commit couple both in
i440fx and MCH9 host bridges. tcg_commit and pam_mem_commit are called
during memory_region_transaction_commit execution.

To summarize:
- TLB is flushed by existing code.
- Should I remove pam_update_redirection call from pam_set_current?
It will be called by pam_mem_commit soon? Note that a PAM API user
should call memory_region_transaction_begin/_commit in this case.


Paolo


Vasily

Re: [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documentation

[Ефимов Василий]

16.07.2015 20:52, Paolo Bonzini пишет:



On 16/07/2015 16:41, Ефимов Василий wrote:

The main problem is rendering memory tree to FlatView.


I don't believe it's necessary to render a memory tree to the FlatView.
  You can use existing AddressSpaces.


+/* Read from RAM and write to PCI */
+memory_region_init_io(pam-region[1], OBJECT(dev), pam_ops, pam,
+pam-r-ram-w-pci, size);

This can be done with memory_region_set_readonly on the RAM region.  You
need to set mr-ops in order to point to pam_ops; for a first proof of
concept you can just set the field directly.

The idea is to read directly from system RAM region and to write
to PCI using I/O (because I do not see another way to emulate
access type driven redirection with existent API). If we create RAM
and make it read only then new useless RAM block will be created.


Don't create RAM; modify the existing one.


It is useless because of ram_addr of new region will be set to
one within system RAM block. Hence, cleaner way is to create I/O region.


You can use the existing RAM region and modify its properties (i.e.
toggle mr-readonly) after setting special mr-ops.  The special mr-ops
will be used for writes when mr-readonly = true.

The existing RAMs are ether whole pc.ram or pc.rom and pc.bios beyond
PCI. So, I think we have not invade them. Also, we only need the small 
subrange to be read only. Moreover, if -pflash is used then there is

ROM device instead of pc.bios with its own mr-ops.

You have suggested to create AddressSpace for PCI below. It is flexible
solution which is transparent for existing regions. I suggests to create
AddressSpace for RAM subtree too.  I think, both AS have to be PAM
implementation private for complete transparency for another QEMU parts.

I will try it in next patch version.



Writes to the PCI memory space can use the PCI address space, with
address_space_st*.

There is no PCI AddressSpace (only MemoryRegion). But
address_space_st* requires AddressSpace as argument.


Then create one with address_space_init.

However, can the guest see the difference between real mode 1 and the
fake mode 1 that QEMU implements?  Perhaps mode 1 can be left as is.

Yes, guest can.
If -pfalsh is used then BIOS becomes a programmable ROM device. Then
guest can switch to mode 1 and copy data by reading and writing it
at same location. After that guest can switch to mode 0 (or 3) and
copy data to some another place. Then it switches to mode 3 (or 0) and
compares the data.

I just check it with SeaBIOS and original PAM adding code listed below
to fw/shadow.c: __make_bios_writable_intel.

dprintf(1, PAM mode 1 test begin\n);
unsigned *m = (unsigned *) BUILD_ROM_START;

pci_config_writeb(bdf, pam0 + 1, 0x33);
*m = 0xdeafbeef;

pci_config_writeb(bdf, pam0 + 1, 0x11);
volatile unsigned t = *m;
*m = t;

pci_config_writeb(bdf, pam0 + 1, 0x33);
t = *m;

pci_config_writeb(bdf, pam0 + 1, 0x00);
unsigned t2 = *m;

dprintf(1, t = 0x%x, t2 = 0x%x\n, t, t2);

dprintf(1, PAM mode 1 test end\n);

The output is:

PAM mode 1 test begin
t = 0xdeafbeef, t2 = 0x0
PAM mode 1 test end

With new PAM the output is:

PAM mode 1 test begin
t = 0xdeafbeef, t2 = 0xdeafbeef
PAM mode 1 test end

Note BUILD_ROM_START is 0xc which is pc.rom with write permission
according to info mtree output. The -pflash is not needed.




+/* Read from PCI and write to RAM */
+memory_region_init_io(pam-region[2], OBJECT(dev), pam_ops, pam,
+pam-r-pci-w-ram, size);

Here you cannot run code from ROM, so it can be a pure MMIO region.
Reads can use address_space_ld*, while writes can use
memory_region_get_ram_ptr.


Even in this mode it is possible for code to be executed from ROM. This
can happen when particular PCI address is within ROM device connected
to PCI bus.


If it's just for pc.rom and isa-bios, introduce a new function
pam_create_pci_region that creates pc.rom with
memory_region_init_rom_device.  The mr-ops can write to RAM (mode 2) or
discard the write (mode 0).

They you can make pc.rom 256K instead of 128K, and instead of an alias,
you can manually copy the last 128K of the BIOS into the last 128K of
pc.rom.

Some adjustment will be necessary in order to support migration (perhaps
creating two 128K regions pc.rom and pc.rom.mirror), but for a proof of
concept the above should be enough.
I will try solution based on address spaces as stated above. It is 
cleaner and more generic.


Paolo


Vasily

Re: [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documentation

[Ефимов Василий]

16.07.2015 12:05, Paolo Bonzini пишет:



On 16/07/2015 10:35, Efimov Vasily wrote:

This patch improves PAM emulation.

PAM defines 4 memory access redirection modes. In mode 1 reads are directed to
RAM and writes are directed to PCI. In mode 2 it is contrary. In mode 0 all
access is directed to PCI. In mode 3 it is directed to RAM. Modes 0 and 3 are
well emulated but modes 1 and 2 are not. The cause is: aliases are used
while more complicated logic is required.

The idea is to use ROM device like memory regions for mode 1 and 2 emulation
instead of aliases. Writes are directed to proper destination region by
specified I/O callback. Read redirection depends on type of source region.
In most cases source region is RAM (or ROM), so ram_addr of PAM region is set to
ram_addr of source region with offset. Otherwise, when source region is an I/O
region, reading is redirected to source region read callback by PAM region one.

Read source and write destination regions are updated by the memory
commit callback.

Note that we cannot use I/O region for PAM as it will violate trying to execute
code outside RAM or ROM assertion.

Signed-off-by: Efimov Vasily r...@ispras.ru
---
  hw/pci-host/pam.c | 238 +-
  include/hw/pci-host/pam.h |  10 +-
  2 files changed, 223 insertions(+), 25 deletions(-)

diff --git a/hw/pci-host/pam.c b/hw/pci-host/pam.c
index 17d826c..9729b2b 100644
--- a/hw/pci-host/pam.c
+++ b/hw/pci-host/pam.c
@@ -27,43 +27,233 @@
   * THE SOFTWARE.
   */

-#include qom/object.h
-#include sysemu/sysemu.h
  #include hw/pci-host/pam.h
+#include exec/address-spaces.h
+#include exec/memory-internal.h
+#include qemu/bswap.h
+
+static void pam_write(void *opaque, hwaddr addr, uint64_t data,
+  unsigned size)
+{
+PAMMemoryRegion *pam = (PAMMemoryRegion *) opaque;
+void *ptr;
+
+/* Destination region can be both RAM and IO. */
+if (!memory_access_is_direct(pam-mr_write_to, true)) {
+memory_region_dispatch_write(pam-mr_write_to,
+ addr + pam-write_offset, data, size,
+ MEMTXATTRS_UNSPECIFIED);
+} else {
+ptr = memory_region_get_ram_ptr(pam-mr_write_to) + addr
+  + pam-write_offset;
+
+switch (size) {
+case 1:
+stb_p(ptr, data);
+break;
+case 2:
+stw_he_p(ptr, data);
+break;
+case 4:
+stl_he_p(ptr, data);
+break;
+case 8:
+stq_he_p(ptr, data);
+break;
+default:
+abort();
+}
+
+invalidate_and_set_dirty(pam-mr_write_to, addr + pam-pam_offset,
+ size);
+}
+}
+


The idea is very good, but the implementation relies on copying a lot of
code from exec.c.

If it is about pam_write then, for instance, I could suggest to outline
corresponding part of address_space_rw to dedicated public function.
The solution will require endianness conversion because of the
part works with uint8_t buffer but not with uint64_t values.

The rest of code looks up destination or source region or child region
offset in memory sub-tree which root is PCI or RAM region provided on
PAM creation. We cannon use common address_space_translate because it
searches from address space root and will return current PAM region.
To summarize, I suggest to move the code to exec.c. It is generic
enough.


Could you use an IOMMU memory region instead?  Then a single region can
be used to implement all four modes, and you don't hit the trying to
execute code outside RAM or RAM.

Did you mean MemoryRegion.iommu_ops ? The feature does not allow to
change destination memory region. Also I has no find its using during
write access from CPU. And there is:

exec.c: address_space_translate_for_iotlb:
assert(!section-mr-iommu_ops);



Paolo

Re: [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documentation

[Ефимов Василий]

16.07.2015 14:10, Paolo Bonzini wrote:


 On 16/07/2015 12:51, Ефимов Василий wrote:
 The rest of code looks up destination or source region or child region
 offset in memory sub-tree which root is PCI or RAM region provided on
 PAM creation. We cannon use common address_space_translate because it
 searches from address space root and will return current PAM region.
 To summarize, I suggest to move the code to exec.c. It is generic
 enough.

 All these mechanism are extremely low level.  They are encapsulated
 within exec.c, and copying code to pam.c is not a good idea because you
 already have all the AddressSpaces and RAM MemoryRegions you need.
The core problem is there is no region type which can redirects access
depending on whether it is read or write. The access type driven alias
could be perfect. But it is quite difficult to invent such type of
alias (or to generalize existing). The main problem is rendering memory
tree to FlatView.

 Could you use an IOMMU memory region instead?  Then a single region can
 be used to implement all four modes, and you don't hit the trying to
 execute code outside RAM or RAM.
 Did you mean MemoryRegion.iommu_ops ? The feature does not allow to
 change destination memory region.

 It does.  You're right about this:

 exec.c: address_space_translate_for_iotlb:
  assert(!section-mr-iommu_ops);

 ... but an IOMMU region is not needed, and I think you can do everything
 without touching exec.c at all.

 +/* Read from RAM and write to PCI */
 +memory_region_init_io(pam-region[1], OBJECT(dev), pam_ops, pam,
 +pam-r-ram-w-pci, size);

 This can be done with memory_region_set_readonly on the RAM region.  You
 need to set mr-ops in order to point to pam_ops; for a first proof of
 concept you can just set the field directly.
The idea is to read directly from system RAM region and to write
to PCI using I/O (because I do not see another way to emulate
access type driven redirection with existent API). If we create RAM
and make it read only then new useless RAM block will be created.
It is useless because of ram_addr of new region will be set to
one within system RAM block. Hence, cleaner way is to create I/O region.

 Writes to the PCI memory space can use the PCI address space, with
 address_space_st*.
There is no PCI AddressSpace (only MemoryRegion). But
address_space_st* requires AddressSpace as argument.

 +/* Read from PCI and write to RAM */
 +memory_region_init_io(pam-region[2], OBJECT(dev), pam_ops, pam,
 +pam-r-pci-w-ram, size);

 Here you cannot run code from ROM, so it can be a pure MMIO region.
 Reads can use address_space_ld*, while writes can use
 memory_region_get_ram_ptr.

Even in this mode it is possible for code to be executed from ROM. This
can happen when particular PCI address is within ROM device connected
to PCI bus.

I do not have examples where this happens in mode 2, but in mode 0
(where reads are also directed to PCI) this happens at startup time
when BIOS is executed from ROM device on PCI. The path in memory tree
is system - pam-pci - pci - isa-bios - pc.bios where pc.bios is ROM
and pam-pci is alias.

If this happens when PAM is in mode 2 then path should become
system - pam-r-pci-w-ram where pam-r-pci-w-ram is ROM which ram_addr
points to RAM block of pc.bios. Write handler of pam-r-pci-w-ram
performs access to RAM block of pc.ram.

Implemented mechanism performs search for leaf region. And it supports
cases when leaf is I/O too. In this case pam-r-pci-w-ram (and
pam-r-ram-w-pci) becomes clear I/O and both its handlers
redirects access to corresponding region.

 Paolo


Vasily