On Fri, Nov 08, 2019 at 03:15:40PM +0200, Andriy Gapon wrote:
> On 08/11/2019 11:57, Roger Pau Monné wrote:
> > On Fri, Nov 08, 2019 at 10:19:01AM +0200, Andriy Gapon wrote:
> >>> I found this in Linux code:
> >>> HYPERVISOR_vcpu_op(VCPUOP_send_nmi, xen_vcpu_nr(cpu), NULL);
> >>> It's in
On Fri, Nov 08, 2019 at 10:19:01AM +0200, Andriy Gapon wrote:
> On 08/11/2019 10:03, Andriy Gapon wrote:
> > On 07/11/2019 20:08, Andriy Gapon wrote:
> >> For CPUs that do get interrupted I see stack traces like:
> >> cpustop_handler+0x28 ipi_nmi_handler+0x44 xen_cpustophard_handler+0x9
> >>
On 08/11/2019 10:03, Andriy Gapon wrote:
> On 07/11/2019 20:08, Andriy Gapon wrote:
>> For CPUs that do get interrupted I see stack traces like:
>> cpustop_handler+0x28 ipi_nmi_handler+0x44 xen_cpustophard_handler+0x9
>> intr_event_handle+0x8b intr_execute_handlers+0x58
>>
On 07/11/2019 20:08, Andriy Gapon wrote:
> For CPUs that do get interrupted I see stack traces like:
> cpustop_handler+0x28 ipi_nmi_handler+0x44 xen_cpustophard_handler+0x9
> intr_event_handle+0x8b intr_execute_handlers+0x58 xen_intr_handle_upcall+0x15a
> xen_intr_upcall_u+0x96 ...
> So, it looks
Does Xen provide any support for non-maskable interrupts interrupt delivery to a
guest?
I am trying to debug a particular crash in a Xen guest, but it seems that the
FreeBSD crash code (stop_cpus specifically) cannot interrupt some processors
and, thus, take control of them and collect their