Avi Kivity wrote: > >If management apps need to hard-code which slots are available on > >different targets and different qemu versions, or restrictions on which > >devices can use which slots, or knowledge that some devices can be > >multi-function, or ... anything like that is just lame. > > > > You can't abstract these things away. If you can't put a NIC in slot 4, > and you have 7 slots, then you cannot have 7 NICs. Having qemu allocate > the slot numbers does not absolve management from knowing this > limitation and preventing the user from creating a machine with 7 slots. > > Likewise, management will have to know which devices are multi-function, > since that affects their hotpluggability. Ditto if some slot if faster > than others, if you want to make use of this information you have to let > the upper layers know. > > It could be done using an elaborate machine description that qemu > exposes to management coupled with a constraint solver that optimizes > the machine layout according to user specifications and hardware > limitations. Or we could take the view that real life is not perfect > (especially where computers are involved), add some machine specific > knowledge, and spend the rest of the summer at the beach. To be honest, an elaborate machine description is probably fine... A fancy constraint solver is not required. A simple one strikes me as about as simple as what you'd hard-code anyway, but with fewer special cases. Note that the result can fail due to things like insufficient address space for all the device BARs even when they _are_ in the right slots. Especially if there are lots of slots, or bridges which can provide unlimited slots. That is arcane: device-dependent, CPU-dependent, machine-dependent, RAM-size dependent (in a non-linear way), device-option-dependent and probably QEMU-version-dependent too. It would be nice if libvirt (et al) would prevent the user from creating a VM with insufficient BAR space for that machine, but I'm not sure how to do it sanely, without arcane knowledge getting about. Maybe that idea of a .so shared by qemu and libvirt, to manipulate device configurations, is a sane one after all. -- Jamie _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
