qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/5] spapr: drop DIV_ROUND_UP() from xics_max_se


From: Greg Kurz
Subject: Re: [Qemu-devel] [PATCH 5/5] spapr: drop DIV_ROUND_UP() from xics_max_server_number()
Date: Thu, 15 Feb 2018 18:09:32 +0100

On Thu, 15 Feb 2018 16:54:18 +0000
Daniel P. Berrangé <address@hidden> wrote:

> On Thu, Feb 15, 2018 at 05:08:57PM +0100, Greg Kurz wrote:
> > On Thu, 15 Feb 2018 15:08:18 +1100
> > David Gibson <address@hidden> wrote:
> >   
> > > On Wed, Feb 14, 2018 at 08:41:03PM +0100, Greg Kurz wrote:  
> > 
> > <snip>
> >   
> > > > 
> > > > It breaks migration of pre-2.7 machine types with unusual CPU 
> > > > topologies,
> > > > but I guess this is an acceptable trade-off.    
> > > 
> > > No, not really.  Weird topologies are still allowed on old machine
> > > types for backwards compatibility, and we shouldn't break that.  I
> > > like the idea of consolidating this calculation, but we can't do it by
> > > just breaking the older machines (at least not until they're formally
> > > deprecated).
> > >   
> > 
> > Heh, I had put this patch at the end because I was expecting you might
> > nack it :)
> > 
> > Per curiosity, when/how do we decide that an older machine type may be
> > formally deprecated ?  
> 
> For versioned machine types we decided that we'd keep them around upstream
> for as long as they were needed by a downstream vendor, *provided* that
> downstream vendor is contributing to QEMU in order to mitigate the maint
> burden it would entail. 
> 

Indeed I now remember having heard something like that in the past. Thanks
for the details anyway. :)

And, this is probably a dumb question, but do we have an up-to-date list
of QEMU versions still needed by a contributing vendor ?

> Regards,
> Daniel




reply via email to

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