[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH 5/5] spapr: drop DIV_ROUND_UP() from
Re: [Qemu-ppc] [Qemu-devel] [PATCH 5/5] spapr: drop DIV_ROUND_UP() from xics_max_server_number()
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 ?
- Re: [Qemu-ppc] [PATCH 1/5] spapr: use spapr->vsmt to compute VCPU ids, (continued)