On 09.11.2022 21:16, George Dunlap wrote:
>> On 4 Nov 2022, at 05:01, Andrew Cooper wrote:
>> On 03/11/2022 16:36, Juergen Gross wrote:
>>> The code generated for the call_handlers_*() macros needs to avoid
>>> undefined behavior when multiple handlers share the same priority.
>>> The issue is
On 09.11.22 21:16, George Dunlap wrote:
On 4 Nov 2022, at 05:01, Andrew Cooper wrote:
On 03/11/2022 16:36, Juergen Gross wrote:
The code generated for the call_handlers_*() macros needs to avoid
undefined behavior when multiple handlers share the same priority.
The issue is the hypercall
> On 4 Nov 2022, at 05:01, Andrew Cooper wrote:
>
> On 03/11/2022 16:36, Juergen Gross wrote:
>> The code generated for the call_handlers_*() macros needs to avoid
>> undefined behavior when multiple handlers share the same priority.
>> The issue is the hypercall number being unverified fed
> On 4 Nov 2022, at 05:01, Andrew Cooper wrote:
>
> The series claims "This is beneficial to performance and avoids
> speculation issues.", c/s 8523851dbc4.
>
> That half sentence is literally the sum total of justification given for
> this being related to speculation.
The cover letter,
On 04.11.2022 06:01, Andrew Cooper wrote:
> On 03/11/2022 16:36, Juergen Gross wrote:
>> The code generated for the call_handlers_*() macros needs to avoid
>> undefined behavior when multiple handlers share the same priority.
>> The issue is the hypercall number being unverified fed into the
On 04.11.22 06:01, Andrew Cooper wrote:
On 03/11/2022 16:36, Juergen Gross wrote:
The code generated for the call_handlers_*() macros needs to avoid
undefined behavior when multiple handlers share the same priority.
The issue is the hypercall number being unverified fed into the macros
and then
On 03/11/2022 16:36, Juergen Gross wrote:
> The code generated for the call_handlers_*() macros needs to avoid
> undefined behavior when multiple handlers share the same priority.
> The issue is the hypercall number being unverified fed into the macros
> and then used to set a mask via "mask =