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.
