Den tisdag 2 maj 2017 kl. 18:12:04 UTC+2 skrev J. Kiszka: > 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. >
I'm on BPi-M1, but as far as I've understood, it has a gic-v2 (Allwinner A20, 2* Cortex-A7). > 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. > I guess using a command line argument would be the way to go, as well as the base address of the PCI configuration area, as you suggested earlier. > > > > 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 BR - Jonas -- 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.
