On Tue, 8 Jun 2021 at 19:39, Jan Kiszka <[email protected]> wrote: > > On 08.06.21 13:26, Dongjiu Geng wrote: > > On Tue, 8 Jun 2021 at 18:53, Jan Kiszka <[email protected]> wrote: > >> > >> On 08.06.21 11:20, Dongjiu Geng wrote: > >>> Hi, > >>> From the jailhouse design, the Private Per-CPU data should be not > >>> accessed by other CPUs except the current CPU. But from the code[1] > >>> and my test, it is not. For example, the CPU1 can access the CPU0's > >>> private data, because hv_paging_structs already map it, and the > >>> per-cpu page table will link the hv_paging_structs. is this a bug？ I > >>> think the Private Per-CPU data should be not accessed by other CPUs > >>> except the self CPU. > >>> > >>> [1]: err = paging_create(&hv_paging_structs, > >>> paging_hvirt2phys(&hypervisor_header), > >>> system_config->hypervisor_memory.size, > >>> (unsigned long)&hypervisor_header, > >>> PAGE_DEFAULT_FLAGS, > >>> PAGING_NON_COHERENT | PAGING_HUGE); > >>> > >> > >> You are referring to > >> https://github.com/siemens/jailhouse/blob/6d9c51d0bd819689c00f6a3c38d3099f6eb9c657/hypervisor/paging.c#L678: > >> Right, the initial mapping means everything is visible for all CPUs. But > >> then comes > >> https://github.com/siemens/jailhouse/blob/6d9c51d0bd819689c00f6a3c38d3099f6eb9c657/hypervisor/setup.c#L100 > >> which setups up an alternative mapping (installed by arch_cpu_init()). > >> That does not contain the private data structs of the other CPUs. You > >> should be able to confirm that AFTER initialization, e.g. on a first VM > >> exit after setup. > > > > Thanks very much for the answer, could you paste the code where it > > removes the private data structs of the other CPUs? I do not find that > > logic. After enabling jailhouse hypervisor and returning to the first > > VM0. the CPU0 still can access other CPU's private data structs, as > > shown in[1]. > > > > [1]: > > @@ -261,8 +262,10 @@ int entry(unsigned int cpu_id, struct per_cpu > > *cpu_data) > > return error; > > } > > > > - if (master) > > + if (master) { > > + printk("10: > > ----------------------------------------------------------%lx----\n", > > per_cpu(10)->id_aa64mmfr0); > > printk("Activating hypervisor\n"); > > + } > > > > Ah, need to correct myself: > > https://github.com/siemens/jailhouse/blob/6d9c51d0bd819689c00f6a3c38d3099f6eb9c657/hypervisor/arch/arm64/setup.c#L103 > > So the disabling happens even later, in arch_cpu_activate_vmm. The > alternative mapping we built up and installed in arch_cpu_init still > contains full access as you noticed. > > Again, please try after the first vmexit.
Understand now, thanks for the explanation. > > Jan > > -- > Siemens AG, T RDA IOT > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/CABSBigStz81rW1oBRkMd88e%3D-aKU%2BPUU01aA8Z5K1iPpLpYzJA%40mail.gmail.com.
