linux-kernel - Re: [Qemu-devel] [RFC PATCH v2 13/15] cpu-model/s390: Add processor property routines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Feb 2015 17:28:14 +0100
From:	Andreas Färber <afaerber@...e.de>
To:	Michael Mueller <mimu@...ux.vnet.ibm.com>
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

Am 20.02.2015 um 17:04 schrieb Michael Mueller:
> On Fri, 20 Feb 2015 16:41:49 +0100
> Andreas Färber <afaerber@...e.de> wrote:
> 
>> Can't you just implement the class-level name-to-ObjectClass callback
>> that other CPUs have grown for the above use case?
> 
> If it fulfills the requirements sure. Please point me to an example,

Take a look at include/qom/cpu.h CPUClass::class_by_name and git-grep
the existing targets - most implement it already. It's a generic hook to
be used from everywhere rather than a local function specific to the
legacy init function. Apart from the error handling it should be
straight-forward.

> sounds that
> s390_select_cpu_model() is doing something similar to that, just that it hooks in
> the s390_set_processor_props() call.
> 
> const char *s390_select_cpu_model(const char *model)
> {
>     S390ProcessorProps proc;
>     const char *typename;
>     S390CPUClass *cc;
> 
>     /* return already selected cpu typename */
>     typename = s390_cpu_typename();
>     if (typename) {
>         goto out;
>     }
> 
>     /* return standard cpu typename when cpu models are unavailable */
>     typename = TYPE_S390_CPU;
>     if (!s390_cpu_classes_initialized() || !model) {
>         goto out;
>     }
>     cc = S390_CPU_CLASS(s390_cpu_class_by_name(model));
>     if (!cc) {
>         goto out;
>     }
>     proc.cpuid = cpuid(cc->proc);
>     proc.ibc = cc->proc->ibc;
>     memcpy(proc.fac_list, cc->fac_list, S390_ARCH_FAC_LIST_SIZE_BYTE);
>     if (s390_set_processor_props(&proc)) {
>         goto out;
>     }

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
DeviceClass::realize when the vCPU actually goes "live". A
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.

Regards,
Andreas

> 
>     /* return requested cpu typename in success case */
>     typename = object_class_get_name((ObjectClass *) cc);
> out:
>     selected_cpu_typename = typename;
>     trace_select_cpu_model(model, typename);
>     return typename;
> }

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
--
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/