[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through hvm_funcs to direct ones

>>> On 13.07.18 at 12:06, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
>> Of Jan Beulich
>> Sent: 11 July 2018 14:43
>> To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
>> Subject: [Xen-devel] [PATCH 10/16] x86/HVM: patch indirect calls through
>> hvm_funcs to direct ones
>> This is intentionally not touching hooks used rarely (or not at all)
>> during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
>> as well as nested, VM event, and altp2m ones (they can all be done
>> later, if so desired). Virtual Interrupt delivery ones will be dealt
>> with in a subsequent patch.
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Needless to say that I'm pretty unhappy about the workaround I had to
>> add to hvm_set_rdtsc_exiting(). Improvement suggestions welcome.
> Presumably the workaround is needed because of the ?: in ALT_CALL_ARG() and 
> will occur for any bool argument to an alternatives patched call?


> If so, and 
> ad hoc workaround seems undesirable. Is it possible to suppress it by 
> dropping the gcc-ism from the ternary operator?

Hmm, yes, that looks to work. Makes the code slightly more ugly,
though. And I dislike this because of the warning being pointless
when such an expression occurs in sizeof(), alignof(), or typeof()
(i.e. when the expression isn't really evaluated). But perhaps
that's less ugly than the current warning suppression.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.