* [PATCH v3 1/2] arm64: Add override for MMFR1.HAFDBS
From: Robin Murphy @ 2026-07-27 12:03 UTC (permalink / raw)
To: will, catalin.marinas, joro; +Cc: jpb, jgg, iommu, linux-arm-kernel
In-Reply-To: <cover.1785153415.git.robin.murphy@arm.com>
In general it might be nice to have the ability to disable hardware
access/dirty bit management for debugging or performance comparison
purposes without having to rebuild the kernel. However once FEAT_HAFT
comes into the picture we also start to have a real functional concern
where the decision to use HAFT based on the boot CPUs can prevent SVA
or late-onlining if SMMUs/CPUs are later found to lack HAFT support.
To that end, add the appropriate MMFR1 override, with an easy "nohaft"
alias for the significant case, partly since the feature/field naming
isn't the most obvious, but also so it could potentially be redirected
in future if someone wanted to attempt a higher-level means of turning
off just HAFT usage independently from FEAT_HDBSS.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v3: No change.
Documentation/admin-guide/kernel-parameters.txt | 3 +++
arch/arm64/kernel/pi/idreg-override.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22..7f23e5b8dc44 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -565,6 +565,9 @@ Kernel parameters
arm64.nogcs [ARM64] Unconditionally disable Guarded Control Stack
support
+ arm64.nohaft [ARM64] Unconditionally disable Hardware managed Access
+ Flag for Table descriptors support
+
arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory
Set instructions support
diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index bc57b290e5e7..0e051fec5afe 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c
@@ -64,6 +64,7 @@ static const struct ftr_set_desc mmfr1 __prel64_initconst = {
.override = &id_aa64mmfr1_override,
.fields = {
FIELD("vh", ID_AA64MMFR1_EL1_VH_SHIFT, mmfr1_vh_filter),
+ FIELD("hafdbs", ID_AA64MMFR1_EL1_HAFDBS_SHIFT, NULL),
{}
},
};
@@ -246,6 +247,7 @@ static const struct {
{ "arm64.nomte", "id_aa64pfr1.mte=0" },
{ "nokaslr", "arm64_sw.nokaslr=1" },
{ "rodata=off", "arm64_sw.rodataoff=1" },
+ { "arm64.nohaft", "id_aa64mmfr1.hafdbs=2" },
{ "arm64.nolva", "id_aa64mmfr2.varange=0" },
{ "arm64.no32bit_el0", "id_aa64pfr0.el0=1" },
{ "arm64.nompam", "id_aa64pfr0.mpam=0 id_aa64pfr1.mpam_frac=0" },
--
2.54.0.dirty
^ permalink raw reply related
* [PATCH v3 0/2] iommu/arm-smmu-v3: Fix SVA vs. HAFT issues
From: Robin Murphy @ 2026-07-27 12:03 UTC (permalink / raw)
To: will, catalin.marinas, joro; +Cc: jpb, jgg, iommu, linux-arm-kernel
v1: https://lore.kernel.org/all/878cd6bcbbe2d5677d2f63da13294c148268552c.1782927917.git.robin.murphy@arm.com/
v2: https://lore.kernel.org/all/cover.1784814923.git.robin.murphy@arm.com/
Further to v2, work around the contentious CD update.
Thanks,
Robin.
Robin Murphy (2):
arm64: Add override for MMFR1.HAFDBS
iommu/arm-smmu-v3: Add HAFT support for SVA
.../admin-guide/kernel-parameters.txt | 3 +++
arch/arm64/kernel/pi/idreg-override.c | 2 ++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 24 +++++++++++--------
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 +++
5 files changed, 30 insertions(+), 11 deletions(-)
--
2.54.0.dirty
^ permalink raw reply
* RE: [PATCH v2 2/2] serial: amba-pl011: keep console clock enabled for atomic writes
From: John Ogness @ 2026-07-27 11:59 UTC (permalink / raw)
To: Toshiyuki Sato (Fujitsu), 'Karl Mehltretter'
Cc: Russell King, Greg Kroah-Hartman, Jiri Slaby,
linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev, Sebastian Andrzej Siewior,
Petr Mladek, Steven Rostedt, Clark Williams,
Toshiyuki Sato (Fujitsu)
In-Reply-To: <TYXPR01MB15199DA567AF4541DD79359FBD7CC2@TYXPR01MB15199.jpnprd01.prod.outlook.com>
Hi Toshiyuki,
On 2026-07-27, "Toshiyuki Sato (Fujitsu)" <fj6611ie@fujitsu.com> wrote:
> Regarding Petr's comment [1] as well, I'm concerned about the
> potential impact when the clk remains enabled during periods without
> console output.
Can you elaborate on your concerns? Do you actually need such low-power
_and_ kernel logging directly on serial?
> When creating nbcon patch, I saw a similar patch [2] from the past.
> Have you considered coordinating with the clk subsystem implementation
> for this?
AFAICT there was no real justification for enabling clocks per write
other than because we can. A lot has changed since 2013 and neither
spin_locks nor raw_spin_locks are appropriate because atomic printing
can occur in _any_ context (including NMI's).
If the amba-pl011 insists on enabling clocks per write, I would
recommend not implementing the write_atomic() callback. Since I assume a
significant amount of users _will_ want atomic printing support, perhaps
you can add a Kconfig to toggle building with clock-disabling and no
atomic, or clock-always-on and atomic.
Note that there is also CON_NBCON_ATOMIC_UNSAFE available, if the driver
wants to somehow blindly enable clocks on panic in order to unsafely
dump panic logs.
John Ogness
> [1] https://lore.kernel.org/all/al4KdsU9YLOmwDoV@pathway.suse.cz/
> [2] https://lore.kernel.org/all/1359475526-17523-1-git-send-email-walimisdev@gmail.com/
^ permalink raw reply
* Re: [PATCH v3 06/11] nvmem: imx-ocotp-ele: Use __free(kfree) in imx_ocotp_reg_read()
From: Frieder Schrempf @ 2026-07-27 11:51 UTC (permalink / raw)
To: Frank Li, Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Pankaj Gupta, Peng Fan (OSS),
devicetree, imx, linux-arm-kernel, linux-kernel, linux
In-Reply-To: <amJglJGsfw3rjNPL@SMW015318>
On 23.07.26 20:42, Frank Li wrote:
> On Thu, Jul 23, 2026 at 09:27:28AM +0200, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> This is useful to make sure the buffer is always freed when
>> its scope ends and makes the code slightly easier to read.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> ---
>> drivers/nvmem/imx-ocotp-ele.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/nvmem/imx-ocotp-ele.c b/drivers/nvmem/imx-ocotp-ele.c
>> index 9d3f94e35508..47ee6bd176a3 100644
>> --- a/drivers/nvmem/imx-ocotp-ele.c
>> +++ b/drivers/nvmem/imx-ocotp-ele.c
>> @@ -5,6 +5,7 @@
>> * Copyright 2023 NXP
>> */
>>
>> +#include <linux/cleanup.h>
>> #include <linux/device.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> @@ -68,10 +69,10 @@ static int imx_ocotp_reg_read(void *context, unsigned int offset, void *val, siz
>> {
>> struct imx_ocotp_priv *priv = context;
>> void __iomem *reg = priv->base + priv->data->reg_off;
>> + void *p __free(kfree) = NULL;
>
> according to cleanup.h, it should declare at where assign
>
> void *p __free(free) = kzalloc(num_bytes, GFP_KERNEL);
>
As far as I can see, NULL should be perfectly fine as an initializer, as
we need to calculate num_bytes first.
>
>> u32 count, index, num_bytes;
>> enum fuse_type type;
>> u32 *buf;
>> - void *p;
>> int i;
>> u8 skipbytes;
>>
>> @@ -108,8 +109,6 @@ static int imx_ocotp_reg_read(void *context, unsigned int offset, void *val, siz
>>
>> mutex_unlock(&priv->lock);
>>
>> - kfree(p);
>> -
>> return 0;
>> };
>>
>>
>> --
>> 2.55.0
>>
>>
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: mediatek: alias all enabled serial ports
From: Carlo Caione @ 2026-07-27 11:49 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Carlo Caione, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
Greg Kroah-Hartman, Jiri Slaby
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-serial, dlechner, jstephan
In-Reply-To: <a3298120-f5be-4a8a-bb71-1d6923a28d6c@collabora.com>
On Mon Jul 27, 2026 at 1:30 PM CEST, AngeloGioacchino Del Regno wrote:
> On 7/27/26 09:38, Carlo Caione wrote:
>> On most MediaTek boards only serial0 is aliased, so the remaining
>> enabled uarts get first-free ttyS line numbers from the 8250 core in
>> probe order. When the console uart defers on its clocks another uart can
>> win line 0: console=ttyS0 then ends up on the wrong port and the boot
>> looks like a hang on the serial console, depending on probe order.
>>
>> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
>> ---
>> arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts | 1 +
>> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 1 +
>> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 2 ++
>> arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts | 2 ++
>> arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
>> arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts | 4 ++++
>> arch/arm64/boot/dts/mediatek/mt8195-demo.dts | 1 +
>> arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 2 ++
>> arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi | 2 ++
>> arch/arm64/boot/dts/mediatek/mt8390-grinn-genio-sbc.dtsi | 2 ++
>> arch/arm64/boot/dts/mediatek/mt8390-tungsten-smarc.dtsi | 2 ++
>> arch/arm64/boot/dts/mediatek/mt8395-genio-common.dtsi | 1 +
>> 12 files changed, 21 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
>> index 0e086dd487d9..63659e240b1d 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
>> @@ -20,6 +20,7 @@ aliases {
>> mmc2 = &mmc2;
>> serial0 = &uart0;
>> serial1 = &uart1;
>> + serial2 = &uart2;
>> };
>>
>> backlight_lcd0: backlight {
>> diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
>> index 8c3e2e2578bc..7bccad118d24 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
>> @@ -20,6 +20,7 @@ / {
>>
>> aliases {
>> serial0 = &uart0;
>> + serial2 = &uart2;
>
> Why is that serial2 and not serial1 = &uart2?
To tie the alias number to the SoC uart index instead of to the set of
currently-enabled ports.
The problem is that uart1 exists on mt7622 but is disabled. With serial1
= &uart2, the day uart1 gets enabled the aliases have to be renumbered
and uart2 silently moves from ttyS1 to ttyS2 (or we have to again mix
serial and uart number).
Also in general it keeps ttyS<N> matching the schematics' UART<N>.
Ciao,
--
Carlo Caione
^ permalink raw reply
* Re: [PATCH] perf: arm_pmu_acpi: Get rid of the edge-triggered interrupt oddity
From: Zenghui Yu @ 2026-07-27 11:40 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linux-arm-kernel, linux-kernel, Mark Rutland, Will Deacon
In-Reply-To: <20260725162627.145301-1-maz@kernel.org>
On 2026/7/26 0:26, Marc Zyngier wrote:
> The ACPI spec bizarrely indicates that the PMU interrupt can be
> edge-triggered, which contradicts the very basics of the PMU
> architecture (SW is required to clear the interrupt condition for
> the level to drop).
>
> Remove the code parsing this flag and always flag the interrupt
> as level triggered, no matter what firmware says.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/perf/arm_pmu_acpi.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Thanks,
Zenghui
^ permalink raw reply
* Re: [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool()
From: Leon Romanovsky @ 2026-07-27 11:40 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V, iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy,
Dan Williams, Xu Yilun, linuxppc-dev, linux-s390,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Alexander Gordeev, Gerald Schaefer,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Sven Schnelle, x86, stable, Michael Kelley
In-Reply-To: <ambdXXcfgK+cxqxa@ziepe.ca>
On Mon, Jul 27, 2026 at 01:23:57AM -0300, Jason Gunthorpe wrote:
> On Sun, Jul 26, 2026 at 11:17:53AM +0300, Leon Romanovsky wrote:
>
> > Currently, the phys type universally describes memory and can be
> > reliably translated into any required representation. It is the most
> > fundamental type we have.
>
> You cannot go from phys to page reliably unless you make assumptions
> about the phys, that's the whole issue here. If the callchain expects
> and intends to use a page it should really stay in a page and not take
> a side trip to phys.
>
> I agree it would help to have some helpers that were more phys based
> for the callchains that want that since we are mixing two fairly
> different activities in these functions..
Yes, we are agreed here.
>
> But making phys the only output out of the pool isn't going to be an
> improvement.
I don't know, phys was natural suggestion due to multiple
page_to_phys/phys_to_page conversions down the road.
>
> BTW how does a struct page even work for decrypted memory? You can't
> actually use it that way right? If you try to access it then you'll
> get the wrong IPA and it should explode?
>
> Maybe we should be blocking the struct page path entirely for CC
> shared?
It will simplify things. Ultimately, this series demonstrates that
CC users must be aware of the memory attribute (CC_SHARED) and struct
page is too generic.
Thanks
>
> Jason
>
^ permalink raw reply
* Re: [PATCH v6 00/13] drm/bridge: it6505: DP audio support + shared-DAI hw_params fix
From: AngeloGioacchino Del Regno @ 2026-07-27 11:34 UTC (permalink / raw)
To: Daniel Golle, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Matthias Brugger, Allen Chen, Hermes Wu,
Pin-yen Lin, dri-devel, linux-kernel, linux-arm-kernel,
linux-mediatek, Chen-Yu Tsai
In-Reply-To: <cover.1784947240.git.daniel@makrotopia.org>
On 7/25/26 04:57, Daniel Golle wrote:
> Revive HDMI/DP audio support for the it6505, originally posted by
> Jiaxin Yu [1], rebased onto current -next with the review feedback
> addressed: &client->dev is gone (the driver gained it6505->dev) and
> "#sound-dai-cells" has since been added by commit 325af1bef5b9
> ("dt-bindings: display: bridge: it6505: Add #sound-dai-cells").
>
> Patches 1-11 fix pre-existing bugs found during review of earlier
> versions of this series; they carry Fixes: tags and are ordered first
> so stable trees can pick them.
>
> Patch 12 wires up the it6505 audio helpers via hdmi_codec_ops,
> unblocking the mt8186-mt6366 sound card which references it6505 as
> the I2S3 codec. Patch 13 makes hw_params succeed with no display
> attached, needed when the I2S bus is shared with another codec as on
> MT8186 "steelix" Chromebooks, where the speaker path must keep
> working regardless of the it6505 link state.
>
> Tested on a MT8186 (google,steelix) Chromebook: the sound card comes
> up, speakers, microphone and headset jack work. HDMI/DP audio output
> itself could not be tested for lack of a suitable adapter cable.
>
Whole series is
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioachcino Del Regno <angelogioacchino.delregno@collabora.com> #
Steelix Chromebook
Cheers,
Angelo
> [1] https://lore.kernel.org/all/20230730180803.22570-4-jiaxin.yu@mediatek.com/
^ permalink raw reply
* Re: [PATCH v2 2/2] soc: fsl: dpio: Use scope-based resource management in dpaa2_io_create()
From: Dan Carpenter @ 2026-07-27 11:32 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-arm-kernel, linuxppc-dev, Christophe Leroy, Roy Pledge,
LKML, kernel-janitors
In-Reply-To: <f47abd6e-9337-404c-a24f-39a9dd7454d2@web.de>
On Mon, Jul 06, 2026 at 12:40:09PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 6 Jul 2026 11:18:39 +0200
>
> Scope-based resource management became supported for some
> programming interfaces by contributions of Peter Zijlstra on 2023-05-26.
> See also the commit 54da6a0924311c7cf5015533991e44fb8eb12773 ("locking:
> Introduce __cleanup() based infrastructure").
>
> * Thus use the attribute “__free(kfree)”.
>
> * Omit two kfree() calls accordingly.
>
> * Reduce the scopes for the local variables “obj”
> and “qman_256_cycles_per_ns”.
Why? No one does this except bcachefs and that was removed.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: fsl: dpio: Use scope-based resource management in dpaa2_io_store_create()
From: Dan Carpenter @ 2026-07-27 11:31 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-arm-kernel, linuxppc-dev, Christophe Leroy, Roy Pledge,
LKML, kernel-janitors
In-Reply-To: <6607bb4e-a747-4791-b93f-f82f26e4a334@web.de>
On Mon, Jul 06, 2026 at 12:38:08PM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 6 Jul 2026 10:34:43 +0200
>
> Scope-based resource management became supported for some
> programming interfaces by contributions of Peter Zijlstra on 2023-05-26.
> See also the commit 54da6a0924311c7cf5015533991e44fb8eb12773 ("locking:
> Introduce __cleanup() based infrastructure").
>
> * Thus use the attribute “__free(kfree)”.
>
> * Reduce the scope for the local variable “ret”.
>
> * Omit two kfree() calls accordingly.
>
> * Omit the local variable “size” (for another memory allocation).
Why? This seems unrelated...
>
> * Use the macro call “return_ptr(ret)” at the end.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/soc/fsl/dpio/dpio-service.c | 15 ++++-----------
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/soc/fsl/dpio/dpio-service.c b/drivers/soc/fsl/dpio/dpio-service.c
> index 317ca50b0c2b..b252c3c7fa65 100644
> --- a/drivers/soc/fsl/dpio/dpio-service.c
> +++ b/drivers/soc/fsl/dpio/dpio-service.c
> @@ -652,23 +652,17 @@ EXPORT_SYMBOL_GPL(dpaa2_io_service_acquire);
Missing #include <linux/cleanup.h>
> struct dpaa2_io_store *dpaa2_io_store_create(unsigned int max_frames,
> struct device *dev)
> {
> - struct dpaa2_io_store *ret;
> - size_t size;
> -
> if (!max_frames || (max_frames > 32))
> return NULL;
>
> - ret = kmalloc_obj(*ret);
> + struct dpaa2_io_store *ret __free(kfree) = kmalloc_obj(*ret);
> if (!ret)
> return NULL;
>
> ret->max = max_frames;
> - size = max_frames * sizeof(struct dpaa2_dq) + 64;
> - ret->alloced_addr = kzalloc(size, GFP_KERNEL);
> - if (!ret->alloced_addr) {
> - kfree(ret);
> + ret->alloced_addr = kzalloc(max_frames * sizeof(struct dpaa2_dq) + 64, GFP_KERNEL);
> + if (!ret->alloced_addr)
> return NULL;
Why convert the ret allocation but not the ret->alloced_addr allocation?
regards,
dan carpenter
> - }
>
> ret->vaddr = PTR_ALIGN(ret->alloced_addr, 64);
> ret->paddr = dma_map_single(dev, ret->vaddr,
> @@ -676,14 +670,13 @@ struct dpaa2_io_store *dpaa2_io_store_create(unsigned int max_frames,
> DMA_FROM_DEVICE);
> if (dma_mapping_error(dev, ret->paddr)) {
> kfree(ret->alloced_addr);
> - kfree(ret);
> return NULL;
> }
>
> ret->idx = 0;
> ret->dev = dev;
>
> - return ret;
> + return_ptr(ret);
> }
> EXPORT_SYMBOL_GPL(dpaa2_io_store_create);
>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: mediatek: alias all enabled serial ports
From: AngeloGioacchino Del Regno @ 2026-07-27 11:30 UTC (permalink / raw)
To: Carlo Caione, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, Greg Kroah-Hartman, Jiri Slaby
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
linux-serial, dlechner, jstephan
In-Reply-To: <20260727-ccaione-genio-serial-aliases-v2-1-0f2ae41a8e89@baylibre.com>
On 7/27/26 09:38, Carlo Caione wrote:
> On most MediaTek boards only serial0 is aliased, so the remaining
> enabled uarts get first-free ttyS line numbers from the 8250 core in
> probe order. When the console uart defers on its clocks another uart can
> win line 0: console=ttyS0 then ends up on the wrong port and the boot
> looks like a hang on the serial console, depending on probe order.
>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> ---
> arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts | 1 +
> arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 1 +
> arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 2 ++
> arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts | 2 ++
> arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
> arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts | 4 ++++
> arch/arm64/boot/dts/mediatek/mt8195-demo.dts | 1 +
> arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 2 ++
> arch/arm64/boot/dts/mediatek/mt8390-genio-common.dtsi | 2 ++
> arch/arm64/boot/dts/mediatek/mt8390-grinn-genio-sbc.dtsi | 2 ++
> arch/arm64/boot/dts/mediatek/mt8390-tungsten-smarc.dtsi | 2 ++
> arch/arm64/boot/dts/mediatek/mt8395-genio-common.dtsi | 1 +
> 12 files changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
> index 0e086dd487d9..63659e240b1d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt6795-sony-xperia-m5.dts
> @@ -20,6 +20,7 @@ aliases {
> mmc2 = &mmc2;
> serial0 = &uart0;
> serial1 = &uart1;
> + serial2 = &uart2;
> };
>
> backlight_lcd0: backlight {
> diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
> index 8c3e2e2578bc..7bccad118d24 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
> @@ -20,6 +20,7 @@ / {
>
> aliases {
> serial0 = &uart0;
> + serial2 = &uart2;
Why is that serial2 and not serial1 = &uart2?
Cheers,
Angelo
> };
>
> chosen {
^ permalink raw reply
* Re: [PATCH v3 2/5] clk: mediatek: Add mt8173-mfgtop driver
From: AngeloGioacchino Del Regno @ 2026-07-27 11:26 UTC (permalink / raw)
To: Chen-Yu Tsai, Stephen Boyd, Brian Masney, Matthias Brugger,
Alessio Belle, Luigi Santivetti, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Dan Carpenter, David Airlie, Simona Vetter, linux-clk, devicetree,
linux-mediatek, linux-arm-kernel, imagination, dri-devel,
linux-kernel, Icenowy Zheng, YoungJoon Lee
In-Reply-To: <20260727091555.1023910-3-wenst@chromium.org>
On 7/27/26 11:15, Chen-Yu Tsai wrote:
> The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
> in the datasheet, that contains clock gates, some power sequence signal
> delays, and other unknown registers that get toggled when the GPU is
> powered on.
>
> The clock gates are exposed as clocks provided by a clock controller,
> while the power sequencing bits are exposed as one singular power domain.
>
> Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> Changes since v2:
> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> - Needed since the driver implements PM domains using the generic PM
> domain library, which also depends on PM
> - Fixes build breakage (kernel test robot)
> - Fixed "RST_DELAY_CNT" name (Brian)
> - Dropped unused mfg_desc (Brian)
> - Added check of clk_prepare_enable()'s return value in
> clk_mt8173_mfgtop_power_on() (Brian)
> - Saved error value for return in IS_ERR(data->clk_26m) branch
> (Dan Carpenter / kernel test robot w/ smatch)
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: clock: mediatek: Add mt8173 mfgtop
From: AngeloGioacchino Del Regno @ 2026-07-27 11:26 UTC (permalink / raw)
To: Chen-Yu Tsai, Stephen Boyd, Brian Masney, Matthias Brugger,
Alessio Belle, Luigi Santivetti, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Dan Carpenter, David Airlie, Simona Vetter, linux-clk, devicetree,
linux-mediatek, linux-arm-kernel, imagination, dri-devel,
linux-kernel, Icenowy Zheng, YoungJoon Lee, Conor Dooley
In-Reply-To: <20260727091555.1023910-2-wenst@chromium.org>
On 7/27/26 11:15, Chen-Yu Tsai wrote:
> The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
> in the datasheet, that contains clock gates, some power sequence signal
> delays, and other unknown registers that get toggled when the GPU is
> powered on.
>
> The clock gates are exposed as clocks provided by a clock controller,
> while the power sequencing bits are exposed as one singular power domain.
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [REGRESSION]: [PATCH mm-hotfixes v5 3/5] x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF
From: Lorenzo Stoakes (ARM) @ 2026-07-27 11:25 UTC (permalink / raw)
To: Borah, Chaitanya Kumar
Cc: Andrew Morton, Suren Baghdasaryan, Liam R. Howlett,
Vlastimil Babka, Shakeel Butt, David Hildenbrand, Mike Rapoport,
Michal Hocko, Uladzislau Rezki, Toshi Kani, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, H. Peter Anvin, Kiryl Shutsemau,
Catalin Marinas, Will Deacon, Dev Jain, Ryan Roberts,
David Carlier, linux-mm, linux-kernel, bpf, linux-arm-kernel,
Denis V. Lunev, stable, intel-gfx@lists.freedesktop.org,
intel-xe@lists.freedesktop.org
In-Reply-To: <15f365d9-b5b9-4dc1-b24c-1b6f9363e9b1@intel.com>
On Mon, Jul 27, 2026 at 02:30:57PM +0530, Borah, Chaitanya Kumar wrote:
>
>
> On 7/23/2026 7:48 PM, Lorenzo Stoakes (ARM) wrote:
> > Thanks for the report!
> >
> > A small note - it'd be useful for you to clearly point
> > out the revision of next to make our life a bit easier :)
> >
>
> Ack.
>
Thanks! :)
> > (another small note - running scripts/decode_stacktrace.sh would be hugely
> > useful as these offsets aren't so useful unless I have the exact kernel
> > binary you have with debug symbols :)
> >
>
> We have not been asked for that yet but we can surely provide it if it
> becomes absolutely necessary for debugging.
>
It would be SUPER useful if it's not too difficult to implement, thanks :)
> Thank you for sending the fixes.
>
> CI looks good now.
>
> https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
Great thanks!
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH 8/8] arm64: dts: fsd: Align continued properties and add missing blank lines
From: André Draszik @ 2026-07-27 11:19 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-8-e9e3e9879d05@oss.qualcomm.com>
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> Trivial white-space only changes to adjust to DTS coding style and fix
> dt-check-style strict warnings like:
>
> [required-blank-lines] child node must be preceded by a blank line
> [continuation-alignment] continuation should align to column 39 (under < or ")
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/tesla/fsd-evb.dts | 2 +
> arch/arm64/boot/dts/tesla/fsd.dtsi | 97 +++++++++++++++++++----------------
> 2 files changed, 55 insertions(+), 44 deletions(-)
Reviewed-by: André Draszik <andre.draszik@linaro.org>
^ permalink raw reply
* Re: [PATCH 4/8] arm64: dts: exynos: Re-order clocks and align continued properties
From: André Draszik @ 2026-07-27 11:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-4-e9e3e9879d05@oss.qualcomm.com>
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> Trivial white-space only changes to adjust to DTS coding style
> (clocks-names should follow clocks) and fix dt-check-style strict
> warnings like:
>
> [property-order] property 'clocks' out of canonical order (should sort before 'clock-names')
> [continuation-alignment] continuation should align to column 39 (under < or ")
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 282 ++++++++++++++---------------
> 1 file changed, 141 insertions(+), 141 deletions(-)
Reviewed-by: André Draszik <andre.draszik@linaro.org>
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: exynos: Align continued properties and add missing blank lines
From: André Draszik @ 2026-07-27 11:15 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-2-e9e3e9879d05@oss.qualcomm.com>
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> Trivial white-space only changes to adjust to DTS coding style and fix
> dt-check-style strict warnings like:
>
> [required-blank-lines] child node must be preceded by a blank line
> [continuation-alignment] continuation should align to column 39 (under < or ")
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 19 ++
> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 8 +-
> .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 120 ++++++-----
> arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 45 ++++
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 230 ++++++++++++---------
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 3 +-
> .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi | 7 +
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 34 ++-
> arch/arm64/boot/dts/exynos/exynos7870-j6lte.dts | 4 +-
> arch/arm64/boot/dts/exynos/exynos7870.dtsi | 9 +-
> arch/arm64/boot/dts/exynos/exynos7885.dtsi | 9 +-
> arch/arm64/boot/dts/exynos/exynos850-pinctrl.dtsi | 1 +
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 16 +-
> arch/arm64/boot/dts/exynos/exynos8855.dtsi | 5 +
> arch/arm64/boot/dts/exynos/exynos8895.dtsi | 9 +-
> arch/arm64/boot/dts/exynos/exynos9810.dtsi | 9 +-
> arch/arm64/boot/dts/exynos/exynos990.dtsi | 3 +-
> arch/arm64/boot/dts/exynos/exynosautov9.dtsi | 9 +-
> arch/arm64/boot/dts/exynos/exynosautov920.dtsi | 7 +
> 19 files changed, 359 insertions(+), 188 deletions(-)
Reviewed-by: André Draszik <andre.draszik@linaro.org>
^ permalink raw reply
* Re: [PATCH v5 2/5] KVM: arm64: Add pre_fault_memory implementation
From: Vincent Donnefort @ 2026-07-27 11:11 UTC (permalink / raw)
To: Jack Thomson
Cc: maz, oupton, pbonzini, joey.gouly, seiden, suzuki.poulose,
yuzenghui, catalin.marinas, will, shuah, corbet, vladimir.murzin,
linux-arm-kernel, kvmarm, kvm, linux-kernel, linux-kselftest,
linux-doc, isaku.yamahata, Jack Thomson
In-Reply-To: <20260612162354.73378-3-jackabt.amazon@gmail.com>
Hi,
On Fri, Jun 12, 2026 at 05:23:50PM +0100, Jack Thomson wrote:
> From: Jack Thomson <jackabt@amazon.com>
>
> Add arm64 support for KVM_PRE_FAULT_MEMORY by synthesizing a read data
> abort and routing it through the existing stage-2 fault handlers. Treat
> the requested GPA as an IPA in the userspace-owned VM's memslot space
> and always target the canonical stage-2, even if the vCPU last ran with
> a nested/shadow MMU selected.
>
> If the vCPU last ran in a nested context, switch to the canonical
> stage-2 with the vCPU put/load helpers so VMID, VNCR and shadow-MMU
> refcount state stay consistent. Leave the switch in place for the ioctl;
> vcpu_put() at ioctl exit drops the hw_mmu and the next vcpu_load()
> reselects the correct MMU from vCPU state.
>
> Check existing mappings with a shared page-table walk under the MMU read
> lock, and use the resulting walk level when constructing the synthetic
> fault. Report poisoned pages through the ioctl return path with
> -EHWPOISON instead of also queueing SIGBUS, and use the installed
> mapping size to advance the prefault range.
>
> Advertise KVM_CAP_PRE_FAULT_MEMORY on arm64. Protected VMs remain
> unsupported: pKVM filters the capability, and the ioctl returns
> -EOPNOTSUPP if invoked anyway.
>
> Signed-off-by: Jack Thomson <jackabt@amazon.com>
> ---
> Documentation/virt/kvm/api.rst | 18 +++-
> arch/arm64/kvm/Kconfig | 1 +
> arch/arm64/kvm/arm.c | 1 +
> arch/arm64/kvm/mmu.c | 162 +++++++++++++++++++++++++++++++++
> 4 files changed, 178 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 52bbbb553ce1..657e05656fa6 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6462,7 +6462,7 @@ See KVM_SET_USER_MEMORY_REGION2 for additional details.
> ---------------------------
>
> :Capability: KVM_CAP_PRE_FAULT_MEMORY
> -:Architectures: none
> +:Architectures: x86, arm64
> :Type: vcpu ioctl
> :Parameters: struct kvm_pre_fault_memory (in/out)
> :Returns: 0 if at least one page is processed, < 0 on error
> @@ -6470,11 +6470,14 @@ See KVM_SET_USER_MEMORY_REGION2 for additional details.
> Errors:
>
> ========== ===============================================================
> + EAGAIN A memslot update raced with the ioctl before any page was
> + processed.
> EINVAL The specified `gpa` and `size` were invalid (e.g. not
> page aligned, causes an overflow, or size is zero).
> ENOENT The specified `gpa` is outside defined memslots.
> EINTR An unmasked signal is pending and no page was processed.
> EFAULT The parameter address was invalid.
> + EHWPOISON A poisoned host page was encountered.
> EOPNOTSUPP Mapping memory for a GPA is unsupported by the
> hypervisor, and/or for the current vCPU state/mode.
> EIO unexpected error conditions (also causes a WARN)
> @@ -6494,7 +6497,14 @@ Errors:
> KVM_PRE_FAULT_MEMORY populates KVM's stage-2 page tables used to map memory
> for the current vCPU state. KVM maps memory as if the vCPU generated a
> stage-2 read page fault, e.g. faults in memory as needed, but doesn't break
> -CoW. However, KVM does not mark any newly created stage-2 PTE as Accessed.
> +CoW. However, on x86, KVM does not mark any newly created stage-2 PTE as
> +Accessed. On arm64, newly created stage-2 PTEs are marked Accessed.
> +
> +On arm64, `gpa` is interpreted as an IPA in the userspace-owned VM's
> +memslot address space. If the vCPU most recently ran a nested guest, KVM
> +still targets the VM's canonical stage-2, and does not interpret `gpa` as
> +a nested guest IPA or target the nested/shadow stage-2 selected by the
> +vCPU's last run state.
>
> In the case of confidential VM types where there is an initial set up of
> private guest memory before the guest is 'finalized'/measured, this ioctl
> @@ -6507,9 +6517,9 @@ case, the ioctl can be called in parallel.
>
> When the ioctl returns, the input values are updated to point to the
> remaining range. If `size` > 0 on return, the caller can just issue
> -the ioctl again with the same `struct kvm_map_memory` argument.
> +the ioctl again with the same `struct kvm_pre_fault_memory` argument.
>
> -Shadow page tables cannot support this ioctl because they
> +On x86, shadow page tables cannot support this ioctl because they
> are indexed by virtual address or nested guest physical address.
> Calling this ioctl when the guest is using shadow page tables (for
> example because it is running a nested guest with nested page tables)
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index 449154f9a485..6b89262e8ba7 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -24,6 +24,7 @@ menuconfig KVM
> select HAVE_KVM_CPU_RELAX_INTERCEPT
> select KVM_MMIO
> select KVM_GENERIC_DIRTYLOG_READ_PROTECT
> + select KVM_GENERIC_PRE_FAULT_MEMORY
> select VIRT_XFER_TO_GUEST_WORK
> select KVM_VFIO
> select HAVE_KVM_DIRTY_RING_ACQ_REL
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 9453321ef8c6..dcb92bee13af 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -392,6 +392,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> case KVM_CAP_COUNTER_OFFSET:
> case KVM_CAP_ARM_WRITABLE_IMP_ID_REGS:
> case KVM_CAP_ARM_SEA_TO_USER:
> + case KVM_CAP_PRE_FAULT_MEMORY:
> r = 1;
> break;
> case KVM_CAP_SET_GUEST_DEBUG2:
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index c720f07cb82e..4bf048bbcf8b 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1571,6 +1571,8 @@ struct kvm_s2_fault_desc {
> struct kvm_s2_trans *nested;
> struct kvm_memory_slot *memslot;
> unsigned long hva;
> + unsigned long *page_size;
It looks a bit odd in that struct.
Also, transparent_hugepage_adjust() modifies pfn and gfn. So perhaps it'd be
better to introduce a struct kvm_s2_fault_mapping that can be used to get what
has actually been mapped in kvm_s2_fault_map()?
> + bool prefault;
> };
>
> static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
> @@ -1882,6 +1884,13 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
> &s2vi->map_writable, &s2vi->page);
> if (unlikely(is_error_noslot_pfn(s2vi->pfn))) {
> if (s2vi->pfn == KVM_PFN_ERR_HWPOISON) {
> + /*
> + * When prefaulting, report the poison via -EHWPOISON
> + * only; don't also queue a SIGBUS as the run path
> + * does for the faulting vCPU thread.
> + */
> + if (s2fd->prefault)
> + return -EHWPOISON;
> kvm_send_hwpoison_signal(s2fd->hva, __ffs(s2vi->vma_pagesize));
> return 0;
> }
> @@ -2053,6 +2062,9 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
> kvm_release_faultin_page(kvm, s2vi->page, !!ret, writable);
> kvm_fault_unlock(kvm);
>
> + if (s2fd->page_size && !ret)
> + *s2fd->page_size = mapping_size;
> +
> /*
> * Mark the page dirty only if the fault is handled successfully,
> * making sure we adjust the canonical IPA if the mapping size has
> @@ -2757,3 +2769,153 @@ void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled)
>
> trace_kvm_toggle_cache(*vcpu_pc(vcpu), was_enabled, now_enabled);
> }
> +
> +/*
> + * Prefaulting always targets the canonical stage-2. If the vCPU last ran
> + * in a nested context, swap in the canonical MMU via the vCPU put/load
> + * helpers so that preemption, VMID, VNCR fixmap and shadow-MMU refcount
> + * state stay consistent.
> + *
> + * The swap is deliberately not undone: nothing runs in between the
> + * per-page invocations of kvm_arch_vcpu_pre_fault_memory() except the
> + * generic prefault loop, and the vcpu_put() at ioctl exit discards
> + * vcpu->arch.hw_mmu anyway (see kvm_vcpu_put_hw_mmu()), so the next
> + * vcpu_load() re-derives the correct MMU from the vCPU's context. If the
> + * prefault task is preempted in the meantime, kvm_vcpu_put_hw_mmu()
> + * keeps the canonical MMU in place for the reload. Leaving the swap in
> + * place also bounds the cost to at most one put/load pair per ioctl,
> + * rather than two pairs per prefaulted page.
> + */
> +static void kvm_pre_fault_load_canonical_mmu(struct kvm_vcpu *vcpu)
> +{
> + if (!vcpu_has_nv(vcpu) || vcpu->arch.hw_mmu == &vcpu->kvm->arch.mmu)
> + return;
> +
> + preempt_disable();
> + kvm_arch_vcpu_put(vcpu);
> + vcpu->arch.hw_mmu = &vcpu->kvm->arch.mmu;
> + kvm_arch_vcpu_load(vcpu, smp_processor_id());
> + preempt_enable();
> +}
> +
> +long kvm_arch_vcpu_pre_fault_memory(struct kvm_vcpu *vcpu,
> + struct kvm_pre_fault_memory *range)
> +{
> + struct kvm_vcpu_fault_info *fault_info = &vcpu->arch.fault;
> + struct kvm_vcpu_fault_info fault_backup = *fault_info;
> + s8 walk_level = KVM_PGTABLE_LAST_LEVEL;
> + unsigned long page_size = PAGE_SIZE;
> + struct kvm_memory_slot *memslot;
> + phys_addr_t gpa = range->gpa;
> + struct kvm_pgtable *pgt;
> + phys_addr_t end;
> + kvm_pte_t pte;
> + hva_t hva;
> + gfn_t gfn;
> + long ret;
> +
> + if (vcpu_is_protected(vcpu))
> + return -EOPNOTSUPP;
It could just call pkvm_mem_abort() when the VM is protected?
> +
> + /*
> + * Interpret range->gpa in the userspace-owned VM's IPA space, not in
> + * any nested guest IPA space that may have been active on the vCPU's
> + * last run. Always target the canonical stage-2.
> + */
> + kvm_pre_fault_load_canonical_mmu(vcpu);
> +
> + if (gpa >= kvm_phys_size(vcpu->arch.hw_mmu)) {
> + ret = -ENOENT;
> + goto out;
> + }
> +
> + gfn = gpa_to_gfn(gpa);
> + memslot = gfn_to_memslot(vcpu->kvm, gfn);
> + if (!memslot) {
> + ret = -ENOENT;
> + goto out;
> + }
> +
> + /*
> + * A racing memslot deletion or move installs an invalid slot before
> + * zapping stage-2. Ask userspace to retry once the update settles.
> + */
> + if (memslot->flags & KVM_MEMSLOT_INVALID) {
> + ret = -EAGAIN;
> + goto out;
> + }
> +
> + /*
> + * pKVM stage-2 mappings aren't directly walkable from the host; let
> + * the fault path handle both new and existing mappings.
> + */
pKVM has a host interval-tree where we keep track of what has been mapped and at
what level. This tree is also protected with the mmu_lock.
> + if (!is_protected_kvm_enabled()) {
> + pgt = vcpu->arch.hw_mmu->pgt;
> + scoped_guard(read_lock, &vcpu->kvm->mmu_lock) {
> + ret = kvm_pgtable_get_leaf(pgt, gpa, &pte, &walk_level,
> + KVM_PGTABLE_WALK_SHARED);
> + }
> + if (ret)
> + goto out;
> +
> + if (kvm_pte_valid(pte)) {
> + page_size = kvm_granule_size(walk_level);
> + if (!(pte & KVM_PTE_LEAF_ATTR_LO_S2_AF))
> + handle_access_fault(vcpu, gpa);
> + goto out_success;
> + }
> + }
> +
> + /*
> + * Synthesize a read translation fault for the canonical IPA, at the
> + * level where the stage-2 walk currently ends (the last level under
> + * pKVM, where stage-2 isn't walkable from the host).
> + */
> + fault_info->esr_el2 = (ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT) |
> + ESR_ELx_IL | ESR_ELx_FSC_FAULT_L(walk_level);
> + fault_info->hpfar_el2 = HPFAR_EL2_NS |
> + FIELD_PREP(HPFAR_EL2_FIPA, gpa >> 12);
> +
> + struct kvm_s2_fault_desc s2fd = {
> + .vcpu = vcpu,
> + .fault_ipa = gpa,
> + .nested = NULL,
> + .memslot = memslot,
> + .page_size = &page_size,
> + .prefault = true,
> + };
> +
> + /*
> + * As in the run path, -EAGAIN from the abort handlers is treated as
> + * progress: either a parallel fault installed the mapping, or a racing
> + * invalidation is in flight and the next access will refault.
> + */
> + if (kvm_slot_has_gmem(memslot)) {
> + ret = gmem_abort(&s2fd);
> + } else {
> + hva = gfn_to_hva_memslot_prot(memslot, gfn, NULL);
> + if (kvm_is_error_hva(hva)) {
> + ret = -EFAULT;
> + goto out;
> + }
> +
> + s2fd.hva = hva;
> + ret = user_mem_abort(&s2fd);
> + }
> +
> + if (ret < 0)
> + goto out;
> +
> +out_success:
> + end = ALIGN_DOWN(gpa, page_size) + page_size;
> + ret = min_t(u64, range->size, end - gpa);
> +out:
> + /*
> + * Restore the synthetic fault state so a subsequent KVM_RUN does not
> + * observe it. kvm_handle_mmio_return() runs before guest entry can
> + * refresh fault.esr_el2 from hardware, so leaving the synthetic ESR
> + * in place would corrupt the completion of a pending MMIO exit.
> + */
> + *fault_info = fault_backup;
> + return ret;
> +}
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH 7/8] arm64: dts: fsd: Move 'status' to the end to match coding style
From: André Draszik @ 2026-07-27 11:10 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-7-e9e3e9879d05@oss.qualcomm.com>
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> 'status' property is special, thus DTS coding style expects it to be
> always the last property preceded with a blank line, as reported by
> dt-check-style:
>
> [required-blank-lines] "status" must be preceded by a blank line
> [property-order] property 'phy-mode' out of canonical order (should sort before 'status')
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/tesla/fsd-evb.dts | 6 ++++--
> arch/arm64/boot/dts/tesla/fsd.dtsi | 24 ++++++++++++++++++++++++
> 2 files changed, 28 insertions(+), 2 deletions(-)
Reviewed-by: André Draszik <andre.draszik@linaro.org>,
^ permalink raw reply
* Re: [PATCH 1/8] arm64: dts: exynos: Move 'status' to the end to match coding style
From: Krzysztof Kozlowski @ 2026-07-27 11:10 UTC (permalink / raw)
To: André Draszik, Krzysztof Kozlowski, Ivaylo Ivanov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Peter Griffin,
Alim Akhtar, Sam Protsenko, Tudor Ambarus, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <81160ceaf02ad31c4b86c00dd4bcdcf1fe624788.camel@linaro.org>
On 27/07/2026 13:04, André Draszik wrote:
> Hi Krzysztof,
>
> On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index fa2029e280a5..17b13a586973 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -755,6 +755,7 @@ tmu_atlas0: tmu@10060000 {
>> <&cmu_peris CLK_SCLK_TMU0>;
>> clock-names = "tmu_apbif", "tmu_sclk";
>> #thermal-sensor-cells = <0>;
>> +
>> status = "disabled";
>> };
>>
>> @@ -766,7 +767,9 @@ tmu_atlas1: tmu@10068000 {
>> <&cmu_peris CLK_SCLK_TMU0>;
>> clock-names = "tmu_apbif", "tmu_sclk";
>> #thermal-sensor-cells = <0>;
>> +
>> status = "disabled";
>> +
>> };
>
> This adds an extra empty line.
Ack
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/8] arm64: dts: google: Align continued properties and add missing blank lines
From: André Draszik @ 2026-07-27 11:10 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-6-e9e3e9879d05@oss.qualcomm.com>
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> Trivial white-space only changes to adjust to DTS coding style and fix
> dt-check-style strict warnings like:
>
> [required-blank-lines] child node must be preceded by a blank line
> [continuation-alignment] continuation should align to column 39 (under < or ")
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
Reviewed-by: André Draszik <andre.draszik@linaro.org>,
^ permalink raw reply
* Re: [PATCH 5/8] arm64: dts: google: Move 'status' to the end to match coding style
From: André Draszik @ 2026-07-27 11:08 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-5-e9e3e9879d05@oss.qualcomm.com>
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> 'status' property is special, thus DTS coding style expects it to be
> always the last property preceded with a blank line, as reported by
> dt-check-style:
>
> [required-blank-lines] "status" must be preceded by a blank line
> [property-order] property 'vcc-supply' out of canonical order (should sort before 'status')
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/exynos/google/gs101-oriole.dts | 2 +
> .../boot/dts/exynos/google/gs101-pixel-common.dtsi | 12 +++-
> arch/arm64/boot/dts/exynos/google/gs101-raven.dts | 2 +
> arch/arm64/boot/dts/exynos/google/gs101.dtsi | 70 ++++++++++++++++++++++
> 4 files changed, 85 insertions(+), 1 deletion(-)
Reviewed-by: André Draszik <andre.draszik@linaro.org>,
^ permalink raw reply
* Re: [PATCH 3/8] arm64: dts: exynos5433: Override thermal zones by phandle
From: André Draszik @ 2026-07-27 11:06 UTC (permalink / raw)
To: Krzysztof Kozlowski, Ivaylo Ivanov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Peter Griffin, Alim Akhtar,
Sam Protsenko, Tudor Ambarus, Krzysztof Kozlowski, linux-fsd
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel
In-Reply-To: <20260726-b4-dts-coding-style-strict-v1-3-e9e3e9879d05@oss.qualcomm.com>
On Sun, 2026-07-26 at 19:43 +0200, Krzysztof Kozlowski wrote:
> Fix indentation of DTSI file with thermal zones (two opening { brackets,
> but only one indent) by using a safer choice of phandle/label override.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 4 +---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 3 +++
> 2 files changed, 4 insertions(+), 3 deletions(-)
Reviewed-by: André Draszik <andre.draszik@linaro.org>
^ permalink raw reply
* Re: [PATCH v1] pmdomain: mediatek: Fix MT8183 hang on boot
From: AngeloGioacchino Del Regno @ 2026-07-27 11:04 UTC (permalink / raw)
To: Ulf Hansson, Dmitry Osipenko
Cc: Ulf Hansson, Matthias Brugger, linux-pm, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <CAPx+jO-1_ZpYcnPtoYxRn5vv34tiP7TXnjKZ3SaWkEzdeTfXpA@mail.gmail.com>
On 7/24/26 17:01, Ulf Hansson wrote:
> On Wed, Jul 22, 2026 at 3:28 PM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>>
>> Depending on firmware, part of the MFG domains may be left ON at boot
>> leaving only some MFG cores powered, to let the ACP to prefetch the GPU
>> region when the display controller is brought up. This doesn't play well
>> with an eventual delay in probing Panfrost when the display controller is
>> fully set up, as that would make genpd's sync_state() to power off the
>> domain while ACP tries to prefetch: this is causing an AXI stall,
>> effectively freezing the AP indefinitely. In order to prevent this from
>
> I haven't made any detailed investigation, but to me, it sounds like
> there is a missing consumer somewhere.
>
> Should the ACP/panfrost devices be a consumer of the MFG domains as
> well? Or perhaps, if the ACP/panfrost should rely on the display
> controller to be probed and powered-on, to be able to probe?
>
This is about how the bootloader is leaving the display controller, the ACP,
and the MFG registers before booting the kernel.
The kernel drivers themselves will reset this weird state when the HW gets
to full probe so there won't be any more issue(s) from that point onwards.
Actually, there would be A LOT to say about this, but I'll be very brief...
Basically, before booting the kernel, the bootloader is leaving a half-assed
setup to potentially support continuous splash functionality, but without it
being actually used on the device(s) that we're talking about here...
Again, I should put a remark on every word of that last paragraph, but this
is the gist of it.
If you're curious or need more information, of course I can expand a bit,
there's no secret involved here, it's just that I'm avoiding to write a wall
of text around that...
P.S.: We've been discussing that internally and chasing this issue for months
before deciding to "solve" it like this.
Cheers,
Angelo
>> happening, the sync_state() functionality must be obliterated on all of
>> the MFG domains: while this guarantees a power leakage if the bootloader
>> boots the kernel with MFG PDs partially powered on, this is the only way
>> to ensure stable operation of the SoC during boot on devices with such
>> firmware because, of course, those will never officially receive a
>> firmware update.
>>
>> Fixes Kappa Chromebook hanging during system boot.
>>
>> Fixes: 0e789b491ba0 ("pmdomain: core: Leave powered-on genpds on until sync_state")
>> Fixes: 13a4b7fb6260 ("pmdomain: core: Leave powered-on genpds on until late_initcall_sync")
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>
> Kind regards
> Uffe
>
>> ---
>> drivers/pmdomain/mediatek/mt8183-pm-domains.h | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pmdomain/mediatek/mt8183-pm-domains.h b/drivers/pmdomain/mediatek/mt8183-pm-domains.h
>> index 3742782a2702..5e33b8628e85 100644
>> --- a/drivers/pmdomain/mediatek/mt8183-pm-domains.h
>> +++ b/drivers/pmdomain/mediatek/mt8183-pm-domains.h
>> @@ -47,7 +47,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = 0,
>> .sram_pdn_ack_bits = 0,
>> - .caps = MTK_SCPD_DOMAIN_SUPPLY,
>> + .caps = MTK_SCPD_DOMAIN_SUPPLY | MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG] = {
>> .name = "mfg",
>> @@ -57,7 +57,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> - .caps = MTK_SCPD_DOMAIN_SUPPLY,
>> + .caps = MTK_SCPD_DOMAIN_SUPPLY | MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG_CORE0] = {
>> .name = "mfg_core0",
>> @@ -67,6 +67,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG_CORE1] = {
>> .name = "mfg_core1",
>> @@ -76,6 +77,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>> },
>> [MT8183_POWER_DOMAIN_MFG_2D] = {
>> .name = "mfg_2d",
>> @@ -85,6 +87,7 @@ static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
>> .pwr_sta2nd_offs = 0x0184,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>> .bp_cfg = {
>> BUS_PROT_WR(INFRA,
>> MT8183_TOP_AXI_PROT_EN_1_MFG,
>> --
>> 2.54.0
>>
^ permalink raw reply
* Re: [PATCH v8 00/21] ARM64 PMU Partitioning
From: James Clark @ 2026-07-27 11:04 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, alexandru.elisei, pbonzini, corbet, linux, catalin.marinas,
will, maz, oliver.upton, mizhang, joey.gouly, suzuki.poulose,
yuzenghui, mark.rutland, shuah, gankulkarni, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-perf-users,
linux-kselftest
In-Reply-To: <gsnt33x95sra.fsf@coltonlewis-kvm.c.googlers.com>
On 23/07/2026 9:57 pm, Colton Lewis wrote:
> James Clark <james.clark@linaro.org> writes:
>
>> On 22/07/2026 12:03 am, Colton Lewis wrote:
>>> Hi James, thanks for the review.
>
>>> James Clark <james.clark@linaro.org> writes:
>>>> Hi Colton,
>
>>>> The existence of the parameter makes sense, but can't the default be
>>>> arm_pmuv3.reserved_host_counters=0 instead of -1 (partition disabled)?
>
>>> How would you interpret reserved_host_counters=0? Because that would
>>> express that the host should have zero counters and the guest gets them
>>> all. I remember in early versions of this series last year I did use 0
>>> as the default but reviewers asked for a way to express the scenario of
>>> of zero counters for the host.
>
>
>> I think I would interpret it as it is now. Can't the host still use them
>> until the guest does and then they only get squeezed if there is a
>> collision? That doesn't sound too bad to me. And if a host wants
>> reserved counters they can set a positive number.
>
> Yeah that makes sense. I was thinking in an old headspace when it was
> just a static reservation instead of changing when a guest is loaded.
>
>> Is reserved_host_counters==max_counters equivalent to -1? And there's no
>> overview in the cover letter or documentation about how it interacts
>> with the dynamic guest counter reservations. A bit more detail or a few
>> paragraphs in one place would help users, maybe with examples so they
>> don't have to piece together all the commit messages to work it out.
>
> It's not equivalent since we need a case where the guest only has access
> to the fixed-purpose counters like the dedicated cycle
> counter. reserved_host_counters specifies the number of general purpose
> counters.
>
> I'll document the operation more clearly. In the future please feel free
> to email me to ask if you are confused about something.
>
>>>> It's still a bit fiddly having to do two things to make it work, and
>>>> there's no documentation about what the defaults or other prerequisites
>>>> are. IMO it's not even trivial to work out that you need to prefix it
>>>> with "arm_pmuv3.", which documentation would improve.
>
>>> It is fiddly, which is why the more I think about it the more I'd rather
>>> ditch the kernel cmdline entirely and leave it up to KVM. That's the
>>> most flexible approach. There isn't a good way to change the cmdline
>>> after boot. Trying to make it writeable via sysfs runs into the problem
>>> of when is it safe to apply the change.
>
>>> I thought it was commonly understood module parameters need to be
>>> prefixed by the module name, but I can add better documentation to that
>>> effect.
>
>
>
>> People just want it written out fully somewhere so they can copy paste
>> it. Kernel developers might be able to piece it together, but not
>> everyone will.
>
> This is the KVM mailing list. Kernel developers are the primary
> audience, but I will make reasonable efforts to include others in the
> future.
>
I'm more thinking of the users of this after it gets merged, rather than
just for the review.
>>>> Testing the whole set I ran into a few issues:
>
>>>> This warn is hit when there is some kind of interaction with
>>>> sleeping. I
>>>> tried to bisect it but it only appears on the last commit when the
>>>> option to enable partitioning is added.
>
>>>> /*
>>>> * ARM pmu always has to reprogram the period, so ignore
>>>> * PERF_EF_RELOAD, see the comment below.
>>>> */
>>>> if (flags & PERF_EF_RELOAD)
>>>> WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
>
>>>> Steps to reproduce:
>
>>>> Host (arm_pmuv3.reserved_host_counters=0):
>>>> $ sudo perf stat -C 2 -e \
>>>> 'branches,branches,branches,branches,branches,branches'
>>>> $ sudo taskset --cpu-list 2 ./lkvm run --kernel \
>>>> /boot/vmlinux-7.1.0-rc7+ -m 1024 -c 1 --pmu
>
>>>> Guest:
>>>> $ sleep 1
>
>>>> WARNING: drivers/perf/arm_pmu.c:302 at
>>>> cpu_pm_pmu_notify+0x278/0x2c0,
>>>> CPU#2: swapper/2/0
>>>> Call trace:
>>>> cpu_pm_pmu_notify+0x278/0x2c0 (P)
>>>> notifier_call_chain+0x84/0x1d0
>>>> raw_notifier_call_chain+0x24/0x38
>>>> cpu_pm_exit+0x34/0x68
>>>> acpi_processor_ffh_lpi_enter+0x40/0x78
>>>> acpi_idle_lpi_enter+0x54/0x78
>>>> cpuidle_enter_state+0xb4/0x248
>>>> cpuidle_enter+0x44/0x68
>>>> do_idle+0x21c/0x300
>>>> cpu_startup_entry+0x40/0x50
>>>> secondary_start_kernel+0x120/0x150
>>>> __secondary_switched+0xc0/0xc8
>
>
>>> I'll attempt to reproduce that. I've never seen it myself but I've
>>> mainly been using QEMU for my testing.
>
>
>> The newest Arm FVP should have cpuidle enabled if you boot it with ACPI,
>> but I hit this on a Radxa Orion O6 board.
>
> Noted. Thanks.
>
>
>>>> When running the guest on a single CPU I get different counts for the
>>>> same event for a single process, although this never happens on a host.
>>>> I think there might even be some Perf tests which expect them to be the
>>>> same, and this doesn't depend on whether any events are running on the
>>>> host or not. Not sure if you ran all the Perf selftests in a guest or
>>>> not?
>
>>> I'll investigate but I'm not sure perf is intended to guarantee
>>> that. perf stat just runs the event counters but may not write or read
>>> them at exactly the same time.
>
>
>> Is that true? The perf core calls perf_pmu_disable() when a process is
>> scheduled out before reading the count of each event of that process in
>> an inner loop. The perf_pmu_disable() clears PMCR_EL0.E which freezes
>> all of the counters so they can be read out in a consistent state.
>
>> It's important that they're all stopped at the same time because
>> counters might be used in metrics as ratios of each other. So I think
>> it's deliberately designed that way and appears to not be working in a
>> guest now.
>
> By default I think perf assumes events can be measured independently, If
> you want to guarantee events are scheduled together to avoid measurement
> skew you need to make sure the events are grouped.
>
> The common way to do that is with {} around the event list:
>
> perf stat -e {branches,branches}
>
> Please see if that resolves the issue.
>
Groups only change how the events are scheduled, not how the driver
starts or stops multiple events running on the same PMU (grouped or
ungrouped). In my repro I had less events than counters in HW, so they
will always be scheduled at the same time regardless of grouping.
I did notice something extra though, you have to first open some amount
of counters, and then open more than that. Then the second time the ones
with different counts will be however many were opened first time, as if
some state has stuck.
For example if I open two counters then 6, the first two always have
different counts the second time:
$ perf stat -e branches,branches true
Performance counter stats for 'true':
106129 branches
106129 branches
$ perf stat -e
'{branches,branches,branches,branches,branches,branches}' true
Performance counter stats for 'true':
117013 branches
117013 branches
110364 branches
110364 branches
110364 branches
110364 branches
After opening 6 again a third time they'll all have the same counts.
>>>> I'm not sure if the exception level filtering isn't working or there is
>>>> something wrong with freezing. Doesn't the host PMU driver need to
>>>> freeze with HPME? I see it's still doing it with PMCR_EL0.E which
>>>> freezes the guest's counters now doesn't it?
>
>>> HPME only has any effect while HPMN is programmed to a value different
>>> than the number of counters on the system. That is only true in a guest
>>> context. As I understand it, that means HPME has no effect anywhere the
>>> host driver needs to freeze counters since that happens in host context.
>
>
>> Oh yeah that makes sense, I didn't think about that. I'm not sure if my
>> other idea about exception level filtering being responsible makes sense
>> either.
>
> I'll check that too.
>
>>> Maybe HPMN stays programmed during interrupt handling though. I'll
>>> confirm.
>
>
>>>> Host (arm_pmuv3.reserved_host_counters=0):
>>>> $ sudo taskset --cpu-list 2 ./lkvm run --kernel \
>>>> /boot/vmlinux-7.1.0-rc7+ -m 1024 -c 1 --pmu
>
>>>> Guest:
>>>> $ perf stat -e branches,branches true
>
>>>> Performance counter stats for 'true':
>
>>>> 167963 branches
>
>>>> 160925 branches
>
>
>>>> $ perf stat -e branches,branches,branches,branches,branches true
>
>>>> Performance counter stats for 'true':
>
>>>> 164425 branches
>
>>>> 164425 branches
>
>>>> 164425 branches
>
>>>> 157743 branches
>
>>>> 157743 branches
>
>
>>>> When running the guest on two CPUs I just get zeros. Do the kvm
>>>> selftests not catch this? Or is it something to do with my setup:
>
>>> KVM selftests definitely don't catch it. I'll see if I can reproduce.
>
>>> Since the problem happens with 2 CPUs I wonder if something is
>>> triggering the lazy context swap behavior so the counter values aren't
>>> being moved to the 2nd CPU correctly.
>
>
>> If that was the case I would have expected it to be intermittent, or you
>> would get a partial count if the second CPU started from 0, but not
>> zeros every where every time. Let me know if I can run any more tests.
>
> I'll let you know if I think of something.
>
>>>> Host (arm_pmuv3.reserved_host_counters=0):
>>>> $ sudo taskset --cpu-list 2-3 ./lkvm run --kernel \
>>>> /boot/vmlinux-7.1.0-rc7+ -m 1024 -c 1 --pmu
>
>>>> Guest:
>>>> $ perf stat -e branches,branches true
>
>>>> Performance counter stats for 'true':
>
>>>> 0 branches
>
>>>> 0 branches
>
>>>> I also noticed I get the "squeezed" warning printed after launching the
>>>> guest but not using Perf. This comment implies that not using counters
>>>> makes it a nop:
>
>>>> /*
>>>> * If we aren't guest-owned then we know the guest isn't using
>>>> * the PMU anyway, so no need to bother with the swap.
>>>> */
>>>> if (vcpu->arch.pmu.access != VCPU_PMU_ACCESS_GUEST_OWNED)
>>>> return;
>
>>>> But maybe linux is touching them in a way that makes them guest owned,
>>>> even on probe? Or is the guest/host ownership tracking not working, I
>>>> didn't look too hard.
>
>>> Maybe. I'll check. The guest is also running its own PMU driver that
>>> might trigger guest ownership on initialization since ownership is
>>> determined by which registers the guest touches.
>
>
>> It doesn't enable any counters though does it, even if it touches some
>> of the registers to probe? Should that result in squeezing out host
>> counters? Maybe it's more complicated to implement, but right now it
>> seems like there is some complexity without much benefit as 90% of hosts
>> are going to probe the counters just to see what's there but not use
>> them.
>
> As far as I'm aware the driver probe shouldn't shouldn't enable any
> counters or trigger squeezing. I'll narrow the conditions that trigger
> guest ownership.
>
> My first suspect is the guest driver probe is triggering guest ownership
> by reading PMCR_EL0, which I agree should be changed to avoid that.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox