[libvirt] [RFC PATCH 0/3] improve virtio-serial port address allocation

[Jonathan Lebon]

This series of patches improves the way in which virtio-serial port
addresses are handled. See BZ1042505[1] for more background information.
In a nutshell, the issue is that libvirt always assigns ports to the
same virtio-serial controller (index 0). It does not take into account
the maximum number of ports of the controller, nor whether there are
other controllers with free ports.

These patches modify the behaviour of libvirt in two ways:
1. Ports assigned out-of-range numbers are rejected right away, rather
   than having qemu failing at startup (see patch 2/3).
2. Ports without any explicit <address> elements are assigning a
   controller guaranteed to hold a free port, rather than always using
   controller index 0 (see patch 3/3).

Care was taken to not override any field explicitly specified by the
user (e.g. if the controller index is given, then that controller will
be used).

However, there are a few shortcomings with these patches (mostly due to
my inexperience with the libvirt codebase and virtualization in
general):
1. The limit of 31 ports per controller, mentioned here [2], is specific
   to qemu/kvm (although it is the only driver that supports
   virtio-serial ports for now). I've hardcoded the constant in these
   patches because I'm not sure how to properly contain them within
   qemu-specific code. There doesn't seem to be a way to query qemu to
   find out what the number of maximum ports are but looking at the qemu
   codebase indicates that the limit has always been 31. Not sure if a
   simple #define would be suitable for this.
2. I'm not sure how to handle the 'bus' attribute of virtio-serial port
   <address> elements. I haven't been able to get information regarding
   whether the bus is always 0, or how it affects port numbering. (So
   far haven't been able to start a VM with bus != 0).
3. More broadly, I'm not sure how in line these patches are with the
   overall design of libvirt. It seems like domain definitions should be
   completely independent of driver limitations, in which case enforcing
   a maximum number of ports at domain-definition-time might be the
   wrong thing to do. But since it is clear from the BZ that libvirt
   currently can modify the definition into an invalid unstartable
   state, it might be too late to go back on our word there.

Advice and feedback appreciated,

Jonathan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1042505
[2] https://fedoraproject.org/wiki/Features/VirtioSerial?rd=VirtioSerial#Device

Jonathan Lebon (3):
  add new function virDomainGetVirtioMaxPort
  check for out-of-range virtio-serial ports
  assign free controller to virtio-serial port

 src/conf/domain_conf.c | 77 ++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 66 insertions(+), 11 deletions(-)

-- 
1.8.3.1