Re: [PATCH v2 00/21] qom: introduce property flags to track external user input

[Zhao Liu <zhao1.liu@intel.com>]

Hi Daniel,

On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote:
> Date: Tue, 10 Feb 2026 10:12:38 +0000
> From: "Daniel P. Berrangé" <berrange@redhat.com>
> Subject: Re: [PATCH v2 00/21] qom: introduce property flags to track
>  external user input
> 
> On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote:
> > Hi,
> > 
> > This is the v2 trying to introduce property flags to detect user's
> > property setting (from CLI/QMP/HMP). I dropped RFC tag since previous
> > RFC v1 [1].
> 
> This says what the series is proposing, but IMHO what is more important
> here is explaining why this either desirable or appropriate to add as
> general facility in QOM.

Yes, sorry this cover letter I wrote is overly simplified.

This series tries to control the property access against external user.
USER_SET is the base to track external user's behavior, and DEPRECATED &
INTERNAL flags provide different levels of access control.

Though the DEPRECATED flag does not inherently restrict access, I think
such a warning also serves as a form of control.

The idea of restricting external access to properties is from previous
discussions [*] about internal properties.

[*]: How to mark internal properties:
     https://lore.kernel.org/qemu-devel/2f526570-7ab0-479c-967c-b3f95f9f19e3@redhat.com/

Since that disscussion, currently all properties expected to be
"internal" have an “x-” prefix — while this approach can work, it clearly
confuses the original meaning of “x-”, which actually means "unstable".

Therefore, I think the optimal approach is to provide the capability to
restrict external access to the property — that is, to implement the
"true" internal property.

Based on this, it seems impossible to implement an internal property
without tracking user input in the QOM?

> The idea that code should take different action for a given fixed value,
> based on whether the value was set by the user, or left on the default,
> makes me very uncomfortable.
> 
> There have been a number of situations where something that was initially 
> a boolean flag, actually needed to be a tri-state instead, to provide
> semantics like "On", "Off", "Auto".
> 
> This "user set" flag could support such behaviour indirectly, but since
> "user set" is an internal concept we'd still be only exposing a boolean
> externally, while using a tri-state internally. That does not give the
> full flexibility of a tri-state, because internally if we wanted to
> have the default to be "yes", it offers no way for the mgmt app to
> put it back to "auto".
> 
> For properties that are not booleans, it is much less obvious to me
> whether we actually need a distinct "not set" concept at all.

USER_SET primarily serves the INTERNAL and DEPRECATED flags. However,
its another function is to indicates whether the external user has
touched the property.

But, Hmm, I think "auto" and USER_SET don't have conflict?

IIUC, "auto" means the user requests that QEMU make the decision itself.
However, just like my patch 19 cleanup of “lbr-fmt”, that property
explicitly requires users to provide a valid value. Even we have "auto"
for uint64, "auto" can't address this case.

Similarly, the x86 CPU's topology IDs (used for hotplug) - "thread-id"/
"core-id"/"module-id"..., also require the user to set valid and accurate
values; they cannot be replaced with "auto".

These existing cases all check user input for magic numbers. I hope to
simplify these existing logic using USER_SET.

> So overall, at a conceptual level, I don't think that QOM should care
> about /how/ a value came to be set. It should have no direct awareness
> of the "user input", rather it just represents the configuration of the
> system at a given point in time,  however that came to pass.

I also think the ideal situation is not to distinguish between external
and internal - however, exposing properties to external users makes code
evolution painful...

Thanks,
Zhao