Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 1/22/2025 11:28 AM, Chenyi Qiang wrote:
> 
> 
> On 1/22/2025 12:35 AM, Peter Xu wrote:
>> On Tue, Jan 21, 2025 at 09:35:26AM +0800, Chenyi Qiang wrote:
>>>
>>>
>>> On 1/21/2025 2:33 AM, Peter Xu wrote:
>>>> On Mon, Jan 20, 2025 at 06:54:14PM +0100, David Hildenbrand wrote:
>>>>> On 20.01.25 18:21, Peter Xu wrote:
>>>>>> On Mon, Jan 20, 2025 at 11:48:39AM +0100, David Hildenbrand wrote:
>>>>>>> Sorry, I was traveling end of last week. I wrote a mail on the train and
>>>>>>> apparently it was swallowed somehow ...
>>>>>>>
>>>>>>>>> Not sure that's the right place. Isn't it the (cc) machine that controls
>>>>>>>>> the state?
>>>>>>>>
>>>>>>>> KVM does, via MemoryRegion->RAMBlock->guest_memfd.
>>>>>>>
>>>>>>> Right; I consider KVM part of the machine.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> It's not really the memory backend, that's just the memory provider.
>>>>>>>>
>>>>>>>> Sorry but is not "providing memory" the purpose of "memory backend"? :)
>>>>>>>
>>>>>>> Hehe, what I wanted to say is that a memory backend is just something to
>>>>>>> create a RAMBlock. There are different ways to create a RAMBlock, even
>>>>>>> guest_memfd ones.
>>>>>>>
>>>>>>> guest_memfd is stored per RAMBlock. I assume the state should be stored per
>>>>>>> RAMBlock as well, maybe as part of a "guest_memfd state" thing.
>>>>>>>
>>>>>>> Now, the question is, who is the manager?
>>>>>>>
>>>>>>> 1) The machine. KVM requests the machine to perform the transition, and the
>>>>>>> machine takes care of updating the guest_memfd state and notifying any
>>>>>>> listeners.
>>>>>>>
>>>>>>> 2) The RAMBlock. Then we need some other Object to trigger that. Maybe
>>>>>>> RAMBlock would have to become an object, or we allocate separate objects.
>>>>>>>
>>>>>>> I'm leaning towards 1), but I might be missing something.
>>>>>>
>>>>>> A pure question: how do we process the bios gmemfds?  I assume they're
>>>>>> shared when VM starts if QEMU needs to load the bios into it, but are they
>>>>>> always shared, or can they be converted to private later?
>>>>>
>>>>> You're probably looking for memory_region_init_ram_guest_memfd().
>>>>
>>>> Yes, but I didn't see whether such gmemfd needs conversions there.  I saw
>>>> an answer though from Chenyi in another email:
>>>>
>>>> https://lore.kernel.org/all/fc7194ee-ed21-4f6b-bf87-147a47f5f074@intel.com/
>>>>
>>>> So I suppose the BIOS region must support private / share conversions too,
>>>> just like the rest part.
>>>
>>> Yes, the BIOS region can support conversion as well. I think guest_memfd
>>> backed memory regions all follow the same sequence during setup time:
>>>
>>> guest_memfd is shared when the guest_memfd fd is created by
>>> kvm_create_guest_memfd() in ram_block_add(), But it will sooner be
>>> converted to private just after kvm_set_user_memory_region() in
>>> kvm_set_phys_mem(). So at the boot time of cc VM, the default attribute
>>> is private. During runtime, the vBIOS can also do the conversion if it
>>> wants.
>>
>> I see.
>>
>>>
>>>>
>>>> Though in that case, I'm not 100% sure whether that could also be done by
>>>> reusing the major guest memfd with some specific offset regions.
>>>
>>> Not sure if I understand you clearly. guest_memfd is per-Ramblock. It
>>> will have its own slot. So the vBIOS can use its own guest_memfd to get
>>> the specific offset regions.
>>
>> Sorry to be confusing, please feel free to ignore my previous comment.
>> That came from a very limited mindset that maybe one confidential VM should
>> only have one gmemfd..
>>
>> Now I see it looks like it's by design open to multiple gmemfds for each
>> VM, then it's definitely ok that bios has its own.
>>
>> Do you know why the bios needs to be convertable?  I wonder whether the VM
>> can copy it over to a private region and do whatever it wants, e.g.  attest
>> the bios being valid.  However this is also more of a pure question.. and
>> it can be offtopic to this series, so feel free to ignore.
> 
> AFAIK, the vBIOS won't do conversion after it is set as private at the
> beginning. But in theory, the VM can do the conversion at runtime with
> current implementation. As for why make the vBIOS convertable, I'm also
> uncertain about it. Maybe convenient for managing the private/shared
> status by guest_memfd as it's also converted once at the beginning.

The reason is just that we are too lazy to implement a variant of guest 
memfd for vBIOS that is disallowed to be converted from private to shared.

>>
>> Thanks,
>>
>