Hi again, On Tue, 2021-02-02 at 15:23 +0000, Julien Grall wrote: > (Adding Andrew, Jan, Juergen for visibility) > Thanks! :-)
> On 02/02/2021 15:03, Dario Faggioli wrote: > > On Tue, 2021-02-02 at 07:59 +0000, Julien Grall wrote: > > > The placement in enter_hypervisor_from_guest() doesn't matter too > > > much, > > > although I would consider to call it as a late as possible. > > > > > Mmmm... Can I ask why? In fact, I would have said "as soon as > > possible". > > Because those functions only access data for the current vCPU/domain. > This is already protected by the fact that the domain is running. > Mmm.. ok, yes, I think it makes sense. > By leaving the "quiesce" mode later, you give an opportunity to the > RCU > to release memory earlier. > Yeah. What I wanted to be sure is that we put the CPU "back in the race" :-) before any current or future use of RCUs. > In reality, it is probably still too early as a pCPU can be > considered > 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). To me, however, this looks indeed too complex and difficult to maintain, not only for 4.15 but in general. E.g., suppose we find such a use of RCUs in function foo() called by bar() called by hypervisor_enter_from_guest(). If someone at some points wants to use RCUs in bar(), how does she know that she should also move the call to rcu_quiet_enter() from foo() to there? So, yes, I'll move it a little down, but still within hypervisor_enter_from_guest(). In the meanwhile, I had a quick chat with Jourgen about x86. In fact, I had a look and was not finding a place where to put the rcu_quiet_{exit,enter}() calls as convenient as you have here on ARM. I.e., two nice C functions that we traverse for all kind of guests, for HVM and SVM, etc. Actually, I was quite skeptical about it but, you know, one can hope! Juergen confirmed that there's no such things, so I'll look at the various entry.S files for the proper spots. Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part