From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org, aleksandar.qemu.devel@gmail.com,
alexandru.elisei@arm.com, anup.patel@wdc.com,
aou@eecs.berkeley.edu, atish.patra@wdc.com,
benh@kernel.crashing.org, borntraeger@linux.ibm.com,
bp@alien8.de, catalin.marinas@arm.com, chenhuacai@kernel.org,
dave.hansen@linux.intel.com, david@redhat.com,
frankja@linux.ibm.com, frederic@kernel.org, gor@linux.ibm.com,
hca@linux.ibm.com, imbrenda@linux.ibm.com, james.morse@arm.com,
jmattson@google.com, joro@8bytes.org, kvm@vger.kernel.org,
mingo@redhat.com, mpe@ellerman.id.au, nsaenzju@redhat.com,
palmer@dabbelt.com, paulmck@kernel.org, paulus@samba.org,
paul.walmsley@sifive.com, pbonzini@redhat.com, seanjc@google.com,
suzuki.poulose@arm.com, tglx@linutronix.de,
tsbogend@alpha.franken.de, vkuznets@redhat.com,
wanpengli@tencent.com, will@kernel.org
Subject: Re: [PATCH 1/5] kvm: add exit_to_guest_mode() and enter_from_guest_mode()
Date: Thu, 13 Jan 2022 11:55:11 +0000 [thread overview]
Message-ID: <87pmov97fk.wl-maz@kernel.org> (raw)
In-Reply-To: <YeAGit8JTO/AmAaU@FVFF77S0Q05N>
On Thu, 13 Jan 2022 11:01:30 +0000,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Tue, Jan 11, 2022 at 05:54:59PM +0000, Marc Zyngier wrote:
> > Hi Mark,
> >
> > On Tue, 11 Jan 2022 15:35:35 +0000,
> > Mark Rutland <mark.rutland@arm.com> wrote:
[...]
> > > +/*
> > > + * Enter guest context and enter an RCU extended quiescent state.
> > > + *
> > > + * This should be the last thing called before entering the guest, and must be
> > > + * called after any potential use of RCU (including any potentially
> > > + * instrumented code).
> >
> > nit: "the last thing called" is terribly ambiguous. Any architecture
> > obviously calls a ****load of stuff after this point. Should this be
> > 'the last thing involving RCU' instead?
>
> I agree this is unclear and I struggled to fing good wording for this. Is the
> following any better?
>
> /*
> * Enter guest context and enter an RCU extended quiescent state.
> *
> * Between guest_context_enter_irqoff() and guest_context_exit_irqoff() it is
> * unsafe to use any code which may directly or indirectly use RCU, tracing
> * (including IRQ flag tracing), or lockdep. All code in this period must be
> * non-instrumentable.
> */
>
> If that's good I can add similar to guest_context_exit_irqoff().
Yes, that's much clearer, thanks.
>
> [...]
>
> > > +/**
> > > + * exit_to_guest_mode - Fixup state when exiting to guest mode
> > > + *
> > > + * This is analagous to exit_to_user_mode(), and ensures we perform the
> > > + * following in order:
> > > + *
> > > + * 1) Trace interrupts on state
> > > + * 2) Invoke context tracking if enabled to adjust RCU state
> > > + * 3) Tell lockdep that interrupts are enabled
> >
> > nit: or rather, are about to be enabled? Certainly on arm64, the
> > enable happens much later, right at the point where we enter the guest
> > for real.
>
> True; I'd cribbed the wording from the comment block above exit_to_user_mode(),
> but I stripped the context that made that clear. I'll make that:
>
> /**
> * exit_to_guest_mode - Fixup state when exiting to guest mode
> *
> * Entry to a guest will enable interrupts, but the kernel state is
> * interrupts disabled when this is invoked. Also tell RCU about it.
> *
> * 1) Trace interrupts on state
> * 2) Invoke context tracking if enabled to adjust RCU state
> * 3) Tell lockdep that interrupts are enabled
> *
> * Invoked from architecture specific code before entering a guest.
> * Must be called with interrupts disabled and the caller must be
> * non-instrumentable.
> * The caller has to invoke guest_timing_enter_irqoff() before this.
> *
> * Note: this is analagous to exit_to_user_mode().
nit: analogous
> */
>
> ... with likewise for enter_from_guest_mode(), if that's clear enough?
Yes, that's great.
Thanks again,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-01-13 11:55 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-11 15:35 [PATCH 0/5] kvm: fix latent guest entry/exit bugs Mark Rutland
2022-01-11 15:35 ` [PATCH 1/5] kvm: add exit_to_guest_mode() and enter_from_guest_mode() Mark Rutland
2022-01-11 17:54 ` Marc Zyngier
2022-01-13 11:01 ` Mark Rutland
2022-01-13 11:55 ` Marc Zyngier [this message]
2022-01-13 13:01 ` Mark Rutland
2022-01-13 20:32 ` Sean Christopherson
2022-01-14 11:48 ` Mark Rutland
2022-01-14 16:11 ` Sean Christopherson
2022-01-18 13:01 ` Mark Rutland
2022-01-11 15:35 ` [PATCH 2/5] kvm/arm64: rework guest entry logic Mark Rutland
2022-01-11 17:55 ` Marc Zyngier
2022-01-13 11:17 ` Mark Rutland
2022-01-13 11:43 ` Marc Zyngier
2022-01-13 12:58 ` Mark Rutland
2022-01-11 15:35 ` [PATCH 3/5] kvm/mips: " Mark Rutland
2022-01-11 15:35 ` [PATCH 4/5] kvm/riscv: " Mark Rutland
2022-01-11 15:35 ` [PATCH 5/5] kvm/x86: " Mark Rutland
2022-01-13 20:50 ` Sean Christopherson
2022-01-14 12:05 ` Mark Rutland
2022-01-14 16:49 ` Sean Christopherson
2022-01-11 18:47 ` [PATCH 0/5] kvm: fix latent guest entry/exit bugs Palmer Dabbelt
2022-01-13 15:20 ` Christian Borntraeger
2022-01-14 12:19 ` Mark Rutland
2022-01-14 12:29 ` Christian Borntraeger
2022-01-14 13:32 ` Mark Rutland
2022-01-14 13:51 ` Christian Borntraeger
2022-01-14 15:19 ` Mark Rutland
2022-01-17 17:45 ` Paolo Bonzini
2022-01-18 12:02 ` Mark Rutland
2022-01-18 12:08 ` Christian Borntraeger
2022-01-18 12:42 ` Christian Borntraeger
2022-01-18 13:12 ` Mark Rutland
2022-01-18 14:15 ` Christian Borntraeger
2022-01-18 15:43 ` Mark Rutland
2022-01-18 16:09 ` Sven Schnelle
2022-01-18 17:50 ` Mark Rutland
2022-01-18 18:12 ` Mark Rutland
2022-01-19 6:41 ` Sven Schnelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pmov97fk.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=alexandru.elisei@arm.com \
--cc=anup.patel@wdc.com \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@wdc.com \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=frederic@kernel.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=james.morse@arm.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=nsaenzju@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=paulmck@kernel.org \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.