Re: [PATCH v12 08/18] KVM: guest_memfd: Allow host to map guest_memfd pages

[David Hildenbrand <david@redhat.com>]

On 18.06.25 14:17, Xiaoyao Li wrote:
> On 6/18/2025 7:14 PM, David Hildenbrand wrote:
>> On 18.06.25 12:42, Xiaoyao Li wrote:
>>> On 6/18/2025 5:59 PM, David Hildenbrand wrote:
>>>> On 18.06.25 11:44, Xiaoyao Li wrote:
>>>>> On 6/18/2025 5:27 PM, David Hildenbrand wrote:
>>>>>> On 18.06.25 11:20, Xiaoyao Li wrote:
>>>>>>> On 6/18/2025 4:15 PM, David Hildenbrand wrote:
>>>>>>>>> If we are really dead set on having SHARED in the name, it could be
>>>>>>>>> GUEST_MEMFD_FLAG_USER_MAPPABLE_SHARED or
>>>>>>>>> GUEST_MEMFD_FLAG_USER_MAP_SHARED?  But
>>>>>>>>> to me that's _too_ specific and again somewhat confusing given the
>>>>>>>>> unfortunate
>>>>>>>>> private vs. shared usage in CoCo-land.  And just playing the odds,
>>>>>>>>> I'm
>>>>>>>>> fine taking
>>>>>>>>> a risk of ending up with GUEST_MEMFD_FLAG_USER_MAPPABLE_PRIVATE or
>>>>>>>>> whatever,
>>>>>>>>> because I think that is comically unlikely to happen.
>>>>>>>>
>>>>>>>> I think in addition to GUEST_MEMFD_FLAG_MMAP we want something to
>>>>>>>> express "this is not your old guest_memfd that only supports private
>>>>>>>> memory". And that's what I am struggling with.
>>>>>>>
>>>>>>> Sorry for chiming in.
>>>>>>>
>>>>>>> Per my understanding, (old) guest memfd only means it's the memory
>>>>>>> that
>>>>>>> cannot be accessed by userspace. There should be no shared/private
>>>>>>> concept on it.
>>>>>>>
>>>>>>> And "private" is the concept of KVM. Guest memfd can serve as private
>>>>>>> memory, is just due to the character of it cannot be accessed from
>>>>>>> userspace.
>>>>>>>
>>>>>>> So if the guest memfd can be mmap'ed, then it become userspace
>>>>>>> accessable and cannot serve as private memory.
>>>>>>>
>>>>>>>> Now, if you argue "support for mmap() implies support for non-
>>>>>>>> private
>>>>>>>> memory", I'm probably okay for that.
>>>>>>>
>>>>>>> I would say, support for mmap() implies cannot be used as private
>>>>>>> memory.
>>>>>>
>>>>>> That's not where we're heading with in-place conversion support: you
>>>>>> will have private (ianccessible) and non-private (accessible)
>>>>>> parts, and
>>>>>> while guest_memfd will support mmap() only the accessible parts can
>>>>>> actually be accessed (faulted in etc).
>>>>>
>>>>> That's OK. The guestmemfd can be fine-grained, i.e., different
>>>>> range/part of it can have different access property. But one rule never
>>>>> change: only the sub-range is not accessible by userspace can it be
>>>>> serve as private memory.
>>>>
>>>> I'm sorry, I don't understand what you are getting at.
>>>>
>>>> You said "So if the guest memfd can be mmap'ed, then it become userspace
>>>> accessable and cannot serve as private memory." and I say, with in-place
>>>> conversion support you are wrong.
>>>>
>>>> The whole file can be mmaped(), that does not tell us anything about
>>>> which parts can be private or not.
>>>
>>> So there is nothing prevent userspace from accessing it after a range is
>>> converted to private via KVM_GMEM_CONVERT_PRIVATE since the whole file
>>> can be mmaped()?
>>>
>>> If so, then for TDX case, userspace can change the TD-owner bit of the
>>> private part by accessing it and later guest access will poison it and
>>> trigger #MC. If the #MC is only delivered to the PCPU that triggers it,
>>> it just leads to the TD guest being killed. If the #MC is broadcasted,
>>> it affects other in the system.
>>>
>>> I just give it a try on real TDX system with in-place conversion. The TD
>>> is killed due to SIGBUS (host kernel handles the #MC and sends the
>>> SIGBUS). It seems OK if only the TD guest being affected due to
>>> userspace accesses the private memory. But I'm not sure if there is any
>>> corner case that will affect the host.
>>
>> I suggest you go ahead and read all about in-place conversion support,
>> and how it all relates to the #MC problem you mention here.
>>
>> Long story short: SIGBUS is triggered by the fault handler, not by the
>> #MC, because private pages cannot be faulted in and accessed.
>>
> 
> Sorry for the wrong information and thanks for your patience!

No problem. As raised, it would all be clearer if we started out with 
guest_memfd behaving just like memfd (mmap() support etc) and then added 
support for "private" memory on top.

But that's not how it happened :)

-- 
Cheers,

David / dhildenb