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]
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
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
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
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 -
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
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
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
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
* 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
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
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)
+
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
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
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
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
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
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
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 +
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,
+
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),
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,
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
23 matches
Mail list logo
