"Michael Kelley (EOSG)" writes:
> From: Vitaly Kuznetsov Sent: Wednesday, August 1, 2018
> 2:26 AM
>
>> > I was trying to decide if there are any arguments in favor of one
>> > approach vs. the other: a per-cpu flag in memory or checking
>> > the synic_control "enable" bit. Seems like a
From: Vitaly Kuznetsov Sent: Wednesday, August 1, 2018
2:26 AM
> > I was trying to decide if there are any arguments in favor of one
> > approach vs. the other: a per-cpu flag in memory or checking
> > the synic_control "enable" bit. Seems like a wash to me, in which
> > case I have a
"Michael Kelley (EOSG)" writes:
> From: Vitaly Kuznetsov Sent: Tuesday, July 31, 2018
> 4:20 AM
>>
>> Alternatively, we can get rid of synic_initialized flag altogether:
>> hv_synic_init() never fails in the first place but we can always
>> implement something like:
>>
>> int
From: Vitaly Kuznetsov Sent: Tuesday, July 31, 2018 4:20
AM
>
> Reviewed-by: Vitaly Kuznetsov
Thanks for the review
>
> Alternatively, we can get rid of synic_initialized flag altogether:
> hv_synic_init() never fails in the first place but we can always
> implement something like:
>
> int
mhkelle...@gmail.com writes:
> From: Michael Kelley
>
> The synic_initialized flag is part of the global hv_context
> structure. But the Hyper-V synthetic interrupt controller is
> fundamentally a per-cpu device, and other synic related
> fields are in hv_per_cpu_context. In a multi-CPU
From: Michael Kelley
The synic_initialized flag is part of the global hv_context
structure. But the Hyper-V synthetic interrupt controller is
fundamentally a per-cpu device, and other synic related
fields are in hv_per_cpu_context. In a multi-CPU system,
synic_initialized gets set multiple
