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

Re: [Xen-devel] [PATCH] fix multicall state tracking



>>> Keir Fraser <keir@xxxxxxxxxxxxx> 14.12.06 11:36 >>>
>On 12/12/06 13:30, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> This replaces the previous fix to multicall state tracking so that now the
>> multicall-
>> in-progress status is maintained on a per-VCPU basis (all other state remains
>> per physical CPU). This seems cleaner than the previous hack requiring
>> clearing
>> of the flags in domain_crash_synchronous().
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>I decided to entirely move away from domain_crash_synchronous() in hypercall
>context. So the code in domain_crash_synchronous() is just a warning for
>errant code -- later it can become BUG_ON(). This means that multicall state
>can remain per-cpu, unless per-vcpu seems much better (personally I think it
>doesn't really matter either way so we may as well stick with what we have).

But hypercall context to me seems exactly the right context for synchronously
crashing a domain - am I missing something here? What else (if any) do you
consider appropriate use of this (i.e. can't it go away then altogether)?
I'm specifically asking because I have a patch (as talked about briefly before,
pending for submission after 3.0.4) to replace the BUG() stuff with a more
Linux-like approach, which at once also puts things like WARN() and also the
crashing of a domain into the same framework. Obviously, if you consider
domain_crash_synchronous() use ill in general, I shouldn't introduce a
CRASH_ME() macro here.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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