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