Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-11 Thread Gerd Hoffmann
On 06/10/10 16:33, Alex Williamson wrote: On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote: I may have been a bit misleading here. What we really want to do is use the same matching algorithm as is used by the rest of the device state. Currently this is a vmstate name and [arbitrary]

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-11 Thread Gerd Hoffmann
On 06/10/10 17:21, Alex Williamson wrote: On Thu, 2010-06-10 at 15:49 +0100, Paul Brook wrote: Ok, we can certainly dovmsd-name.vmsd-instance\driver string. It seems like this highlights a deficiency in the vmstate matching Why are you forcing this to be a string? It seemed like a good way

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-11 Thread Alex Williamson
On Fri, 2010-06-11 at 10:48 +0200, Gerd Hoffmann wrote: On 06/10/10 17:21, Alex Williamson wrote: On Thu, 2010-06-10 at 15:49 +0100, Paul Brook wrote: Ok, we can certainly dovmsd-name.vmsd-instance\driver string. It seems like this highlights a deficiency in the vmstate matching Why are

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-11 Thread Paul Brook
The trouble I'm running into is that the SaveStateEntry.instance_id is effectively private, and there's no easy way to associate a SaveStateEntry to a device since it passes an opaque pointer, which could be whatever the driver decides it wants. I'm wondering if we should pass the

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-10 Thread Gerd Hoffmann
I may have been a bit misleading here. What we really want to do is use the same matching algorithm as is used by the rest of the device state. Currently this is a vmstate name and [arbitrary] numeric id. I don't remember whether there's a convenient link from a device to its associated vmstate -

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-10 Thread Alex Williamson
On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote: I may have been a bit misleading here. What we really want to do is use the same matching algorithm as is used by the rest of the device state. Currently this is a vmstate name and [arbitrary] numeric id. I don't remember whether

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-10 Thread Paul Brook
On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote: I may have been a bit misleading here. What we really want to do is use the same matching algorithm as is used by the rest of the device state. Currently this is a vmstate name and [arbitrary] numeric id. I don't remember whether

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-10 Thread Alex Williamson
On Wed, 2010-06-09 at 21:36 +0100, Paul Brook wrote: Not really. This identifier is device and bus independent, which is why I suggested passing the device to qemu_ram_alloc. This can then figure out how to the identify the device. It should probably do this the same way that we

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-10 Thread Alex Williamson
On Thu, 2010-06-10 at 15:49 +0100, Paul Brook wrote: On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote: I may have been a bit misleading here. What we really want to do is use the same matching algorithm as is used by the rest of the device state. Currently this is a vmstate

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-10 Thread Chris Wright
* Alex Williamson (alex.william...@redhat.com) wrote: On Wed, 2010-06-09 at 13:18 +0100, Paul Brook wrote: to the identify the device. It should probably do this the same way that we identify the saved state for the device. Currently I think this is an arbitrary vmstate name/id, but I

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-10 Thread Paul Brook
to the identify the device. It should probably do this the same way that we identify the saved state for the device. Currently I think this is an arbitrary vmstate name/id, but I expect this to change to a qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0). Ok, that seems

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-09 Thread Gerd Hoffmann
On 06/09/10 04:40, Anthony Liguori wrote: On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) +

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-09 Thread Avi Kivity
On 06/09/2010 05:54 AM, Paul Brook wrote: On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-09 Thread Paul Brook
Not all ram is associated with a device. Maybe not, but where it is we should be using that information. Absolute minimum we should be using the existing qdev address rather than inventing a new one. Duplicating this logic inside every device seems like a bad idea so I suggest

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-09 Thread Anthony Liguori
On 06/09/2010 06:58 AM, Avi Kivity wrote: On 06/09/2010 05:54 AM, Paul Brook wrote: On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-09 Thread Paul Brook
Keep in mind, this has to be a stable string across versions of qemu since this is savevm/migration. Are we absolutely confident that the full qdev path isn't going to change? I'm more confident that a unique device name is going to be static across qemu versions. The actual representation

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-09 Thread Alex Williamson
On Wed, 2010-06-09 at 13:18 +0100, Paul Brook wrote: Not all ram is associated with a device. Maybe not, but where it is we should be using that information. Absolute minimum we should be using the existing qdev address rather than inventing a new one. Duplicating this logic

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-09 Thread Paul Brook
Not really. This identifier is device and bus independent, which is why I suggested passing the device to qemu_ram_alloc. This can then figure out how to the identify the device. It should probably do this the same way that we identify the saved state for the device. Currently I think

[Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-08 Thread Alex Williamson
The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. Note, this only addresses the qemu-kvm callers so far. Signed-off-by: Alex Williamson alex.william...@redhat.com --- cpu-all.h |1 +

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-08 Thread Paul Brook
The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) +snprintf(name, sizeof(name), pci:%02x.%x.rom, +

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-08 Thread Anthony Liguori
On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) +snprintf(name, sizeof(name),

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-08 Thread Paul Brook
On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) +snprintf(name,

Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

2010-06-08 Thread Alex Williamson
On Wed, 2010-06-09 at 03:54 +0100, Paul Brook wrote: On 06/08/2010 09:30 PM, Paul Brook wrote: The offset given to a block created via qemu_ram_alloc/map() is arbitrary, let the caller specify a name so we can make a positive match. @@ -1924,7 +1925,9 @@ static int