libvirt-devaddr: a new library for device address assignment

Daniel P. Berrangé berrange at redhat.com
Fri May 1 16:00:44 UTC 2020


On Fri, May 01, 2020 at 12:57:54PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> 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.

Yes, it was not intended to be tied to QEMU's specific implementation
either. It should be a generic modelling / addressing system.

> > 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list