[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <22ab15f6-b1b9-4bb2-80b5-9e5bf4a3b7f5@redhat.com>
Date: Mon, 1 Sep 2025 17:38:13 +0200
From: David Hildenbrand <david@...hat.com>
To: kalyazin@...zon.com, "Kalyazin, Nikita" <kalyazin@...zon.co.uk>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"shuah@...nel.org" <shuah@...nel.org>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jthoughton@...gle.com" <jthoughton@...gle.com>,
"Roy, Patrick" <roypat@...zon.co.uk>, "Thomson, Jack"
<jackabt@...zon.co.uk>, "Manwaring, Derek" <derekmn@...zon.com>,
"Cali, Marco" <xmarcalx@...zon.co.uk>
Subject: Re: [PATCH v4 1/2] KVM: guest_memfd: add generic population via write
On 01.09.25 16:29, Nikita Kalyazin wrote:
>
>
> On 28/08/2025 21:01, David Hildenbrand wrote:
>> On 28.08.25 17:31, Kalyazin, Nikita wrote:
>>> write syscall populates guest_memfd with user-supplied data in a generic
>>> way, ie no vendor-specific preparation is performed. This is supposed
>>> to be used in non-CoCo setups where guest memory is not
>>> hardware-encrypted.
>>>
>>> The following behaviour is implemented:
>>> - only page-aligned count and offset are allowed
>>> - if the memory is already allocated, the call will successfully
>>> populate it
>>> - if the memory is not allocated, the call will both allocate and
>>> populate
>>> - if the memory is already populated, the call will not repopulate it
>>>
>>> Signed-off-by: Nikita Kalyazin <kalyazin@...zon.com>
>>> ---
>>
>> Just nothing that checkpatch complains about
>>
>> a) Usage of "unsigned" instead of "unsigned int"
>
> Hi David,
>
>
> I copied the prototypes straight from the fs.h... In any case, will fix
> in the next version.
Yes, realized that after I sent it. :)
>
>>
>> b) The From doesn't completely match the SOB: "Kalyazin, Nikita" vs
>> "Nikita Kalyazin"
>
> It's about .com vs .co.uk, I think. Will have to use "From:" apparently.
Yes, discussed that with Patrick on the other thread: sending from .com
is apparently fine.
--
Cheers
David / dhildenb
Powered by blists - more mailing lists