On Thu, Dec 01, 2011 at 05:38:31PM +1100, Michael Ellerman wrote:
> On Wed, 2011-11-30 at 12:44 +0000, Daniel P. Berrange wrote:
> > On Tue, Nov 29, 2011 at 08:33:09PM +0530, Prerna Saxena wrote:
> > > From: Michael Ellerman <michael@xxxxxxxxxxxxxx>
> > > Date: Tue, 29 Nov 2011 13:48:09 +0530
> > > Subject: [PATCH 5/5] Add address-type "spapr-vio" for devices based on
> > > the same bus.
> > >
> > > For QEMU PPC64 we have a machine type ("pseries") which
> > > has a virtual bus called "spapr-vio". We need to be
> > > able to create devices on this bus, and as such need a
> > > way to specify the address for those devices.
> > >
> > > This patch adds a new address type "spapr-vio", which achieves this.
> > >
> > > The addressing is specified with a "reg" property in the address
> > > definition. The reg is optional, if it is not specified QEMU will
> > > auto-assign an address for the device.
> >
> > In libvirt, we need to guarantee that addressing is stable across
> > QEMU releases. So if the 'reg' property is not set in the XML,
> > libvirt must auto-assign one itself before starting QEMU.
>
> Must we really? IMHO if the user doesn't specify anything then that is
> essentially asking for "the default", whatever that is.
>
> My reasoning for putting the address assignment code in QEMU in the
> first place was that it has the most knowledge and so can make the best
> decision.
>
> > You'll notice we have a qemuDomainAssignPCIAddresses() API.
> > We will need to have some kind of equivalent for sparpr-vio
> > "reg" addresses. Ideally libvirt will auto-assign using the
> > same algorithm as QEMU would have, just for sake of sanity.
>
> Yeah I've seen it. I'd rather not do anything similar for spapr-vio,
> precisely because we will end up with identical duplicate code in
> libvirt & QEMU.
>
> But if it's a hard requirement in your view then I'll do it.
It is the only way to ensure stable device addresses every time the
guest is started.
eg, consider what happens if you don't assign addresses
qemu -drive foo -drive bar
QEMU assigns foo reg=1, bar reg=2. Now delete hotunplug a device
(qemu) drive_del foo
Now migrate QEMU to a new host, which means it'll be started with
qemu -drive bar
So QEMU will assign bar reg=1, whereas the guest OS currently
thinks it has reg=2.
libvirt *must* define addresses for every single device it passes to
QEMU at all times. Even if we ignore hotplug, and just consider that
we cold unpluged 'foo', we still want 'bar' to have the same address,
in case the guest OS had configured something based on address, or
worse yet done an OS license/activation check based on hardware config.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list