qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Williamson
Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
Date: Thu, 10 Jun 2010 09:05:38 -0600

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 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 fairly reasonable, so from a device pointer we can get
> > something like "/i440FX-pcihost/pci.0/_addr_04.0", then we can add
> > something like ":rom" or ":bar.0" to it via an extra string.
> > 
> > qemu_ram_alloc(DeviceState *dev, const char *info, size)
> 
> Exactly - though personally I wouldn't call the second argument "info".

Hmm, this gets a little hairy for patch 5/6 where we try to create a
block on the fly to match the migration source.  For now, this is mainly
to catch things like devices that are hot plugged then removed before
migration, but don't currently have a functional qemu_ram_free() to
clean up.  However, if we could get past that and clean up drivers, it
might be nice for the string to provide enough information to
instantiate the missing device on the target.  I suddenly see that
char[64] name becoming insufficient.  Maybe we should follow the vmstate
example and use a variable length string preceded by a length byte (or
two).

Alex






reply via email to

[Prev in Thread] Current Thread [Next in Thread]