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