On 5 April 2018 at 13:53, Philippe Mathieu-Daudé <address@hidden> wrote:
On 04/05/2018 06:27 AM, Peter Maydell wrote:
On 5 April 2018 at 02:22, Philippe Mathieu-Daudé <address@hidden> wrote:
If an user creates a RAM region smaller than TARGET_PAGE_SIZE,
this region will be handled as a subpage.
While the subpage behavior can be noticed by an experienced QEMU
developper, it might takes hours to a novice to figure it out.
To save time to novices, do not allow subpage creation via the
memory_region_init_ram_*() functions.
This commit message doesn't make it clear to me what actually
goes wrong. Why doesn't the subpage mechanism do the right thing
here?
Trying to understand a bit more, I think the problem is "you can not
_execute_ from a region smaller than TARGET_PAGE_SIZE", however if this
region is used for I/O this is not a problem (the xilinx-pcie.c case).
In my case I create a 2K SRAM which contains the exception vectors, but
instructions are never fetched because it is handled as I/O.
Ah, I wondered if it might be that. Yes, you can't execute from
small lumps of memory at the moment. We might be able in theory
to fix this for TCG, though I think it's harder to do so for KVM.
If we end up implementing small-MPU-region support for ARM v7M/v8M
that will have a similar setup. When RTH and I last discussed that:
https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg00293.html
I think the favoured idea was to have a way to say "always take the
slow path and do an MPU/MMU check". If we also had a mechanism for
taking the slow path for code execution that would effectively
also allow execution from subpages, though done only slowly one
guest insn per TLB. The two use cases aren't exactly the same but
some of the implementation seems similar enough to do the same way.
(There's a lot of unresolved detail and irritating corner cases to
deal with, though.)