Re: [Qemu-devel] [PATCH v2 1/4] memory: Avoid to create tiny RAM regions, handled as subpages

[Philippe Mathieu-Daudé]

On 04/05/2018 10:20 AM, Peter Maydell wrote:
> 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.)

Now this makes more sens to me, thanks :)

Luckily in my case I can workaround with a 4K SRAM, but it took me hours
to track this down until Paolo helped me.

Regards,

Phil.