From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44490 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMBjw-0006ci-7z for qemu-devel@nongnu.org; Tue, 08 Jun 2010 23:14:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMBjv-0002HO-3p for qemu-devel@nongnu.org; Tue, 08 Jun 2010 23:14:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4331) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMBju-0002H8-RG for qemu-devel@nongnu.org; Tue, 08 Jun 2010 23:14:03 -0400 From: Alex Williamson In-Reply-To: <20100608214103.GT28492@x200.localdomain> References: <20100608191447.4451.47795.stgit@localhost.localdomain> <20100608191557.4451.30384.stgit@localhost.localdomain> <20100608214103.GT28492@x200.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Jun 2010 21:13:58 -0600 Message-ID: <1276053238.3079.51.camel@x201> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH 3/6] RAMBlock: Add a name field List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Wright Cc: quintela@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org On Tue, 2010-06-08 at 14:41 -0700, Chris Wright wrote: > * Alex Williamson (alex.williamson@redhat.com) wrote: > > + // XXX check duplicates > > Yes, definitely. Yep, I was just thinking that without freeing, the uniqueness really falls apart. If we hotplug a nic multiple times on the source, we're going to have multiple pci:d.f for the slot. If we're lucky, they're all for the same type of device and therefore the same ROM size and the ordering will cause them to be merged into one on the target. That requires a lot of luck though. Maybe once we have freeing we just blow up and call it a device bug if it didn't free and tries to add more ram with the same name. > You created a notion of a hierarchical namespace, > can this be formalized any more? Currently scattered... Yeah, it's pretty haphazard, I probably haven't spent enough time working out what makes sense across all devices. I started with "ram..", where context was whatever I could guess from the surrounding code. Then I jumped over to "pci:d.f" (which should at least be "pci.s:b:d.f") just because I thought the PCI address space already provided a nicely unique layout. > > + char name[14]; > > + snprintf(name, sizeof(name), "pci:%02x.%x.bar%d", > > + PCI_SLOT(pci_dev->dev.devfn), > > + PCI_FUNC(pci_dev->dev.devfn), i); > > + pci_dev->v_addrs[i].memory_index = qemu_ram_map(name, > > + cur_region->size, virtbase); > > + ram_addr = qemu_ram_alloc("ram.pc.lowmem", below_4g_mem_size); > > + ram_addr = qemu_ram_alloc("ram.pc.highmem", above_4g_mem_size); > > + bios_offset = qemu_ram_alloc("ram.pc.bios", bios_size); > > + option_rom_offset = qemu_ram_alloc("ram.pc.rom", PC_ROM_SIZE); > > + char name[13]; > (13, 14...good to be consistent, maybe w/ helper like, pci_ram_alloc_{bar,rom}) That probably makes sense. > > + snprintf(name, sizeof(name), "pci:%02x.%x.rom", > > + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); > > + pdev->rom_offset = qemu_ram_alloc(name, size); > > + s->vram_offset = qemu_ram_alloc("ram.vga.vram", vga_ram_size); > > + s->fifo_offset = qemu_ram_alloc("ram.vmsvga.fifo", s->fifo_size); > > So far we have: > ram. > pc. > lowmem > highmem > bios > rom > vga. > vram > vmsvga. > fifo So maybe we say "ram." = "platform devices", things that have single instances or are easy to split up into fixed, unique names. > pci. > D.F. (B:D.F?) > bar > rom This one is pretty obvious. If this is a reasonable starting point, I can start hashing through the other archs and take a guess at what makes sense. Thanks, Alex