qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call agenda for 2012-11-12


From: Eduardo Habkost
Subject: Re: [Qemu-devel] KVM call agenda for 2012-11-12
Date: Tue, 13 Nov 2012 13:17:20 -0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Nov 13, 2012 at 03:29:37PM +0100, Andreas Färber wrote:
> Am 13.11.2012 13:29, schrieb Eduardo Habkost:
> > On Mon, Nov 12, 2012 at 01:58:38PM +0100, Juan Quintela wrote:
> >>
> >> Please send in any agenda topics you are interested in.
> > 
> > - Clarify 1.3 plans for CPU:
> 
> From my submaintainer POV:
> 
> > DeviceState CPU,
> 
> I was specifically tasked with the qdev split by Anthony, so unless
> major obstacles arise I will send a PULL until Thursday.
> 
> What I am still unsure about is whether it makes sense to actually apply
> the final CPU-as-device change for v1.3 since that exposes the device
> name(s) as public "ABI", cf. below. A safety option would be no_user = 1
> to avoid users messing with untested use cases at this time.

I'm OK with holding the final TYPE_DEVICE patch, while including only
the other changes. Our main problem is coordinating/rebasing work on
those large patch series, so at least including the qdev split and
header fixes would already make our lives easier.


> 
> > x86 CPU classes,
> 
> If I get through review quickly enough and RFC seems sane and I get a
> PATCH, I might include it in the pull. To me, classes are prerequisites
> to exposing CPU-as-a-device because otherwise the user specifies the
> base class that we want to make abstract (which will then break
> backwards compatibility) and has no API to set it to something useful.
> Once applied, we would still have half a month for testing.

We still have some ongoing discussion about the CPU class namespace, and
how to map the name from "-cpu FOO" to the actual class name, so I don't
think we want to hurry to get the RFC in 1.3. I will try to rewrite it
in a way that allows all targets to use the same code to find the
appropriate CPU class.

Maybe we could just try to include just the cpu_x86_init() cleanups I
sent yesterday, to make further work easier to coordinate?

(It's not that important to get that in 1.3, anyway, we can just agree
to use that series as base for futher work, even if it doesn't get
included right now)

> 
> > x86 CPU properties
> 
> Won't make v1.3 due to timing constraints. There are also still
> unresolved review comments related to property naming IIRC.

OK. It still has to be rebased, so I didn't think it was feasible for
1.3.

> 
> >   (we still want to get any of this included, or all will have to wait for 
> > 1.4?)
> 
> Regards,
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
> 

-- 
Eduardo



reply via email to

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