[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |