Messages in this thread | | | Date | Fri, 18 Mar 2016 17:11:50 +0100 | From | Radim Krcmar <> | Subject | Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios |
| |
2016-03-18 16:53+0100, Vitaly Kuznetsov: > Radim Krcmar <rkrcmar@redhat.com> writes: >> 2016-03-18 13:33+0100, Vitaly Kuznetsov: >>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void) >> >> (I'm not a huge fan of the unloaded variable; what about remembering the >> header/msgtype here ... >> >>> unloaded = true; >>> >>> vmbus_signal_eom(msg); >> >> and checking its value here?) >> > > Sure, but we'll have to use a variable for that ... why would it be > better than 'unloaded'?
It's easier to understand IMO,
x = mem | x = mem if *x == sth | z = *x u = true | eoi() | eoi() if u | if z == sth break | break
And you can replace msg with the new variable,
z = *mem eoi() if z == sth break
>> Can't this be NULL? > > It can't, we allocate it from hv_synic_alloc() (and we don't support cpu > onlining/offlining on WS2012R2+).
Reviewed-by: Radim Krčmář <rkrcmar@redhat.com>
Thanks.
>>> + msg = (struct hv_message *)page_addr + VMBUS_MESSAGE_SINT; >>> + msg->header.message_type = HVMSG_NONE; >>> } >> >> (And, this block belongs to a separate function. ;]) > > I thought about moving it to hv_crash_handler() but then I decided to > leave it here as the need for this fixup is rather an artifact of how we > recieve the message. But I'm flexible here)
Ok, clearing all VCPUs made me think that it would be generally useful.
| |