> On 27 May 2026, at 9:49 PM, Eric Auger <[email protected]> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > > > On 5/27/26 5:44 PM, Khushit Shah wrote: >> >>> On 27 May 2026, at 9:02 PM, Eric Auger <[email protected]> wrote: >>> >>> I replied separately to this on your series thread. I am inclined to do >>> so but this raises another problematic for the layered products to know >>> which mismatch can be fixed >>> >>> Thanks >>> >>> Eric >>> >> >> Hence the safe-value tags :), sneak peek to v2 of RFC, with safe-value tags. >> For each prop we can say: >> ... >> { >> "name": "feat_RDM", >> "supported-values": [ >> "off", >> "on" >> ], >> "type": "string" >> }, >> { >> "name": "feat_ATOMIC", >> "supported-values": [ >> "off", >> "on" >> ], >> "type": "string" >> }, >> { >> "name": "feat_CRC32", >> "supported-values": [ >> "off", >> "on" >> ], >> "type": "string" >> }, >> { >> "name": "feat_SHA2", >> "supported-values": [ >> "off", >> "sha256", >> "sha512" >> ], >> "type": "string" >> }, >> { >> "name": "feat_SHA1", >> "supported-values": [ >> "off", >> "on" >> ], >> "type": "string" >> }, >> { >> "name": "feat_AES", >> "supported-values": [ >> "off", >> "aes", >> "pmull" >> ], >> "type": "string" >> } >> { >> "name": "feat_NV", >> "supported-values": [ >> "0.0" >> ], >> "type": "string" >> }, >> { >> "name": "feat_RAS", >> "supported-values": [ >> "0.0", >> "1.0", >> "1.1_base" >> ], >> "type": "string" >> }, >> { >> "name": "feat_MPAM", >> "supported-values": [ >> "0.0" >> ], >> "type": "string" >> }, >> { >> "name": "feat_CSV2", >> "supported-values": [ >> "0.0", >> "1.0" >> ], >> "type": "string" >> }, > I am not sure what the above represents
This is truncated output of similar qmp command as cpu-model-expansion, which returns for each prop what values can be set. For example MPAM is not writable by KVM, hence only one supported value “0.0”, CSV2 on the host is only “1.0” (architecturally, 2.0 is also valid), hence only “0.0” and “1.0” in the supported values. >> … >> >> >> I am inclined to do so but this raises another problematic for the layered >> products to know which mismatch can be fixed >> >> I am tempted to make the same argument for writable fields: how will the >> layered products know which values are safe (or effectively can be set?)? >> >> I know right now we don’t agree on keeping safe-value tags or default values. >> But, I hope the above inclines you towards keeping those :) > > OK I think I now understand what you plan to do with safe_rule (which, > as far as I understand is not currently implemented in your v1). With a > "tool" like Yes not implemented in v1. > > query-cpu-model-expansion you would be able to retrieve the host value. If it > does not match your named model default value, you can use the safe_rule to > see if it could be applied, without relying on any scratch vcpu > instantiation. This makes sense in the context of providing ways for layered > products to see which vcpu model can be used, assuming there is no other way > like scratch vcpu instantiation. > > Is that a correct understanding? Yes!!! > I think this implies that we need to return more information though > query-cpu-model-expansion than what we currently do (at least in [1] we only > return the value). We would need to return whether the prop value can apply > on this host (its default value is same as host value or OK with regards to > host value and safe rule and the ID reg field is writable). This most > probably means we need to enhance the prop value to contain more fields. Sorry, did not fully understand this. Warm Regards, Khushit > Thoughts? > > Eric > > > >> >> Warm Regards, >> Khushit >
