On 05/04/2017 07:11 PM, Jan Kiszka wrote: > On 2017-05-02 18:08, Ralf Ramsauer wrote: >> Hi, >> >> is there a way on ARM to find out on which physical CPU I'm currently >> running on? >> >> I need this information for interrupt routing. (In Jailhouse) GIC's >> ITARGETSR expects physical CPU IDs. Of course I could statically provide >> this information, but I'd like to find it out during runtime. >> >> Reading the Multi Processor Affinity Register (MPIDR) [1] reports the >> "CPU ID". However, reading this register as a Jailhouse inmate always >> reports 0 for the primary boot CPU, regardless of the real physical CPU. > > Yeah, it's virtualized: The ARM guests will see what we wrote into > VMPIDR_EL2, and that's virt_id. Ah, thank you very much! This helps clarifying things (and maybe explaining effects). > >> >> Let's assume I have a quad-core system (e.g. Jetson TK1) and I assign >> the cpu_mask 0xc (phyical CPUs 2 and 3) to a cell, then reading MPIDR >> reports 0 for phys. CPU 2 and 1 for phys CPU 3. >> >> This means that I'm able to logically differentiate between CPUs, but >> I'm not able to dynamically reconfigure IRQ routing, as I need physical >> CPU IDs. > > That's done my Jailhouse for you when writing to ITARGETSR. > >> >> Thanks >> Ralf >> >> PS: I guess this might also be the reason why we always assign "reg = >> <0x0>;" in Linux Inmate DTs to primary boot CPUs and the real physical >> IDs, e.g., "reg = <0x3>;" to secondary CPUs. (cf. >> configs/dts/inmate-jetson-tk1.dts), right? > > In theory, things should be virtualized properly. But there might be > remaining issues. I never really analyzed where this effect comes from. Maybe I can explain this effect now...
- MPIDR in cells reports virtual CPU IDs, and not physical CPU IDs. IOW, if phys. CPUs 2 and 3 are assigned to a cell, they will get virtual CPU IDs 0 and 1 from the cell's point of view. - PSCI calls (e.g., CPU_ON / CPU_OFF) seem to expect physical CPU IDs from cells. This is what I experienced while implementing a PSCI interface for inmates and explains why we have to assign physical CPU IDs for secondary CPUs for Linux Inmates. - GICD_ITARGETSR accesses are trapped by the HV. From what I can say, it expects physical CPU IDs as well. Example (ARM32): Let's say I assign phys. CPU mask 0xc to a cell and Interrupt 120. MPIDR inside cell reports 0 for the boot CPU ID (virtual ID). So I assume that ID 1 is my secondary CPU. But PSCI_CPU_ON on CPU 1 fails with EPERM. On the other hand PSCI_CPU_ON on CPU 3 works! After I brought up that CPU, guess what it reports as ID :) It reports ID 1. PSCI emulation apparently doesn't properly translate physical to virtual CPUs. Same thing is for accessing ITARGETSR from cells: mmio_write8(GICD_V2_BASE + GICD_ITARGETSR + 120, 0xc); works, while mmio_write8(GICD_V2_BASE + GICD_ITARGETSR + 120, 0x3); panics the cell because of routing IRQ outside of cell. I would expect the exact opposite. Ralf > > Moreover, ARM64 decided to not virtualize the ID. We will have to look > into these nasty details again, at latest when trying to enable GICv3 > for ARM64, because that variant currently relies on the virtualization. > >> >> BTW: Who actually fills MPIDR? Do reads trap to the hypervisor? If not, >> why does the hardware fill it with some sort of 'virtual' CPU IDs? >> >> [1] >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/CIHEBGFG.html >> > > See above. > > Jan > -- 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.
