[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a3663aaf-14c9-4601-90e2-49650af90d7a@huawei.com>
Date: Wed, 22 Oct 2025 09:35:02 +0800
From: "Liao, Chang" <liaochang1@...wei.com>
To: Marc Zyngier <maz@...nel.org>
CC: <corbet@....net>, <catalin.marinas@....com>, <will@...nel.org>,
<akpm@...ux-foundation.org>, <paulmck@...nel.org>,
<pawan.kumar.gupta@...ux.intel.com>, <mingo@...nel.org>, <bp@...en8.de>,
<kees@...nel.org>, <arnd@...db.de>, <fvdl@...gle.com>, <broonie@...nel.org>,
<oliver.upton@...ux.dev>, <yeoreum.yun@....com>, <james.morse@....com>,
<ardb@...nel.org>, <hardevsinh.palaniya@...iconsignals.io>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] arm64: Add kernel parameter to disable trap EL0 accesses
to IMPDEF regs
在 2025/10/21 20:25, Marc Zyngier 写道:
> On Tue, 21 Oct 2025 12:54:28 +0100,
> Liao Chang <liaochang1@...wei.com> wrote:
>>
>> Add kernel parameter to allow system-wide EL0 access to IMPDEF system
>> regregisters and instructions without trapping to EL1/EL2. Since trap
>> overhead will compromises benefits, and it's even worse in
>> virtualization on CPU where certain IMPDEF registers and instructions
>> are designed for EL0 performance use.
>
> Since you mention virtualisation, I want to be clear: there is no way
> I will consider anything like this for KVM. KVM will always trap and
> UNDEF such register accesses, no matter where they come from (EL0 or
> EL1).
>
> Allowing such registers to be accessed from within a guest would make
> it impossible to context-switch or save/restore the guest correctly.
You've got that right, it seems like both the guest and the host would
need to save and restore those IMDDEF registers with the VM or task
context.The only exception would be if the registers aren't for saving
state or configuration, but instead just act as an interface to trigger
a special CPU function, such as ICC_IAR1.
BR,
Liao, Chang
>
> You can of course do what you want in your downstream kernel or your
> own hypervisor, but I wanted to set the expectations on the upstream
> side.
>
> M.
>
Powered by blists - more mailing lists