On 05/14/2018 06:44 PM, Jan Kiszka wrote: > On 2018-05-14 18:19, Ralf Ramsauer wrote: >> On 05/14/2018 05:49 PM, Jan Kiszka wrote: >>> On 2018-05-14 14:18, Ralf Ramsauer wrote: >>>> Hi, >>>> >>>> analogously to x86, this series provides some platform information on >>>> ARM via the communication region. >>>> >>>> In sum, this series passes to inmates: >>>> - A struct jailhouse_debug_console to inmates on all architectures >>>> (including x86, but there it is not used yet) >>>> - arm: GIC (v3 and v4) register locations >>>> - arm: Platform Timer IRQ >>>> >>>> The nice thing is that we get rid of mach.h on ARM architectures, which >>>> makes inmates completely platform independant. >>>> >>>> Inmate command line options (e.g., con-type, con-divider, ...) may still >>>> override platform information. >>>> >>>> Tested on a Jetson TK1 and qemu-arm64. >>>> >>>> I converted this to a RFC series as there are still some things missing: >>>> - Documentation for new comm region ABI >>>> - Use the comm region's struct jailhouse_console on x86 >>>> - Analogously to arm: rewrite x86's uart drivers, embed them in struct >>>> uart_chip >>>> - We then can (probably) consolidate both architecture's printk.c >>> >>> What's the status of cache/mmu enabling? >>> >>> Jan >>> >> >> Cache/MMU enabling is unrelated to these patches, these patches will >> work without MMU enabling. Inmates only read from the comm region. > > I don't find code that flushes dcaches...
When exactly should dcaches be flushed? After setting up the comm region entries? > > We really have to solve that coherency issue before promoting the comm > region on ARM. > >> >> However, I took your stub and played around with it. To get around >> map_range() for the comm region, i mapped the comm region to 0x10000, >> which will be id-mapped by the static page table. >> >> MMU and D+I caches are enabled, but this doesn't seem to be enough. >> Caches are highly configurable [1] on ARM, but I didn't have time to dig >> deeper into that. And I'm not a cache expert, though. >> >> Additionally, for the eventual fix, we will need a map_range() which >> requires some sort of dynamic PT and isn't implemented yet. > > Understood, and the more I would like to avoid rushing forward without > having the full picture yet. Absolutely. That's the reason why I tagged it with RFC. (But we'll need the MMU in any case, as there's still ivshmem) Ralf > > Jan > >> >> Ralf >> >> [1] >> https://developer.arm.com/docs/ddi0329/latest/functional-overview/functional-operation/axi-master-and-slave-interfaces >> > -- 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]. For more options, visit https://groups.google.com/d/optout.
