linux-kernel - Re: [PATCH v7 1/5] KVM: arm64: Rename symbols to reflect whether CMO may be used

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aFLNHvCdz3v6XrCr@arm.com>
Date: Wed, 18 Jun 2025 15:28:46 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: ankita@...dia.com
Cc: jgg@...dia.com, maz@...nel.org, oliver.upton@...ux.dev,
	joey.gouly@....com, suzuki.poulose@....com, yuzenghui@...wei.com,
	will@...nel.org, ryan.roberts@....com, shahuang@...hat.com,
	lpieralisi@...nel.org, david@...hat.com, ddutile@...hat.com,
	seanjc@...gle.com, aniketa@...dia.com, cjia@...dia.com,
	kwankhede@...dia.com, kjaju@...dia.com, targupta@...dia.com,
	vsethi@...dia.com, acurrid@...dia.com, apopple@...dia.com,
	jhubbard@...dia.com, danw@...dia.com, zhiw@...dia.com,
	mochs@...dia.com, udhoke@...dia.com, dnigam@...dia.com,
	alex.williamson@...hat.com, sebastianene@...gle.com,
	coltonlewis@...gle.com, kevin.tian@...el.com, yi.l.liu@...el.com,
	ardb@...nel.org, akpm@...ux-foundation.org, gshan@...hat.com,
	linux-mm@...ck.org, tabba@...gle.com, qperret@...gle.com,
	kvmarm@...ts.linux.dev, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, maobibo@...ngson.cn
Subject: Re: [PATCH v7 1/5] KVM: arm64: Rename symbols to reflect whether CMO
 may be used

On Wed, Jun 18, 2025 at 06:55:37AM +0000, ankita@...dia.com wrote:
> From: Ankit Agrawal <ankita@...dia.com>
> 
> Currently, the kvm_is_device_pfn() detects if the memory is kernel
> mapped. It thus implies whether KVM can use Cache Maintenance
> Operations (CMOs) on that PFN. Rename the function to reflect this.
> 
> Additionally, the "device" variable is effectively trying to setup the S2
> to prevent CMOs. Calling it 'disable_cmo' would make this code clearer.

I'm not sure CMOs is the only reason. Another is to prevent the guest
from mapping device memory as something other than Device with
possible implications for external aborts.

-- 
Catalin