Hi Jan, Jailhouse driver removes inmate cell CPU from root cell , shutdown inmate cell CPU and call JAILHOUSE_HC_CELL_CREATE. But driver removes cell CPU locally not in hypervisor data structure. Now inmate CPU is in offline and cannot receive SGI events. Thanks, Vladimir
-----Original Message----- From: Vladimir Neyelov [mailto:vladimir.neye...@broadcom.com] Sent: Tuesday, November 6, 2018 4:36 PM To: 'Jan Kiszka' <jan.kis...@siemens.com>; 'jailhouse-dev@googlegroups.com' <jailhouse-dev@googlegroups.com> Subject: RE: JAILHOUSE_HC_CELL_CREATE stuck Hi Jan, Simply I use same function that you use in jailhouse driver - cpu_down for inmate CPU before hypercall JAILHOUSE_HC_CELL_CREATE. Thanks, Vladimir -----Original Message----- From: Jan Kiszka [mailto:jan.kis...@siemens.com] Sent: Tuesday, November 6, 2018 3:34 PM To: Vladimir Neyelov <vladimir.neye...@broadcom.com>; jailhouse-dev@googlegroups.com Subject: Re: JAILHOUSE_HC_CELL_CREATE stuck On 06.11.18 13:29, 'Vladimir Neyelov' via Jailhouse wrote: > Hello all, > > I am trying to porting jailhouse on our arm64 base board. I created > configuration for inmate cell and > > trying to launch it. I have cpu bit mask 0xf for root cell and 0x8 for > inmate. > > This is my log: > > > > NONROOT: handle_hvc > > NONROOT: bitmap f, max_cpu_id 63 > > NONROOT: suspend CPU 1 > > NONROOT: cpu 1 try suspend > > SGI_EVENT > > NONROOT: cpu 1 suspended > > NONROOT: suspend CPU 2 > > NONROOT: cpu 2 try suspend > > SGI_EVENT > > NONROOT: cpu 2 suspended > > NONROOT: suspend CPU 3 > > NONROOT: cpu 3 try suspend > > > > In function cell_create called cell_suspend(&root_cell) and stuck. > > As you can see code performed on CPU 0 and it try suspend CPU 1,2 and > 3. 1 and 2 suspended successfully. > > But in case of CPU 3 it stuck in function arch_suspend_cpu on line: > > while (!target_data->cpu_suspended) > > cpu_relax(); > > > > SGI_EVENT sent to CPU 3 but doesn’t reach to exception routine. > > CPU 3 is in down state in linux. Why we need suspend CPU 3 that now > belong to inmate cell ? > Could it be that this "down state" was actually physically executed? Then the hypervisor lost control over the CPU, and it would explain why the SGI does not make. As we do not know the board nor the patches to wrote, it's hard to be more concrete. Jan -- Siemens AG, Corporate Technology, CT RDA IOT 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 jailhouse-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
