> 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 Device
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 doname>.instance>\.
> >>> It seems like this highlights a deficiency in the vmstate matching
> >>
> >> Why are you
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 doname>.instance>\.
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 to send an identifier.
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] numer
> > > 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,
* 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, bu
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
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 t
> 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 reme
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 whet
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 -
> > 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
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
> 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 representati
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
> > > 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 s
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 *pde
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)
+ snp
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
> 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)
> >> +snprin
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), "pc
> 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",
> + PCI_SLOT(pdev-
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
---
cpu-all.h |1 +
cpu-common.h |4 ++-
23 matches
Mail list logo
