linux-kernel - Re: [PATCH v8 5/6] KVM: arm64: Allow cacheable stage 2 mapping using VMA flags

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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <SA1PR12MB7199F040DF62057947664992B07CA@SA1PR12MB7199.namprd12.prod.outlook.com>
Date: Fri, 20 Jun 2025 13:07:11 +0000
From: Ankit Agrawal <ankita@...dia.com>
To: Jason Gunthorpe <jgg@...dia.com>
CC: "maz@...nel.org" <maz@...nel.org>, "oliver.upton@...ux.dev"
	<oliver.upton@...ux.dev>, "joey.gouly@....com" <joey.gouly@....com>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>, "yuzenghui@...wei.com"
	<yuzenghui@...wei.com>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"will@...nel.org" <will@...nel.org>, "ryan.roberts@....com"
	<ryan.roberts@....com>, "shahuang@...hat.com" <shahuang@...hat.com>,
	"lpieralisi@...nel.org" <lpieralisi@...nel.org>, "david@...hat.com"
	<david@...hat.com>, "ddutile@...hat.com" <ddutile@...hat.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, Aniket Agashe <aniketa@...dia.com>,
	Neo Jia <cjia@...dia.com>, Kirti Wankhede <kwankhede@...dia.com>, Krishnakant
 Jaju <kjaju@...dia.com>, "Tarun Gupta (SW-GPU)" <targupta@...dia.com>, Vikram
 Sethi <vsethi@...dia.com>, Andy Currid <acurrid@...dia.com>, Alistair Popple
	<apopple@...dia.com>, John Hubbard <jhubbard@...dia.com>, Dan Williams
	<danw@...dia.com>, Zhi Wang <zhiw@...dia.com>, Matt Ochs <mochs@...dia.com>,
	Uday Dhoke <udhoke@...dia.com>, Dheeraj Nigam <dnigam@...dia.com>,
	"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
	"sebastianene@...gle.com" <sebastianene@...gle.com>, "coltonlewis@...gle.com"
	<coltonlewis@...gle.com>, "kevin.tian@...el.com" <kevin.tian@...el.com>,
	"yi.l.liu@...el.com" <yi.l.liu@...el.com>, "ardb@...nel.org"
	<ardb@...nel.org>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"gshan@...hat.com" <gshan@...hat.com>, "linux-mm@...ck.org"
	<linux-mm@...ck.org>, "tabba@...gle.com" <tabba@...gle.com>,
	"qperret@...gle.com" <qperret@...gle.com>, "kvmarm@...ts.linux.dev"
	<kvmarm@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "maobibo@...ngson.cn"
	<maobibo@...ngson.cn>
Subject: Re: [PATCH v8 5/6] KVM: arm64: Allow cacheable stage 2 mapping using
 VMA flags

>> -             s2_force_noncacheable = true;
>> +             bool cacheable_pfnmap = false;
>> +
>> +             if (vm_flags & VM_PFNMAP) {
>
> I think this same logic works equally well for MIXEDMAP. A cachable
> MIXEDMAP should follow the same rules for PFNMAP for the non-normal
> pages within it. IOW, just remove this if, it was already done above.

I see. Sure, I'll update to remove the check.


>> +                     /*
>> +                      * COW VM_PFNMAP is possible when doing a MAP_PRIVATE
>> +                      * /dev/mem mapping on systems that allow such mapping.
>> +                      * Reject such case.
>> +                      */
>
> This is where a COW mapping come from, but it doesn't explain why KVM
> has a problem here?

Actually I am not entirely sure of the reason. My read on that was that COW of
PFNMAP is a normal page backed by struct page that doesn't follow linearity.
Not sure if that conflicts with user_mem_abort() assumptions. Will need
David's take on that.

>> +                     if (is_vma_cacheable)
>> +                             cacheable_pfnmap = true;
>> +             }
>> +
>> +             if (cacheable_pfnmap) {
>
> If the vm_flags test is removed then this is just is_vma_cacheable

Thanks for catching that. We shouldn't need this variable.

>> +                      * ARM64 KVM relies on kernel VA mapping to the PFN to
>> +                      * perform cache maintenance as the CMO instructions work on
>> +                      * virtual addresses. VM_PFNMAP region are not necessarily
>> +                      * mapped to a KVA and hence the presence of hardware features
>> +                      * S2FWB and CACHE DIC is mandatory for cache maintenance.
>
> "are mandatory to avoid any cache maintenance"

Right, thanks.

> Jason