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:
fc7194ee-ed21-4f6b-bf87-147a47f5f074@intel.com/">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.