On 5/28/26 7:07 AM, Khushit Shah wrote:
>
>> 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.
I imagined we could return all the data
through query-cpu-model-expansion but it seems you plan to use another
qmp cmd. Let's see what it looks like in your v2
Thanks
Eric
> Sorry, did not fully understand this.
>
> Warm Regards,
> Khushit
>
>> Thoughts?
>>
>> Eric
>>
>>
>>
>>> Warm Regards,
>>> Khushit
