Re: [PATCH v5 12/12] RFC: monitor: add 'info ramblock-attributes' command

[Markus Armbruster <armbru@redhat.com>]

Marc-André Lureau <marcandre.lureau@redhat.com> 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 <marcandre.lureau@redhat.com>
> ---
>  qapi/machine.json             | 56 ++++++++++++++++++++++++++++++++++
>  include/monitor/hmp.h         |  1 +
>  hw/core/machine-hmp-cmds.c    | 32 +++++++++++++++++++
>  system/ram-block-attributes.c | 71 +++++++++++++++++++++++++++++++++++++++++++
>  hmp-commands-info.hx          | 13 ++++++++
>  5 files changed, 173 insertions(+)
>
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 685e4e29b87..a1af5c61176 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -1738,6 +1738,62 @@
>    '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.

> +#
> +# @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

Can we assume that anybody with a use for x-query-ramblock-attributes
understands what "range is shared" means?

> +#
> +# @populated: true if the entire range is fully populated across all
> +#     RamDiscardManager sources; false if any sub-block is discarded.
> +#     Only present when a RamDiscardManager is managing the block.

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

Apparently, this is a memory region name, obtained with
memory_region_name().  Correct?

If yes, then what about "@name: the memory region name"?  Or maybe "the
name of the RAM block's memory region"?

> +#
> +# @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.

Ignorant question: 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:
>  #

[...]