On 06/17/2009 11:33 AM, Mark McLoughlin wrote:
I particularly don't like the idea of arcane machine-dependent slot
allocation knowledge living in libvirt, because it needs to be in Qemu
anyway for non-libvirt users. No point in having two implementations
of something tricky and likely to have machine quirks, if one will do.
Indeed.
I don't understand this. Management already has to allocate MAC
addresses, UUIDs, IDE interface and master/slave role, SCSI
LUNs/targets/whatever. It has to understand NUMA (if not do actual
allocation). Even if it doesn't allocate the slots, it has to be able
to query them so it can tell the user which NIC or controller is
connected where, or to do hotunplug. It has to understand that there is
a limitation on the number of slots, and know what that limitation is
(unless it feels that launching an overcommitted guest and showing an
error to the user is preferable to not allowing the user to overcommit
in the first place.
If you'll review my patent application for pci slot allocation, you'll
see the following line:
slot_nr = nb_allocated_slots++; /* Allocate pci slot */
while there is a lot of complicated setup code before that (see the
prior art section as well), I believe licensees could well implement the
algorithm in two short months, including testing.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
