From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: RFC qdev path semantics Date: Thu, 17 Jun 2010 16:34:35 -0600 Message-ID: <1276814075.3216.60.camel@x201> References: <20100614054923.879.33717.stgit@localhost.localdomain> <1276811010.3216.25.camel@x201> <201006172301.22115.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , qemu-devel@nongnu.org, chrisw@redhat.com, kvm@vger.kernel.org, kraxel@redhat.com, avi@redhat.com To: Paul Brook Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41972 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753543Ab0FQWeq (ORCPT ); Thu, 17 Jun 2010 18:34:46 -0400 In-Reply-To: <201006172301.22115.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: 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/IDENT@BUS-ADDR 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