Re: kern/55781: more rump fixes

[Ruslan Nikolaev <nruslan_devel%yahoo.com@localhost>]

The following reply was made to PR kern/55781; it has been noted by GNATS.

From: Ruslan Nikolaev <nruslan_devel%yahoo.com@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/55781: more rump fixes
Date: Wed, 4 Nov 2020 12:42:21 -0500

 No, Christos, the point is different here.
 
 Only the bootstrap CPU calls rump_init() even after our change.
 
 However, during rump_init() other CPUs are already scheduled some tasks, 
 so we need to wake them up, we cannot simply wait until rump_init() 
 finishes. If we wake them too early (i.e., before rump_init()), their 
 state will not be properly initialized yet. So, we need to wake them up 
 while in rump_init() but only *after* their state is fully initialized.
 
 So, this is when the bootstrap CPU will call the callback function.
 
 
 Note that other CPUs will not call rump_init(), they will simply 
 schedule some queued tasks.
 
 
 Does it make sense?
 
 
 Ruslan
 
 
 On 11/4/20 10:43 AM, Christos Zoulas wrote:
 >
 >
 >> On Nov 3, 2020, at 8:00 PM, Ruslan Nikolaev <nruslan_devel%yahoo.com@localhost 
 >> <mailto:nruslan_devel%yahoo.com@localhost>> wrote:
 >>
 >> Thanks for the feedback! I'll see if I can fix it. In the meantime, I 
 >> also posted one more SMP-related patch: kern/55781
 >>
 >> We also have rump (glue) files for new drivers such as ixgbe, nvme, 
 >> etc -- we will post them as well.
 >
 > How does 55781 work? doesn't "rump_inited" prevent the function to be 
 > entered from other cpus?
 >
 > https://github.com/ssrg-vt/src-netbsd/blob/168bf207298443ea437f83cd5594d8907dd0be97/sys/rump/librump/rumpkern/rump.c#L238
 >
 > christos