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
> …
>
>
> 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
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?
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.
Thoughts?
Eric
>
> Warm Regards,
> Khushit
