qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-arm] [PATCH 0/4] cpu: Implement cpu_generic_new()


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH 0/4] cpu: Implement cpu_generic_new()
Date: Tue, 21 Feb 2017 12:58:56 -0300
User-agent: Mutt/1.7.1 (2016-10-04)

On Thu, Feb 16, 2017 at 04:40:43PM +0000, Peter Maydell wrote:
> On 13 February 2017 at 14:28, Peter Maydell <address@hidden> wrote:
> > This patchset adds a new function cpu_generic_new()
> > which is similar to cpu_generic_init() except that it
> > does not realize the created CPU object. This means that
> > board code can do a "new cpu; set QOM properties; realize"
> > sequence without having to do all the work of splitting
> > the CPU model string and calling parse_features by hand.
> >
> > Patch 2 clarifies a TODO comment, hopefully correctly,
> > based on an email conversation I had with Eduardo a
> > little while back.
> >
> > Patches 3 and 4 change the ARM boards which currently
> > call parse_features by hand to use the new function.
> >
> >
> > If there's consensus that this is the right general
> > direction to go in, then I think that some other
> > architectures could also make cleanups to use this:
> >  * cpu_s390x_create() is almost exactly this function,
> >    give or take some fine detail of error handling
> >  * ppc_cpu_parse_features is almost the same thing,
> >    except that it doesn't actually create the CPU object,
> >    it only calls parse_features
> >  * hw/i386/pc.c does a manual parse_features
> >
> > I'm not strongly attached to this particular approach
> > (though it seems like a reasonable one, especially given
> > the proliferation of different arch-specific helpers
> > listed above and the bugs in boards which don't call
> > parse_features when they should), but I would like us to
> > figure out and document what the right way for a board
> > to create and configure its CPU objects is...
> 
> I know it's only been a few days, but I just wanted to
> say that I'd appreciate it if we could manage relatively
> quick review on this one, since I have a set of patches
> pending that depend on this and which it would be nice
> to get into 2.9 (softfreeze approaching rapidly).

I was away from work for the past 3 weeks and I am catching up on
e-mail, right now. Is this proposal still up, or is this series
obsoleted by something else?

-- 
Eduardo



reply via email to

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