On Tue, 10 Feb 2026, Zhao Liu wrote:

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@redh...

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...

So another way could be to not use properties for internal settings but add another set of internal properties for those. These could be set the same way but stored in a different hash table and not get mixed with introspectable and user changable properties. But maybe that would be too much refactoring. Regards, BALATON Zoltan