From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B5EE6AA.5030807@domain.hid> Date: Tue, 26 Jan 2010 13:57:14 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B5EB6D2.9040206@domain.hid> <4B5ED445.1040908@domain.hid> <4B5ED4F7.4030006@domain.hid> <4B5EE589.2040406@domain.hid> In-Reply-To: <4B5EE589.2040406@domain.hid> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [PATCH v2] x86: Fix root domain state restoring on exception return List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wolfgang Mauerer Cc: adeos-main , xenomai-core Wolfgang Mauerer wrote: > Jan Kiszka wrote: >> Wolfgang Mauerer wrote: >>> Jan Kiszka wrote: >>>> If we enter __ipipe_handle_exception over a non-root domain and leave it >>>> due to migration in the event handler over root, we must not restore the >>>> root domain state so far saved on entry. This caused subtle pipeline >>>> state corruptions. Instead, only save and restore them if we were >>>> entering over root. >>>> >>>> However, the x86-32 regs.flags fixup is required nevertheless to take >>>> care of mismatches between the root domain state and the hardware flags >>>> on entry. That may happen if we fault in the iret path. But also in this >>>> case we must not restore an invalid root domain state. So if we entered >>>> over non-root, pick up the input for __fixup_if from the root domain >>>> after running the ipipe handler. >>>> >>>> Signed-off-by: Jan Kiszka >>>> --- >>>> >>>> Next try. But this time I think I finally understood what scenario >>>> __fixup_if is actually fixing. Please correct me if I'm still missing >>>> one. >>> looks good - it works for my test cases and solves the problems with >>> the hw/pipeline state mismatch during early bootup. But do you happen >>> to have any scenario at hand with ipipe_domain_root_p && !root_entry? >>> Couldn't trigger this one yet so only the raw_irqs_disabled_flags >>> fixup is excercised, though I guess it can't do any harm to really >>> ensure that the explanation fits reality this time... >> You mean non-root entry -> migration -> __fixup_if? In that case we pick >> up the flags for fixup _after_ the migration (raw_irqs_disabled()). Or >> what do you mean? > > (...) >>>> - if (unlikely(!ipipe_root_domain_p)) { >>>> + if (likely(ipipe_root_domain_p)) { >>>> + /* >>>> + * 32-bit: In case we faulted in the iret path, regs.flags do >>>> + * not match the root domain state as the low-level return >>>> + * code will evaluate it. Fix this up, either by the root >>>> + * state sampled on entry or, if we migrated to root, with the >>>> + * current state. >>>> + */ >>>> + __fixup_if(root_entry ? raw_irqs_disabled_flags(flags) : >>>> + raw_irqs_disabled(), regs); > > I'm referring to the case that evaluates to > __fixup_if(raw_irqs_disabled(), regs); That is, something that > triggers > > if (!root_entry) > do_something(); > > Could be that we're talking about to the same case, although I'm not > sure ;-) Right, that's the case I described above. What problem do you precisely see or what concerns to you have about the suggested behavior? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux