On 11.12.2024 20:56, Daniel P. Smith wrote:
> On 12/2/24 07:23, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/domain_builder/fdt.c
>>> +++ b/xen/arch/x86/domain_builder/fdt.c
>>> @@ -209,6 +209,19 @@ static int __init process_domain_node(
>>> bd->max_vcpus = val;
>>> printk(" max vcpus: %d\n", bd->max_vcpus);
>>> }
>>> + if ( match_fdt_property(fdt, prop, "capabilities" ) )
>>> + {
>>> + if ( fdt_prop_as_u32(prop, &bd->capabilities) != 0 )
>>> + {
>>> + printk(" failed processing domain id for domain %s\n",
>>> + name == NULL ? "unknown" : name);
>>> + return -EINVAL;
>>> + }
>>> + printk(" caps: ");
>>> + if ( bd->capabilities & BUILD_CAPS_CONTROL )
>>> + printk("c");
>>> + printk("\n");
>>> + }
>>
>> What if any of the other bits is set?
>
> I'm not sure what you are getting at, but there is another cap added
> later for HARDWARE and it will print an 'h' next to the 'c' if set.
And that bit, when set, will likely have meaning beyond this mere printing?
If so, what's the effect on the domain when the bit is set, but the code
consuming the bit isn't there yet? Will the domain function correctly? IOW
shouldn't you reject any set bits that the code doesn't know how to handle?
And then perhaps report all unknown bits in a numeric value here?
Jan
