>Last warning. :)
>You answer in html inside response and use strange formatting: it's
>really hard to read your mails and a fiddling finding out the spots
>where you responded.
I deleted the whole message and am answering to your message exactly, sorry
for disturbance.
>You need to use MAP_UNCACHED for MMIO devices. But keep in mind that we
>use huge pages on arm, so 2MiB will get mapped, but that shouldn't be an
>issue in your case.
> I could not find a signature, but I think I need a void pointer with
> address as an argument, am I correct?
>How can you even not find the signature? There's nothing easier like that:
>$ git grep map_range
>void map_range(void *start, unsigned long size, enum map_type map_type)
>But yes, besides you should use MAP_UNCACHED, this looks good.
Yes, I have done all of this till here
>OK - I think I don't understand what you refer to with "signature".
>>Ok, now things get a bit complicated:
>Usually, the finest granularity for assigning memory is the PAGE_SIZE,
>which is, in case of ARM, 4KiB (0x1000). If you map anything below
>0x1000 (e.g., 0xb4), then Jailhouse implements subpaging: The hypervisor
>will trap on access, and dispatch the access. In this case, you must
>specify JAILHOUSE_MEM_IO_${WIDTH} (with WIDTH=8,16,32,64), in order to
>allow access within a specified width.
Yes, this was tricky and I made your recommendation and used
JAILHOUSE_MEM_IO_32
in inmate configuration file.
>Otherwise, you will fault, as you can see here. "size 4" tells you that
>the width was 4*8=32 bit (obviously, you used mmio_write32).
>So now there are two possibilities how you can fix this issue:
>1. Change the config flags of the memory region to:
>.flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
>JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32
>Advantage: You *exactly* only map 0xb4 byte of the device
>Disadvantage: The hypervisor will trap on every access
This option is working and does not contradict with the concept of static
partitioning. There are different Peripherals in this area and It would be
better to distribute on cells.
>2. Change .size from 0xb4 to 1*PAGE_SIZE. This will map 4KiB instead of
>0xb4 byte. If there are no other devices behind that physical memory
>region, then this should be the preferred choice, as no further
>hypervisor activity will be involved.
I used the first option and it is working like a charm. The second option I
tried with .size=0x1000 and I got:
unhandled data write at 0xfe2000020(4), which is the GPIO_SET_Register
unhandled trap (exception class 0x24)
Then CPU 0 was parked
unhandled data write at 0xfe2000028(4), which is the GPIO_CLR_Register
unhandled trap (exception class 0x24)
Then CPU 2 was parked
So, I will avoid it apparently, unless you have an idea.
Thanks so much for your help and I tried to avoid HTML emails as much as I
can.
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/bf8c269c-0868-4296-b97a-edc841ac530cn%40googlegroups.com.
