libvirt-devaddr: a new library for device address assignment

[Daniel Henrique Barboza]

On 5/1/20 7:40 AM, Daniel P. Berrangé wrote:
> On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
>>
>> My initial plan is to get the logic/APIs design from Libvirt, rename
>> them in a Gopher fashion, re-code it with Go and call it a day :)
> 
> That is really not a way I would like to go, as that means we immediately
> inherit the design bias of the current libvirt code. The goal is to be
> able to replace current libvirt code eventually, but I don't want it to
> just be a clone of that code, as I think it misses the opportunity to
> try to design something better than what we have done.
> 
> As a particular example.. the current placement code has no conceptual
> model of machine types present in QEMU. We've just got many "if" tests
> that take different codepaths based on heuristics about the machine
> type. I would like the new API to have an explicit conceptual model
> of each machine type we intend to support. ie it should have full
> representation of the default topology of devices that are mandated
> by the machine type. Ideally this modelling should be extendable
> without having to write code in the placement model. ie we should
> be able to load  a "i440fx.yaml" file describing the i440fx machine
> type and the placement logic "just works". We should not have any
> tests like "if (is i440fx)" in the code itself.


That's a sound idea. I'd say that instead of basing yourselves in the QEMU
machine types addressing we should aim in implementing he machine specification
instead, even as a long term goal.

E.G let's say that Libvirt wants addressing services for a hotplug in a QEMU
i440fx guest. Instead of devaddr implementing "this is how the i440fx addressing works
in QEMU", devaddr should be more concerned about "this is how the i440fx processor
addressing works". If QEMU does additional/different things on top of that then
qemu_driver.c should operate on that. This allows devaddr to be hypervisor agnostic.



> 
> The libvirt code shows us the range of features we need to support at
> least though.

I'll see if I can take a look in all the "if (pseries)" in Libvirt device addressing code
to get an idea of how a PowerPC addressing model would work related to x86.



DHB

> 
> Regards,
> Daniel
>