Re: [Xen-devel] [PATCH] xen: Improvements to domain_crash_sync()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/02/18 16:17, Jan Beulich wrote:
>>>> On 05.02.18 at 16:34, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 05/02/18 13:44, Jan Beulich wrote:
>>>>>> On 05.02.18 at 12:16, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> The use of __LINE__ in a printk() is problematic for livepatching, as it
>>>> causes unnecessary binary differences.
>>>>
>>>> Furthermore, diagnostic information around calls is inconsistent and
>>>> occasionally unhelpful.  (e.g. diagnosing logs from the field which might 
>>>> be
>>>> release builds, or likely without exact source code).
>>>>
>>>> Take the opportunity to improve things.  Shorten the name to
>>>> domain_crash_sync() and require the user to pass a print message in.
>>> First of all I'd like to re-iterate that a long time ago a plan was
>>> formulated to entirely remove synchronous domain crashing. If I
>>> leave aside the three uses in wait.c (which you say you want to
>>> remove in its entirety anyway rather sooner than later), there
>>> are two other call sites. Wouldn't it therefore be more productive
>>> to actually get rid of those?
>> The asm_domain_crash_synchronous() callsite is also heading for the
>> axe.  I've already deleted it in my series pulling bounce frame handling
>> up into C.
>>
>> The vmx_vmentry_failure() callsite looks like it can turn into
>> domain_crash() by allowing the function to return and re-enter the
>> softirq processing path.
>>
>> Given that, I'd be happy to get rid of the domain_crash_sync()
>> infrastructure eventually, but given how far off the deletion patches
>> are, I'd still like to drop the __LINE__ reference in the short term.
> I can live with that, but please make clear in the commit message
> that this is intended to die (so that people won't use improvements
> being done here as argument to add new users).

Actually, on further consideration, its probably best to drop
domain_crash_sync() entirely, and opencode the softirq loop in the few
cases of almost-removed code.  That would completely prevent people from
introducing new uses.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel