On Mon, Jun 08, 2015 at 09:32:53AM -0400, Gabriel L. Somlo wrote:
> On Mon, Jun 08, 2015 at 02:33:45PM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > I'm wonderingjust when exactly to start sorting items in fw_cfg ?
> >
> > I'd suggest to sort as entries are added, i.e. just insert the new entry
On Mon, Jun 08, 2015 at 02:33:45PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > I'm wonderingjust when exactly to start sorting items in fw_cfg ?
>
> I'd suggest to sort as entries are added, i.e. just insert the new entry
> at the correct place instead of tacking it to the end. So the list is
> al
Hi,
> I'm wonderingjust when exactly to start sorting items in fw_cfg ?
I'd suggest to sort as entries are added, i.e. just insert the new entry
at the correct place instead of tacking it to the end. So the list is
always sorted.
> I'm also assuming this applies to named (file) entries only,
On 08/06/2015 14:23, Gabriel L. Somlo wrote:
> I'm wonderingjust when exactly to start sorting items in fw_cfg ?
>
> Different machine types insert different blobs at various points
> during their initialization (and possibly on-demand during hot-plug
> events, I'm not 100% sure).
Hotplug may
On Mon, Jun 08, 2015 at 01:44:18PM +0200, Paolo Bonzini wrote:
>
>
> On 08/06/2015 13:19, Gerd Hoffmann wrote:
> >>> I would simply sort everything (and do it for new machine types only,
> >
> >>> for backward compatibility
On 08/06/2015 13:19, Gerd Hoffmann wrote:
>>> I would simply sort everything (and do it for new machine types only,
>
>>> for backward compatibility reasons). Sorting user-provided blobs only
>>> adds complexity for no reas
> > I would simply sort everything (and do it for new machine types only,
> > for backward compatibility reasons). Sorting user-provided blobs only
> > adds complexity for no reason.
> Do we want this for all machine types,
On Mon, Jun 08, 2015 at 09:21:45AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > So, sorting entries (and the index assigned too) should fix this, right?
> > > That looks easiest to me.
> >
> > Presumably, anything happening before (and after) user-provided blobs
> > are inserted will continue happ
Hi,
> > So, sorting entries (and the index assigned too) should fix this, right?
> > That looks easiest to me.
>
> Presumably, anything happening before (and after) user-provided blobs
> are inserted will continue happening in the same order everywhere.
Which might change in the future though,
On Tue, Jun 02, 2015 at 09:11:14AM +0200, Gerd Hoffmann wrote:
> > I guess the only reason this isn't a problem is that nobody currently
> > attempts to access fw_cfg after a migration ? :)
>
> Accessing fw_cfg after migration is fine. Problem is this ...
>
> (1) read directory
> (2) migrate
On Tue, Jun 02, 2015 at 09:11:14AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > I guess the only reason this isn't a problem is that nobody currently
> > attempts to access fw_cfg after a migration ? :)
>
> Accessing fw_cfg after migration is fine. Problem is this ...
>
> (1) read directory
>
On 02/06/2015 09:11, Gerd Hoffmann wrote:
> Accessing fw_cfg after migration is fine. Problem is this ...
>
> (1) read directory
> (2) migrate
> (3) read file
>
> ... in case the file ordering happens to be different on the destination
> host due to initialization order changes.
>
> So,
Hi,
> I guess the only reason this isn't a problem is that nobody currently
> attempts to access fw_cfg after a migration ? :)
Accessing fw_cfg after migration is fine. Problem is this ...
(1) read directory
(2) migrate
(3) read file
... in case the file ordering happens to be differen
(resending, with Paolo's address corrected)
On 06/01/15 22:31, Gabriel L. Somlo wrote:
> On Mon, Jun 01, 2015 at 02:00:22PM -0400, Gabriel L. Somlo wrote:
>> On Mon, Jun 01, 2015 at 05:44:47PM +0200, Michael S. Tsirkin wrote:
> Shouldn't we migrate the fw cfg data that the source host generate
On Mon, Jun 01, 2015 at 02:00:22PM -0400, Gabriel L. Somlo wrote:
> On Mon, Jun 01, 2015 at 05:44:47PM +0200, Michael S. Tsirkin wrote:
> > > > Shouldn't we migrate the fw cfg data that the source host generates
> > > > originally, rather than trying to play games make sure the way it
> > > > is r
On Mon, Jun 01, 2015 at 05:44:47PM +0200, Michael S. Tsirkin wrote:
> > > Shouldn't we migrate the fw cfg data that the source host generates
> > > originally, rather than trying to play games make sure the way it
> > > is re-generated on dest doesn't change.
> >
> > Right now, in hw/nvram/fw_cfg
On Mon, Jun 01, 2015 at 11:32:37AM -0400, Gabriel L. Somlo wrote:
> On Mon, Jun 01, 2015 at 03:13:43PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jun 01, 2015 at 04:10:54PM +0200, Michael S. Tsirkin wrote:
> > > Hi all,
> > > At the moment we have devices adding and removing fw cfg file entries.
On Mon, Jun 01, 2015 at 03:13:43PM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 01, 2015 at 04:10:54PM +0200, Michael S. Tsirkin wrote:
> > Hi all,
> > At the moment we have devices adding and removing fw cfg file entries.
> > One problem is that this makes the contents of fw cfg
> > depend on or
On Mon, Jun 01, 2015 at 04:10:54PM +0200, Michael S. Tsirkin wrote:
> Hi all,
> At the moment we have devices adding and removing fw cfg file entries.
> One problem is that this makes the contents of fw cfg
> depend on order of device initialization.
> Since the fw cfg file list is not migrated, th
19 matches
Mail list logo
