On Thu, Jan 15, 2026 at 05:33:56PM +0100, David Hildenbrand (Red Hat) wrote: > On 1/15/26 14:55, Lorenzo Stoakes wrote: > > On Thu, Jan 15, 2026 at 10:20:12AM +0100, David Hildenbrand (Red Hat) wrote: > > > Let's make it consistent with the naming of the files but also with the > > > naming of CONFIG_BALLOON_MIGRATION. > > > > > > While at it, add a "/* CONFIG_BALLOON */". > > > > Probably not relevant but cheap for me to share :) so grepped for > > 'memory_balloon' and saw: > > > > include/uapi/linux/virtio_ids.h > > 44:#define VIRTIO_ID_MEMORY_BALLOON 13 /* virtio memory balloon */ > > > > This maybe relevant (I guess this isn't actually used anywhere?) though > > interesting there is also VIRTIO_ID_BALLOON... hmm :) > > Yeah, we want to leave the virtio stuff alone. > > Now you'll learn something you probably wish you wouldn't know: > > As you spotted, there is > > #define VIRTIO_ID_BALLOON 5 /* virtio balloon */ > > And > > #define VIRTIO_ID_MEMORY_BALLOON 13 /* virtio memory balloon */ > > > The virtio-spec [1] defines ID 5 to be the "Traditional Memory Balloon > Device". > > And in there, we document that > > "This is the traditional balloon device. The device number 13 is reserved for > a new memory balloon interface, with different semantics, which is expected > in a future version of the standard. " > > That's in the spec already like, forever. Likely, at some point someone > wanted to implement a > new version (for whatever reason) and defined ID 13. But that never happened. > > So now we have these beautiful two device IDs. > > I'll note that the spec also defines a "DEVICE ID of Virtio Cpu balloon > device as 47". But > no changes really happened in the spec with that for the last two years (only > the > id is reserved). > > > [1] https://docs.oasis-open.org/virtio/virtio/v1.4/virtio-v1.4.html#x1-4260001 >
Lord haha well that explains that ;) > -- > Cheers > > David Cheers, Lorenzo
