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é" <[email protected]>
> 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/[email protected]/
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
