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

Reply via email to