On 2018-04-16 23:53, Giovani Gracioli wrote: > I instrumented the code with several prints. > > When I start the bare-metal cell, I can see that an interrupt from CPU 3 is > issued and handled by CPU 0: > > Started cell "gic-demo-ivshmem" > ivshmem_register_mmio() mmio->address = 8, mmio->is_write = 0, current cpu = 3 > ivshmem_register_mmio() mmio->address = 0, mmio->is_write = 1, current cpu = 3 > arch_ivshmem_update_intx(ive=0x0000ffffc02450a0), > device->info->num_msix_vectors = 0, ctrl eg intx enable = 1 > ivshmem_register_mmio() mmio->address = 12, mmio->is_write = 1, current cpu = > 3 > @@@@@ ivshmem_remote_interrupt() ive->remote: 0x0000ffffc0245000, current cpu > = 3 > arch_ivshmem_trigger_interrupt(ive:0x0000ffffc0245000), irq_id:136, current > cpu = 3 > irqchip_set_pending(), local_injection = 0, sender (current cpu) = 3 > irqchip_set_pending() -> inside if(!cpu_data) > irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:136), is_sgi(irq_id) = > 0 > irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, > cpu_data->cpu_id = 0 > arch_handle_phys_irq calling irqchip_set_pending(cpu_data=0x0000ffffc021d000, > irqn=136), cpu_id = 0 > irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 > irqchip_set_pending() -> just return after irqchip.inject_irq, > cpu_data->cpu_id = 0 > irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 > irqchip_set_pending() -> just return after irqchip.inject_irq, > cpu_data->cpu_id = 0 > > When I run the program to generate an interrupt from Linux, I got the > following output: > > /dev/mem opened. > Memory mapped at address 0x7f988f2000. > Writing 1 to 0x7f988f200c > ivshmem_register_mmio() mmio->address = 12, mmio->is_write = 1, current cpu = > 1 > @@@@@ ivshmem_remote_interrupt() ive->remote: 0x0000ffffc02450a0, current cpu > = 1 > arch_ivshmem_trigger_interrupt(ive:0x0000ffffc02450a0), irq_id:136, current > cpu = 1 > irqchip_set_pending(), local_injection = 0, sender (current cpu) = 1 > irqchip_set_pending() -> inside if(!cpu_data) > irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:136), is_sgi(irq_id) = > 0 > irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, > cpu_data->cpu_id = 0 > arch_handle_phys_irq calling irqchip_set_pending(cpu_data=0x0000ffffc021d000, > irqn=136), cpu_id = 0 > irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 > irqchip_set_pending() -> just return after irqchip.inject_irq, > cpu_data->cpu_id = 0 > irqchip_handle_irq(cpu_data:0x0000ffffc021d000, irq_id:25), is_sgi(irq_id) = 0 > irqchip_handle_irq() this_cpu_data() = 0x0000ffffc021d000, current cpu 0, > cpu_data->cpu_id = 0 > irqchip_set_pending(), local_injection = 1, sender (current cpu) = 0 > irqchip_set_pending() -> just return after irqchip.inject_irq, > cpu_data->cpu_id = 0 > > Seems that the connection between Linux (root-cell) and the bare-metal one is > not correct, but the other way around is fine. Why is that?
Just to confirm my understanding: You have the same cell configurations, just switching the binary executed in the non-root cell between Linux and a bare-metal inmate, right? Is the root Linux programming the INTX_CTRL register properly (not part of your trace)? 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.
