qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Chris Wright <chrisw@redhat.com>
Cc: quintela@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: [Qemu-devel] Re: [RFC PATCH 3/6] RAMBlock: Add a name field
Date: Tue, 08 Jun 2010 21:13:58 -0600	[thread overview]
Message-ID: <1276053238.3079.51.camel@x201> (raw)
In-Reply-To: <20100608214103.GT28492@x200.localdomain>

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.<device/driver>.<context>", 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

  reply	other threads:[~2010-06-09  3:14 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 19:14 [Qemu-devel] [RFC PATCH 0/6] RAM migration overhaul Alex Williamson
2010-06-08 19:15 ` [Qemu-devel] [RFC PATCH 1/6] qemu_ram_alloc: Remove duplicate code Alex Williamson
2010-06-08 21:00   ` [Qemu-devel] " Chris Wright
2010-06-08 19:15 ` [Qemu-devel] [RFC PATCH 2/6] ram_blocks: Convert to a QLIST Alex Williamson
2010-06-08 21:26   ` [Qemu-devel] " Chris Wright
2010-06-08 21:45     ` Alex Williamson
2010-06-08 21:51       ` Chris Wright
2010-06-09  8:19       ` Juan Quintela
2010-06-09 20:11   ` [Qemu-devel] " Cam Macdonell
2010-06-09 20:55     ` Alex Williamson
2010-06-09 21:12       ` Yoshiaki Tamura
2010-06-08 19:15 ` [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field Alex Williamson
2010-06-08 20:07   ` [Qemu-devel] " Anthony Liguori
2010-06-08 20:09     ` Alex Williamson
2010-06-08 21:41   ` Chris Wright
2010-06-09  3:13     ` Alex Williamson [this message]
2010-06-09 11:55     ` Avi Kivity
2010-06-09 12:56     ` Paul Brook
2010-06-09  2:30   ` [Qemu-devel] " Paul Brook
2010-06-09  2:40     ` Anthony Liguori
2010-06-09  2:54       ` Paul Brook
2010-06-09  4:19         ` Alex Williamson
2010-06-09 12:18           ` Paul Brook
2010-06-09 16:37             ` Alex Williamson
2010-06-09 20:36               ` Paul Brook
2010-06-10  8:23                 ` Gerd Hoffmann
2010-06-10 14:33                   ` Alex Williamson
2010-06-10 14:49                     ` Paul Brook
2010-06-10 15:21                       ` Alex Williamson
2010-06-11  8:48                         ` Gerd Hoffmann
2010-06-11 15:50                           ` Alex Williamson
2010-06-11 16:12                             ` Paul Brook
2010-06-11  8:45                     ` Gerd Hoffmann
2010-06-10 15:05                 ` Alex Williamson
2010-06-10 16:40               ` Chris Wright
2010-06-10 16:45                 ` Paul Brook
2010-06-09 11:58         ` Avi Kivity
2010-06-09 13:57           ` Anthony Liguori
2010-06-09 14:09             ` Paul Brook
2010-06-09  7:28       ` Gerd Hoffmann
2010-06-08 19:16 ` [Qemu-devel] [RFC PATCH 4/6] Remove uses of ram.last_offset (aka last_ram_offset) Alex Williamson
2010-06-08 19:16 ` [Qemu-devel] [RFC PATCH 5/6] savevm: Migrate RAM based on name/offset Alex Williamson
2010-06-08 20:12   ` [Qemu-devel] " Anthony Liguori
2010-06-08 21:12     ` Alex Williamson
2010-06-08 20:54   ` Chris Wright
2010-06-08 21:22     ` Alex Williamson
2010-06-08 19:16 ` [Qemu-devel] [RFC PATCH 6/6] savevm: Use RAM blocks for basis of migration Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1276053238.3079.51.camel@x201 \
    --to=alex.williamson@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).