[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150220175321.63fc8e3a@bee>
Date: Fri, 20 Feb 2015 17:53:21 +0100
From: Michael Mueller <mimu@...ux.vnet.ibm.com>
To: Andreas Färber <afaerber@...e.de>
Cc: Alexander Graf <agraf@...e.de>, qemu-devel@...gnu.org,
kvm@...r.kernel.org, linux-s390@...r.kernel.org,
linux-kernel@...r.kernel.org, Gleb Natapov <gleb@...nel.org>,
Christian Borntraeger <borntraeger@...ibm.com>,
"Jason J. Herne" <jjherne@...ux.vnet.ibm.com>,
Cornelia Huck <cornelia.huck@...ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Richard Henderson <rth@...ddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH v2 13/15] cpu-model/s390: Add processor
property routines
On Fri, 20 Feb 2015 17:28:14 +0100
Andreas Färber <afaerber@...e.de> wrote:
Andreas,
> Sorry for my ignorance, but what is proc actually needed for? For
> initializing the class, there's .class_init (and cc->fac_list apparently
> is initialized here). If you need to pass info to KVM, you can do so in
yes, it is communication to the accelerator to prepare its local cpu model related data
structures which are used to initialize a vcpu (e.g. the facility list beside others)
> DeviceClass::realize when the vCPU actually goes "live". A
I will look what "goes live" in detail means here, it should at least be before
kvm_arch_vcpu_setup() gets triggered on accelerator side.
> string-to-string (or string-to-ObjectClass) translation function seems
> like a weird point in time to take action with global effect.
>
> Anyway, please implement the generic callback, then you can still call
> it from your own helper functions if needed.
Thanks a lot!
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists