On 17.10.25 10:14, Chenyi Qiang wrote:
Currently, private memory and shared memory have different backend in
CoCo VMs. It is possible for users to specify the shared memory with
hugetlbfs backend while private memory with guest_memfd backend only
supports 4K page size. In this case, ram_block->page_size is different
from the host page size which will trigger the assertion when getting
block size. Relax the restriction to allow shared memory to use
hugetlbfs backend.
Please mention that the VM can do conversion in base page granularity,
consequently that is the granularity in which we have to track things.
And in the relevant setups we assume that target page size == host page
size.
Fixes: 5d6483edaa92 ("ram-block-attributes: Introduce RamBlockAttributes to manage
RAMBlock with guest_memfd")
Signed-off-by: Chenyi Qiang <[email protected]>
---
system/ram-block-attributes.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/system/ram-block-attributes.c b/system/ram-block-attributes.c
index 68e8a027032..0f39ccf9090 100644
--- a/system/ram-block-attributes.c
+++ b/system/ram-block-attributes.c
@@ -28,10 +28,11 @@ ram_block_attributes_get_block_size(const
RamBlockAttributes *attr)
* Because page conversion could be manipulated in the size of at least 4K
* or 4K aligned, Use the host page size as the granularity to track the
* memory attribute.
+ * When hugetlbfs is used as backend of shared memory, ram_block->page_size
+ * is different from host page size. So it is not appropriate to use
+ * ram_block->page_size here.
I don't think that comment is required. The comment above already states
the relevant thing: "Use the host page size as the granularity to track
the memory attribute."
Acked-by: David Hildenbrand <[email protected]>
--
Cheers
David / dhildenb
