[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Null scheduler and vwfi native problem

On 03.02.21 12:20, Julien Grall wrote:
Hi Juergen,

On 03/02/2021 11:00, Jürgen Groß wrote:
On 03.02.21 10:19, Julien Grall wrote:

On 03/02/2021 07:31, Dario Faggioli wrote:
On Tue, 2021-02-02 at 15:23 +0000, Julien Grall wrote:
In reality, it is probably still too early as a pCPU can be
quiesced until a call to rcu_lock*() (such rcu_lock_domain()).

Well, yes, in theory, we could track down which is the first RCU read
side crit. section on this path, and put the call right before that (if
I understood what you mean).

Oh, that's not what I meant. This will indeed be far more complex than I originally had in mind.

AFAIU, the RCU uses critical section to protect data. So the "entering" could be used as "the pCPU is not quiesced" and "exiting" could be used as "the pCPU is quiesced".

The concern with my approach is we would need to make sure that Xen correctly uses the rcu helpers. I know Juergen worked on that recently, but I don't know whether this is fully complete.

I think it is complete, but I can't be sure, of course.

One bit missing (for catching some wrong uses of the helpers) is this


I don't remember why it hasn't been taken, but I think there was a
specific reason for that.

Looking at v8 and the patch is suitably reviewed by Jan. So I am a bit puzzled to why this wasn't committed... I had to go to v6 and notice the following message:

"albeit to be honest I'm not fully convinced we need to go this far."

Was the implication that his reviewed-by was conditional to someone else answering to the e-mail?

I have no record for that being the case.

Patches 1-3 of that series were needed for getting rid of
stop_machine_run() in rcu handling and to fix other problems. Patch 4
was adding some additional ASSERT()s for making sure no potential
deadlocks due to wrong rcu usage could creep in again.

Patch 5 was more a "nice to have" addition in order to avoid any
wrong usage of rcu which should have no real negative impact on the
system stability.

So I believe Jan as the committer didn't want to commit it himself, but
was fine with the overall idea and implementation.

I still think for code sanity it would be nice, but I was rather busy
with Xenstore and event channel security work at that time, so I didn't
urge anyone to take this patch.


Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.