[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Ping: [PATCH] VMX: sync CPU state upon vCPU destruction
On 11/21/2017 04:42 PM, Dario Faggioli wrote: > On Tue, 2017-11-21 at 08:29 -0700, Jan Beulich wrote: >>>>> On 21.11.17 at 15:07, <igor.druzhinin@xxxxxxxxxx> wrote: >>> >> The question here is: In what other cases do we expect an RCU >> callback to possibly touch guest state? I think the common use is >> to merely free some memory in a delayed fashion. >> >>> Those choices that you outlined appear to be different in terms >>> whether >>> we solve the general problem and probably have some minor >>> performance >>> impact or we solve the ad-hoc problem but make the system more >>> entangled. Here I'm more inclined to the first choice because this >>> particular scenario the performance impact should be negligible. >> >> For the problem at hand there's no question about a >> performance effect. The question is whether doing this for _other_ >> RCU callbacks would introduce a performance drop in certain cases. >> > Well, I personally favour the approach of making the piece of code that > plays with the context responsible of not messing up when doing so. > > And (replying to Igor comment above), I don't think that syncing > context before RCU handlers solves the general problem --as you're > calling it-- of "VMX code asynchronously messing up with the context". > In fzct, it solves the specific problem of "VMX code called via RCU, > asynchronously messing up with the context". > There may be other places where (VMX?) code messes with context, *not* > from within an RCU handler, and that would still be an issue. Yes, to expand on what I said earlier: Given that we cannot (at least between now and the release) make it so that developers *never* have to think about syncing state, it seems like the best thing to do is to make coders *always* think about syncing state. Syncing always in the RCU handler means coders can get away sometimes without syncing; which makes it more likely we'll forget in some other circumstance where it matters. But that's my take on general principles; like Dario I wouldn't argue too strongly if someone felt differently. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |