On 23/07/2019 15:14, Juergen Gross wrote: > On 23.07.19 15:31, Andrew Cooper wrote: >> On 23/07/2019 14:25, Juergen Gross wrote: >>> On 23.07.19 14:26, Andrew Cooper wrote: >>>> On 23/07/2019 10:20, Juergen Gross wrote: >>>> >>>>> } >>>>> /* >>>>> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h >>>>> index b40c8fd138..721c429454 100644 >>>>> --- a/xen/include/xen/sched.h >>>>> +++ b/xen/include/xen/sched.h >>>>> @@ -200,7 +200,10 @@ struct vcpu >>>>> /* VCPU is paused following shutdown request >>>>> (d->is_shutting_down)? */ >>>>> bool paused_for_shutdown; >>>>> /* VCPU need affinity restored */ >>>>> - bool affinity_broken; >>>>> + uint8_t affinity_broken; >>>>> +#define VCPU_AFFINITY_OVERRIDE 0x01 >>>>> +#define VCPU_AFFINITY_NMI 0x02 >>>> >>>> VCPU_AFFINITY_NMI_MCE ? It is used for more than just NMIs. >>> >>> Okay. >>> >>> BTW: The MCE case is never triggered (there is no caller of >>> pv_raise_interrupt() with TRAP_machine_check). Is this code left in >>> place on purpose or could it be removed? >> >> It come from the restore_all_guest path in assembly, via process_mce. > > Are you sure? I can see that it would call > set_guest_machinecheck_trapbounce(), but I don't see how NMI_MCE_SOFTIRQ > would be triggered on this path, which would be required for hitting > nmi_mce_softirq().
Looking at it, I'm not so sure... There is certainly room for further clean-up here, for anyone with enough time to disentangle this rats nest. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel