qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv2] Fix virtio-serial migration on bi-endian targ


From: Amit Shah
Subject: Re: [Qemu-devel] [PATCHv2] Fix virtio-serial migration on bi-endian targets
Date: Tue, 16 Dec 2014 11:37:23 +0530

On (Tue) 16 Dec 2014 [16:38:15], David Gibson wrote:
> On Tue, Dec 16, 2014 at 10:08:49AM +0530, Amit Shah wrote:
> > On (Tue) 16 Dec 2014 [15:33:54], David Gibson wrote:
> > > On Tue, Dec 16, 2014 at 09:43:30AM +0530, Amit Shah wrote:

> > > > Can you split this patch so the config change and the max_nr_ports
> > > > change are separate?  The max_nr_ports could similarly be ignored by
> > > > dest, right?
> > > 
> > > Um.. I'm not exactly sure where you're drawing the distinction between
> > > the two parts.  Are you thinking
> > >     patch 1) make config.max_nr_ports unused, by using
> > >              max_virtserial_ports instead
> > >     patch 2) eliminate the config field entirely
> > 
> > For this patch, I'm just suggesting to only touch cols and rows, and
> > lines that touch the max_nr_ports can be put in 2/2.  Eliminating
> > config entirely may not be desirable, but if you want to do that, and
> > mark all fields as 'unused' in the savevm/loadvm functions, go for
> > it :-)
> 
> That division really doesn't make sense to me.  If rows and cols are
> removed, but max_nr_ports stays, then get_config has to become a
> weird hybrid where it copies some stuff directly from ->config and
> other bits from elsewhere.
> 
> I really don't see any reason keeping config would be a desirable
> thing: it's a cache of information that doesn't need to be cached, and
> just adds complexity because of the endian issues.

Oh please go ahead and do it -- my only point here is to split the
patchset into logical units, not wrt the total intent of the series.

                Amit



reply via email to

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