From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq1IR-0000et-6h for qemu-devel@nongnu.org; Wed, 25 Jan 2012 06:45:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rq1IL-0004sR-BQ for qemu-devel@nongnu.org; Wed, 25 Jan 2012 06:45:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rq1IL-0004sL-4e for qemu-devel@nongnu.org; Wed, 25 Jan 2012 06:45:41 -0500 Message-ID: <4F1FEB59.8060102@redhat.com> Date: Wed, 25 Jan 2012 13:45:29 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com> <1326975896.17599.81.camel@zakaz.uk.xensource.com> <1326981859.17599.87.camel@zakaz.uk.xensource.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to xenstore List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: "jan.kiszka@siemens.com" , "xen-devel@lists.xensource.com" , Ian Campbell , "qemu-devel@nongnu.org" On 01/19/2012 04:16 PM, Stefano Stabellini wrote: > > > > If you are migrating to a newer qemu then the could in > > principal change, I think. > > Not unless the implementation of qemu_ram_alloc_from_ptr or > find_ram_offset change, but these are core qemu functions. Both of these functions will be removed. There will no longer be a qemu-internal address space for physical memory; instead memory will be addressed using a (MemoryRegion, offset) pair. We can/will hook memory_region_init_ram() to call xen_ram_alloc() which can then generate those old addresses, but those (like qemu_ram_alloc()) are dependent on allocation order and you shouldn't depend on them returning stable values. > Or the device starts allocating more memory of course, but it wouldn't > be the same device anymore. > In any case, if we also match on the MemoryRegion name we cannot go > wrong. Match on just the MemoryRegion (and match on the object itself, not the name; see xen_register_framebuffer()). > > > We could add some additional info to better identify the physmap entry, > > > probably the best we could use is the memory_region name. > > > > And/Or the PCI BDF + BAR? > > I don't think we can get the PCI BDF from the Xen MemoryListener, but we > can get the MemoryRegion. The most identifying info in it I think is the > name, for example for vga would be "vga.vram". -- error compiling committee.c: too many arguments to function