linux-kernel - Re: RCU treating guest mode just like it does user-mode execution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110818002513.GP2419@linux.vnet.ibm.com>
Date:	Wed, 17 Aug 2011 17:25:13 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Gleb Natapov <gleb@...hat.com>
Cc:	linux-kernel@...r.kernel.org, avi@...hat.com, mtosatti@...hat.com,
	kvm@...r.kernel.org
Subject: Re: RCU treating guest mode just like it does user-mode execution

On Thu, Aug 18, 2011 at 02:55:29AM +0300, Gleb Natapov wrote:
> On Wed, Aug 17, 2011 at 03:05:20PM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 18, 2011 at 12:50:15AM +0300, Gleb Natapov wrote:
> > > On Wed, Aug 17, 2011 at 01:43:27PM -0700, Paul E. McKenney wrote:
> > > > Hello, Gleb,
> > > > 
> > > > I was looking at KVM's call to rcu_virt_note_context_switch()
> > > > in kvm_guest_enter(), and noting the comment talking about treating
> > > > guest mode like user-mode execution is.  One difference between RCU's
> > > > treatment of KVM guest execution and user-mode execution is that RCU
> > > > notes a context switch only at the beginning of KVM guest execution,
> > > > but notes user-mode execution at every scheduling-clock interrupt.
> > > > 
> > > > Does it make sense to also note KVM guest execution on each
> > > > scheduling-clock interrupt?  One reason it might not make sense is
> > > > if interrupts from KVM guest execution appear to rcu_check_callbacks()
> > > > as interrupts from user-mode execution.  (Do they?  Given that people
> > > > are reporting RCU CPU stall warnings in virtualized environments, I
> > > > am beginning to suspect that the answer is "no".)
> > > > 
> > > The answer is "no" because any interrupt kicks cpu out of a guest mode, so
> > > it appears to be in the kernel for RCU. Do people still reporting RCU
> > > stalls even with the my patch?
> > > 
> > > > If KVM guest execution does not appear as user-mode execution to
> > > > rcu_check_callback(), I would consider doing the following:
> > > > 
> > > > 1.	Rename rcu_virt_note_context_switch() to something like
> > > > 	rcu_guest_execution_start().
> > > > 
> > > > 2.	Place a call to a new rcu_guest_execution_end() in
> > > > 	kvm_guest_exit().
> > > > 
> > > > 3.	Make rcu_guest_execution_start() and rcu_guest_execution_end()
> > > > 	set and clear a new per-CPU variable.
> > > There is such variable already: current->flags & PF_VCPU.
> > 
> > Good to know, thank you!
> > 
> > > > 4.	Make rcu_check_callbacks() check this per-CPU variable in
> > > > 	much the same way that it currently checks its "user"
> > > > 	argument, aside from needing to check that the CPU is
> > > > 	not in an interrupt handler or some such.
> > > > 
> > > > Of course, some thought is required to make sure that the checks for
> > > > executing in an interrupt handler actually cover all of the needed
> > > > situations, but so it goes!
> > > > 
> > > > Thoughts?
> > > 
> > > I wonder why it will be better than current situation. After cpu leaves
> > > a guest mode there are only three options. It will either go to
> > > userspace, execute schedule or go back to guest mode. At all those cases
> > > RCU should note quiescent state.
> > 
> > Might be that the current state is optimal.  That would be a good thing.
> > 
> > But if a CPU stays in guest mode for (say) 30 seconds, it will have
> > called schedule() every jiffy in the meantime?  In other words, if
> > a CPU stays in guest mode for a long time, how does RCU know that
> > this CPU is in an extended quiescent state?
> > 
> Wouldn't scheduling-clock interrupt kick vcpu out of a guest mode much
> earlier then 30 seconds?

The scheduling-clock interrupt would happen, but I do not know whether
or not it would kick the vcpu out of guest mode in such a way that
would result in RCU thinking that the CPU has passed through a quiescent
state.

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/