qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v6 15/17] target-s390x: Extend arch specific QMP


From: Michael Mueller
Subject: Re: [Qemu-devel] [PATCH v6 15/17] target-s390x: Extend arch specific QMP command query-cpu-definitions
Date: Wed, 6 May 2015 18:27:03 +0200

On Wed, 6 May 2015 13:00:32 -0300
Eduardo Habkost <address@hidden> wrote:

> On Wed, May 06, 2015 at 05:31:06PM +0200, Michael Mueller wrote:
> > On Tue, 5 May 2015 15:40:34 -0300
> > Eduardo Habkost <address@hidden> wrote:
> [...]
> > > Second, you shouldn't even need to duplicate code in
> > > get_machine_props_fallback() if you are able to create an accel object
> > > and do just basic initialization so that cpu_model_get() works.
> > > Allowing accel objects to be created on the fly was one of the main
> > > purposes of the accel QOM work.
> > > 
> > > For example, if we do something like this:
> > >   
> > > https://github.com/ehabkost/qemu-hacks/commit/36a250e34c5fd0d43a25271f5bc9b04681fdd56a
> > >  [1]
> > >   https://github.com/ehabkost/qemu-hacks/commits/work/accel-open-func
> > 
> > I had a look at your qemu-hacks before writing the _fallback() routine
> > but did not wanted to base on some not yet published code. Once your part 
> > goes
> > upstream my intend is to provide a cleanup patch... And I was missing the
> > KVM_CREATE_VM actually.
> 
> No problem to me if you prefer to keep it this way and change it to use
> AccelState as a follow-up, after appropriate methods are provided by
> TYPE_KVM_ACCEL. Your patch was helpful to show that just extracting the
> open("/dev/kvm") part isn't enough and more work is needed.

promised :-)

> 




reply via email to

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