On Tue, May 07, 2024 at 10:55:54AM -0700, Sean Christopherson wrote:
> On Fri, May 03, 2024, Paul E. McKenney wrote:
> > On Fri, May 03, 2024 at 02:29:57PM -0700, Sean Christopherson wrote:
> > > So if we're comfortable relying on the 1 second timeout to guard against a
> > > misbehaving userspace, IMO we might as well fully rely on that guardrail. I.e.
> > > add a generic PF_xxx flag (or whatever flag location is most appropriate) to let
> > > userspace communicate to the kernel that it's a real-time task that spends the
> > > overwhelming majority of its time in userspace or guest context, i.e. should be
> > > given extra leniency with respect to rcuc if the task happens to be interrupted
> > > while it's in kernel context.
> >
> > But if the task is executing in host kernel context for quite some time,
> > then the host kernel's RCU really does need to take evasive action.
>
> Agreed, but what I'm saying is that RCU already has the mechanism to do so in the
> form of the 1 second timeout.
Plus RCU will force-enable that CPU's scheduler-clock tick after about
ten milliseconds of that CPU not being in a quiescent state, with
the time varying depending on the value of HZ and the number of CPUs.
After about ten seconds (halfway to the RCU CPU stall warning), it will
resched_cpu() that CPU every few milliseconds.
> And while KVM does not guarantee that it will immediately resume the guest after
> servicing the IRQ, neither does the existing userspace logic. E.g. I don't see
> anything that would prevent the kernel from preempting the interrupt task.
Similarly, the hypervisor could preempt a guest OS's RCU read-side
critical section or its preempt_disable() code.
Or am I missing your point?
> > On the other hand, if that task is executing in guest context (either
> > kernel or userspace), then the host kernel's RCU can immediately report
> > that task's quiescent state.
> >
> > Too much to ask for the host kernel's RCU to be able to sense the
> > difference? ;-)
>
> KVM already notifies RCU when its entering/exiting an extended quiescent state,
> via __ct_user_{enter,exit}().
>
> When handling an IRQ that _probably_ triggered an exit from the guest, the CPU
> has already exited the quiescent state. And AFAIK, that can't be safely changed,
> i.e. KVM must note the context switch before enabling IRQs.
Whew!!! ;-)
Just to make sure that I understand, is there any part of the problem
to be solved that does not involve vCPU preemption?
Thanx, Paul
