From: Mark Rutland <mark.rutland@arm.com>
To: Paolo Bonzini <pbonzini@redhat.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,
borntraeger@linux.ibm.com, bp@alien8.de, catalin.marinas@arm.com,
chenhuacai@kernel.org, dave.hansen@linux.intel.com,
frankja@linux.ibm.com, frederic@kernel.org, gor@linux.ibm.com,
hca@linux.ibm.com, james.morse@arm.com, jmattson@google.com,
joro@8bytes.org, luto@kernel.org, maz@kernel.org,
mingo@redhat.com, mpe@ellerman.id.au, nsaenzju@redhat.com,
palmer@dabbelt.com, paulmck@kernel.org, paul.walmsley@sifive.com,
peterz@infradead.org, seanjc@google.com, suzuki.poulose@arm.com,
svens@linux.ibm.com, tglx@linutronix.de,
tsbogend@alpha.franken.de, vkuznets@redhat.com,
wanpengli@tencent.com, will@kernel.org
Subject: Re: [PATCH v2 4/7] kvm/mips: rework guest entry logic
Date: Fri, 21 Jan 2022 12:44:05 +0000 [thread overview]
Message-ID: <Yeqqle7lERyreSLi@FVFF77S0Q05N> (raw)
In-Reply-To: <f7413789-f6f2-612e-2323-bf35afdb8a02@redhat.com>
On Thu, Jan 20, 2022 at 06:29:25PM +0100, Paolo Bonzini wrote:
> On 1/20/22 18:15, Mark Rutland wrote:
> > As above, we'll also need the guest_state_{enter,exit}() calls
> > surrounding this (e.g. before that local_irq_enable() at the start of
> > kvm_mips_handle_exit(),
>
> Oh, indeed. And there is also an interrupt-enabled area similar to s390's,
> in both vcpu_run and the exception handler entry point (which falls through
> to the exit handler created by kvm_mips_build_exit). For example:
>
> /* Setup status register for running guest in UM */
> uasm_i_ori(&p, V1, V1, ST0_EXL | KSU_USER | ST0_IE);
> UASM_i_LA(&p, AT, ~(ST0_CU0 | ST0_MX | ST0_SX | ST0_UX));
> uasm_i_and(&p, V1, V1, AT);
> uasm_i_mtc0(&p, V1, C0_STATUS);
> uasm_i_ehb(&p);
>
> I'd rather get rid altogether of the EQS for MIPS.
Ok; I'm not immediately sure how to do that without invasive changes around the
context tracking bits.
Did you have a specific approach in mind, or was that just a general statement?
> > and that needs to happen in noinstr code, etc.
>
> There are bigger problems with instrumentation, because the
> runtime-generated code as far as I can tell is not noinstr.
The generated sequences themselves are not a problem -- they're not
compiler-instrumented, and kprobes will reject them since they live in a
kzalloc()'d buffer which is outside of kernel text.
Those call tlbmiss_handler_setup_pgd(), but that itself is runtime-generated,
and AFAICT doesn't call anything. It is placed within the kernel text, but it
could be blacklisted from kprobes.
Have I missed something there?
Thanks,
Mark.
next prev parent reply other threads:[~2022-01-21 12:44 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-19 10:58 [PATCH v2 0/7] kvm: fix latent guest entry/exit bugs Mark Rutland
2022-01-19 10:58 ` [PATCH v2 1/7] entry: add arch_in_rcu_eqs() Mark Rutland
2022-01-19 17:35 ` Christian Borntraeger
2022-01-21 17:34 ` Nicolas Saenz Julienne
2022-01-19 10:58 ` [PATCH v2 2/7] kvm: add guest_state_{enter,exit}_irqoff() Mark Rutland
2022-01-20 11:00 ` Paolo Bonzini
2022-01-21 17:35 ` Nicolas Saenz Julienne
2022-01-19 10:58 ` [PATCH v2 3/7] kvm/arm64: rework guest entry logic Mark Rutland
2022-01-21 17:37 ` Nicolas Saenz Julienne
2022-01-19 10:58 ` [PATCH v2 4/7] kvm/mips: " Mark Rutland
2022-01-20 11:10 ` Paolo Bonzini
2022-01-20 13:33 ` Mark Rutland
2022-01-20 16:44 ` Mark Rutland
2022-01-20 16:57 ` Paolo Bonzini
2022-01-20 17:15 ` Mark Rutland
2022-01-20 17:17 ` Sean Christopherson
2022-01-20 17:29 ` Paolo Bonzini
2022-01-21 12:44 ` Mark Rutland [this message]
2022-01-19 10:58 ` [PATCH v2 5/7] kvm/riscv: " Mark Rutland
2022-01-20 11:18 ` Paolo Bonzini
2022-01-20 12:56 ` Mark Rutland
2022-01-20 13:13 ` Paolo Bonzini
2022-01-19 10:58 ` [PATCH v2 6/7] kvm/s390: " Mark Rutland
2022-01-19 10:58 ` [PATCH v2 7/7] kvm/x86: " Mark Rutland
2022-01-20 11:20 ` Paolo Bonzini
2022-01-21 17:40 ` Nicolas Saenz Julienne
2022-01-19 18:25 ` [PATCH v2 0/7] kvm: fix latent guest entry/exit bugs Christian Borntraeger
2022-01-19 18:28 ` Christian Borntraeger
2022-01-19 19:22 ` Mark Rutland
2022-01-19 19:30 ` Christian Borntraeger
2022-01-20 11:57 ` Mark Rutland
2022-01-20 12:02 ` Christian Borntraeger
2022-01-20 11:28 ` Paolo Bonzini
2022-01-20 12:03 ` Mark Rutland
2022-01-20 15:14 ` Christian Borntraeger
2022-01-21 9:53 ` Christian Borntraeger
2022-01-21 14:17 ` Christian Borntraeger
2022-01-21 14:30 ` Mark Rutland
2022-01-21 14:42 ` Christian Borntraeger
2022-01-21 15:29 ` Mark Rutland
2022-01-21 15:40 ` Christian Borntraeger
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=Yeqqle7lERyreSLi@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--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=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=frankja@linux.ibm.com \
--cc=frederic@kernel.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=james.morse@arm.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=maz@kernel.org \
--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=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=svens@linux.ibm.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.