[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 :-)
>