On 2026-04-21 5:26 PM, Peter Krempa wrote: [snip]
@@ -13125,7 +13148,8 @@ virDomainSetGuestVcpus(virDomainPtr domain, * @domain: pointer to domain object * @vcpumap: text representation of a bitmap of vcpus to set * @state: 0 to disable/1 to enable cpus described by @vcpumap - * @flags: bitwise-OR of virDomainModificationImpact + * @flags: bitwise-OR of virDomainModificationImpact with optional + * VIR_DOMAIN_VCPU_ASYNC
You can't do this. You'll need to add a new enum of flags specifically for this API. Mirror virDomainModificationImpact in the enum and add new flags separately.
Doesn't it make more sense to add this flag to `enum virDomainVcpuFlags`, since that enum already encompasses all the other flags that are used in the two functions (qemuDomainSetVcpusFlags and qemuDomainSetVcpu)? If I mirror
No, because since 'virDomainSetVcpu' accepts only a subset of the flags you can't then state in the documentation that 'flags' is a bitwise-or of 'virDomainVcpuFlag'. You'd then have to express in text that some flags are not in fact supported.
In fact many of the flags such as VIR_DOMAIN_VCPU_MAXIMUM make no sense with 'virDomainSetVcpu' so it makes no sense to even have them there.
`virDomainModificationImpact` and create a new enum then there's a false positive in qemuDomainSetVcpusFlags, since the enum values of `VIR_DOMAIN_VCPU_GUEST` will collide with this new flag (added immediately
That isn't a problem, because either of those functions will extract it before passing into the internals.
Understood. My earlier confusion stemmed from the fact that the flags being passed to either of the setvcpu/setvcpuflags functions were still using the original VIR_DOMAIN_AFFECT_* enums, even though they had equivalents defined in each new enum. That led me to make a false association with the original `virDomainModificationImpact` enum continuity. I'd like to fix this in a separate patch that uses the correctly-named aliases from the appropriate enum defined for the functions. Since this is a cosmetic-only change and has a potential to conflict with some hunks from v2 of this changeset, I will send that patch out separately once this changeset comes to a head. Will be sending out a v2 shortly.