Marc-André Lureau <[email protected]> writes: > Hi Markus > > I am not an expert in this area, and I am only working on this series > occasionally (too little activity to keep me fresh on the topic, > unfortunately). Bear with me.
Sure! > On Mon, May 18, 2026 at 10:34 AM Markus Armbruster <[email protected]> wrote: >> >> Marc-André Lureau <[email protected]> writes: >> >> > Add a new 'info ramblock-attributes' HMP command and the corresponding >> > 'x-query-ramblock-attributes' QMP command to display the shared/private >> > memory attributes for ram blocks. >> > >> > The QMP command returns structured data (RamBlockAttributesInfo list >> > with per-range shared/populated attributes), while HMP formats it for >> > human consumption. >> > >> > This is useful for debugging confidential guests (TDX, SNP) to inspect >> > which memory regions are shared vs private, and their population state >> > when a RamDiscardManager is present (e.g. virtio-mem). >> > >> > Signed-off-by: Marc-André Lureau <[email protected]> >> > --- >> > qapi/machine.json | 55 +++++++++++++++++++++++++++++++++ >> > include/monitor/hmp.h | 1 + >> > hw/core/machine-hmp-cmds.c | 32 +++++++++++++++++++ >> > system/ram-block-attributes.c | 72 >> > +++++++++++++++++++++++++++++++++++++++++++ >> > hmp-commands-info.hx | 13 ++++++++ >> > 5 files changed, 173 insertions(+) >> > >> > diff --git a/qapi/machine.json b/qapi/machine.json >> > index 685e4e29b87..aac8a235cf6 100644 >> > --- a/qapi/machine.json >> > +++ b/qapi/machine.json >> >> I have a few fairly ignorant questions. They may or may not indicate a >> need for doc improvements. >> >> > @@ -1738,6 +1738,61 @@ >> > 'returns': 'HumanReadableText', >> > 'features': [ 'unstable' ] } >> > >> > +## >> > +# @RamBlockAttributeRange: >> > +# >> > +# A contiguous range within a ram block with uniform attributes. >> >> RAM please. More of the same below, not flagging it again. >> > > ok > >> > +# >> > +# @start: start offset in bytes within the ram block >> > +# >> > +# @length: length in bytes of the range >> > +# >> > +# @shared: true if the range is shared, false if private >> >> What does it mean for a range to be shared? > > commit 5d6483edaa9232d8f3709f68c8eab4bc2033fb70 > "in the current context > of RamDiscardManager for guest_memfd, the shared state is analogous to > being populated, while the private state can be considered discarded for > simplicity. In the future, it would be more complicated if considering > more states like private/shared/discarded at the same time." Thought and care went into that commit message. Unfortunately, it's still greek to me. Not criticism! It needs to make sense to the people working in that area, and I'm not. Can we assume that anybody with a use for x-query-ramblock-attributes understands what "range is shared" means? >> > +# >> > +# @populated: true if the range is populated (only present when a >> > +# RamDiscardManager is managing the block) >> >> What's a RamDiscardManager? > > commit 8947d7fc4e77d36fae44411b1b63c513863f89a7 > * A #RamDiscardManager coordinates which parts of specific RAM #MemoryRegion > * regions are currently populated to be used/accessed by the VM, notifying > * after parts were discarded (freeing up memory) and before parts will be > * populated (consuming memory), to be used/accessed by the VM. > > In this series, RamDiscardManager learned to aggregate from multiple > sources (virtio-mem + RamBlockAttributes), so virtio-mem can work with > confidential VMs. Can we assume that anybody with a use for x-query-ramblock-attributes understands what "a RamDiscardManager is managing the block" means? I can't find anything about RamDiscardManager in docs. Would it make sense to have something there, so we can point to it here? >> > +# >> > +# Since: 11.1 >> > +## >> > +{ 'struct': 'RamBlockAttributeRange', >> > + 'data': { 'start': 'uint64', >> > + 'length': 'uint64', >> > + 'shared': 'bool', >> > + '*populated': 'bool' } } >> > + >> > +## >> > +# @RamBlockAttributesInfo: >> > +# >> > +# Shared/private memory attributes for a ram block. >> > +# >> > +# @name: the ram block identifier >> >> Where do RAM block names come from? > > They are set during vmstate_register_ram(). "idstr" and "name" are > used interchangeably to refer to it. void vmstate_register_ram(MemoryRegion *mr, DeviceState *dev) { qemu_ram_set_idstr(mr->ram_block, memory_region_name(mr), dev); qemu_ram_set_migratable(mr->ram_block); ram_block_add_cpr_blocker(mr->ram_block, &error_fatal); } Looks like it's the name of the memory region associated with the RAM block. Would "the memory region name" do? Or would something like "the name of the RAM block's memory region" be better? >> >> > +# >> > +# @ranges: list of attribute ranges >> > +# >> > +# Since: 11.1 >> > +## >> > +{ 'struct': 'RamBlockAttributesInfo', >> > + 'data': { 'name': 'str', >> > + 'ranges': [ 'RamBlockAttributeRange' ] } } >> > + >> > +## >> > +# @x-query-ramblock-attributes: >> > +# >> > +# Query ram block shared/private attributes. This is useful >> > +# to debug confidential guests. >> >> What are RAM blocks? > > They are the actual host allocated memory backing guest RAM MemoryRegions How are RAM blocks related to memory regions? >> > +# >> > +# Features: >> > +# >> > +# @unstable: This command is meant for debugging. >> > +# >> > +# Returns: list of ram block attributes >> > +# >> > +# Since: 11.1 >> > +## >> > +{ 'command': 'x-query-ramblock-attributes', >> > + 'returns': [ 'RamBlockAttributesInfo' ], >> > + 'features': [ 'unstable' ] } >> > + >> > ## >> > # @x-query-roms: >> > # >> >> [...]
