Le Sun, Sep 21, 2025 at 10:40:59AM +0200, Patrick Wildt a écrit :
> Hi,
> 
> I'd like to get some more testing done on the initial SMMUv3 support
> that's in the tree.  I've mostly been testing on the Rockchip RK3588
> but I think this should also affect e.g. Ampere Altra-based systems?
> 
> Please give this diff a go on newer Arm-based machines and check if a
> new smmu device pops up in dmesg, and if it does, if your I/O devices
> still perform the same (or better or worse).
> 
> On Apple devices this diff won't make a difference, on those we have
> apldart(4).
> 
> On QC machines this diff might make the driver try to attach in ACPI
> mode; and possibly panic.  Reports on booting this diff in ACPI mode
> would be highly appreciated.  In FDT mode this should not attach.

blows on the omnibook x14, handwritten trace below:

acpiiort0 at acpi0
smmu0 at acpiiort0 addr 0x15000000/0x100000: disabled
smmu1 at acpiiort0 addr 0x3da0000/0x40000
smmu2 at acpiiort0 addr 0x1400000/0x20000panic: uvm_fault failed: ffffff8000baa954 esr 96000010 far ffffff80e5e1e000
stopped at db_enter+0x18: brk #0xf000
TID	PID	UID	PRFLAGS	PFLAGS	CPU	COMAND
0	0	0	0x10000	0x200	0K	swapper
db_enter() at panic+0x198
panic() at date_abort+0x198
do_el0_sync() at handle_el1h_sync+0x68
handle_el1h_sync() at generic_space_reead_4+0x14
--- trap ---
generic_space_read_4() at smmu_v3_attach+0xa0
smmu_v3_attach() at smmu_v3_acpi_attach+0x154
smmu_v3_acpi_attach() at smmu_acpi_attach+0x74

at that point i dont have a keyboard, so cant get anything from ddb.  in
FDT mode, everything works fine, and i have the two smmu0/smmu1 devices
from the other diff enabling it. i can also try with only the smmu v3
diff if that's useful.