On Mon, Jan 13, 2020 at 07:11:21PM +0000, Andrew Doran wrote: > On Mon, Jan 13, 2020 at 07:36:41PM +0100, Manuel Bouyer wrote: > > > On Mon, Jan 13, 2020 at 06:33:08PM +0000, Andrew Doran wrote: > > > On Mon, Jan 13, 2020 at 05:43:51PM +0100, Manuel Bouyer wrote: > > > > > > > On Mon, Jan 13, 2020 at 04:59:50PM +0100, Manuel Bouyer wrote: > > > > > It also sets rsp and rbp. I think rbp is not set by anything else, at > > > > > last > > > > > in the Xen case. > > > > > The different rbp value would explain why in one case we hit a > > > > > KASSERT() > > > > > in lwp_startup later. > > > > > But I don't know what pcb_rbp contains; I couldn't find where the pcb > > > > > for > > > > > idlelwp is initialized. > > > > > > > > I tried the attached patch, which should set rsp/rbp as cpu_switchto() > > > > does. It doens't cause the lwp_startup() KASSERT as calling > > > > cpu_switchto() > > > > does; it also doesn't change the scheduler behavior. > > > > > > Wait - do you mean that everything works now? Or that everything still > > > runs > > > on CPU0? > > > > No, everything still runs on CPU0 > > Hmm, I don't understand why. I'll set up Xen and try it out. It might take > me a day or two.
OK thanks. > [...] > > The assertion in lwp_startup() is because I made MI changes so that prevlwp > is never NULL when calling cpu_switchto(), when fixing some bugs problems MP > support on !x86 and make things more correct. lwp_startup()/mi_switch() now > need to unlock prevlwp after it is finished in cpu_switchto(). I never > expected anybody but mi_switch() to call cpu_switchto(). OK, so I removed the call to cpu_switchto() before idle_loop(), and added a few KASSERTS. I guess you can back out the prev == NULL case from cpu_switchto(). -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --