[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: RFC qdev path semantics
From: |
Alex Williamson |
Subject: |
[Qemu-devel] Re: RFC qdev path semantics |
Date: |
Thu, 17 Jun 2010 16:34:35 -0600 |
On Thu, 2010-06-17 at 23:01 +0100, Paul Brook wrote:
> > > ### Paul proposes to require all buses to define bus addresses. Make
> > > one up if necessary.
> >
> > That seems arbitrary and prone to breakage. How do we handle a subtle
> > change in device instantiation order and still allow migration? If by
> > code change or command line ordering my frobnitz moves from:
> >
> > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0
> >
> > to
> >
> > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1
>
> Two things are apparent here.
> (a) You've clearly misunderstood the proposals. The paths above make no sense.
Sorry, hastily created paths. Though yes, I am a little unclear of the
proposal, feel free to code up how it should work. I hope the other
follow-up I just sent is more correct.
> (b) You've picked a particularly poor definition of device address for the
> ISA
> bus. We can do much better than device creation order.
Ok, how?
> > ...
> > I can live with PATH/@BUS-ADDR if it's still felt that
> > PATH/address@hidden isn't canonical. What that means is that I'll
> > probably code up vmstate and ramblocks to append IDENT themselves to
> > keep all the goodness of having per PATH/IDENT namespaces.
>
> As discussed elsewhere in this thread, addition of IDENT to the device path
> is
> neither necessary nor sufficient for migration.
>
> I really feel like we're going round in circles here.
Um, I believe I just agreed to remove IDENT from the canonical path and
append it in a usage specific way. I think I've cited a couple relevant
examples of how this can improve the robustness of migration and I have
yet to hear anything but conjecture that this is only a false sense of
security.
Alex
- [Qemu-devel] Re: RFC qdev path semantics, (continued)
[Qemu-devel] Re: RFC qdev path semantics, Markus Armbruster, 2010/06/16
[Qemu-devel] Re: RFC qdev path semantics, Alex Williamson, 2010/06/17
[Qemu-devel] Re: RFC qdev path semantics, Gerd Hoffmann, 2010/06/18
[Qemu-devel] Re: RFC qdev path semantics, Markus Armbruster, 2010/06/18
[Qemu-devel] Re: RFC qdev path semantics, Anthony Liguori, 2010/06/22