On 2017-05-02 17:35, Jonas Westaker wrote: >>> Hi, >>> >>> I'm also experimenting with ivshmem between the root-cell and a bare >>> metal cell. In my case, however, on BananaPi M1. >>> >>> Could you elaborate on modifying the functions >>> pci_(read|write)_config to use mmio instead of pio? >>> >>> I guess it's a matter of accessing the appropriate memory mapped PCI >>> configuration space of the (virtual) PCI devices available to the >>> guest/inmate instead of accessing PCI_REG_ADDR_PORT and >>> PCI_REG_DATA_PORT using functions(out|in)[bwl]? >> >> Exactly mmio = memory mapped IO, pio = port IO (in|out). The outs and >> ins will not work, instead the whole config space will be in physical >> memory. The location can be found in the root-cell configuration >> .pci_mmconfig_base. >> Some more information can be found here. >> http://wiki.osdev.org/PCI >> >> The method currently implemented is called method #1 on that wiki. Make >> sure to keep your access aligned with the size that is requested. >> >> Code that is similar to what you will need can be found in the >> hypervisor. hypervisor/pci.c include/jailhouse/mmio.h >> >> Henning >> >> >>> Best regards - Jonas Weståker >>> > > Thanks for the fast response. > I've got a bit further in porting ivshmem-demo.c from x86 to arm, but a few > new questions arise: > When scanning the configuration area of the (virtual) PCI device the > followning is reported: "IVSHMEM ERROR: device is not MSI-X capable" - is > this a problem?
The demo was written with the assumption there is always MSI-X for ivshmem interrupts. However, we only have this on ARM when there is also a gic-v2m MSI controller physically available. That is not the case on the Jetson. We then fall back to line-based interrupts (INTx). The demo needs to be extended in this regard. You will probably have to hard-code the GIC interrupt number as well because the demos have no device tree support. > > jailhouse/inmates/lib/x86/mem.c:map_range() is used to map the IVSHMEM region > and registers. Got any pointers to code doing the equivalent for ARM? > > What is the expected behaviour when accessing unmapped memory in an inmate? > > (E.g., I can see the inmate/cell gets shut down when touching memory outside > .pci_mmconfig_base + 0x100000): > # Unhandled data read at 0x2100000(2) > FATAL: unhandled trap (exception class 0x24) > pc=0x00000ff4 cpsr=0x60000153 hsr=0x93400006 > r0=0x00001834 r1=0x0000000d r2=0x00000000 r3=0x00006ed1 > r4=0x02100000 r5=0x00000000 r6=0x00000002 r7=0x0000ffff > r8=0x00001000 r9=0x00000000 r10=0x00000000 r11=0x00000000 > r12=0x00000000 r13=0x00006f80 r14=0x00000fc4 > Parking CPU 1 (Cell: "ivshmem-demo") That is the expected behaviour: stop the CPU that performed the invalid access. > > What memory areas are made available by Jailhouse for a cell/inmate to access? On ARM, the GICV (as GICC) and everything you list in the config. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- 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.
