Am 02.03.2015 um 17:43 schrieb Michael Mueller:
> On Mon, 02 Mar 2015 14:57:21 +0100
> Andreas Färber <afaer...@suse.de> wrote:
>
>>> int configure_accelerator(MachineState *ms)
>>> {
>>> - const char *p;
>>> + const char *p, *name;
>>> char buf[10];
>>> int ret;
>>> bool accel_initialised = false;
>>> bool init_failed = false;
>>> AccelClass *acc = NULL;
>>> + ObjectClass *oc;
>>> + bool probe_mode = false;
>>>
>>> p = qemu_opt_get(qemu_get_machine_opts(), "accel");
>>> if (p == NULL) {
>>> - /* Use the default "accelerator", tcg */
>>> - p = "tcg";
>>> + oc = (ObjectClass *) MACHINE_GET_CLASS(current_machine);
>>> + name = object_class_get_name(oc);
>>> + probe_mode = !strcmp(name, "none" TYPE_MACHINE_SUFFIX);
>>> + if (probe_mode) {
>>> + /* Use these accelerators in probe mode, tcg should be last */
>>> + p = probe_mode_accels;
>>> + } else {
>>> + /* Use the default "accelerator", tcg */
>>> + p = "tcg";
>>> + }
>>> }
>>
>> Can't we instead use an explicit ,accel=probe or ,accel=auto?
>> That would then obsolete the next patch.
>
> How would you express the following with the accel=<pseudo-accel> approach?
>
> -probe -machine s390-ccw,accel=kvm
>
> Using machine "none" as default with tcg as last accelerator initialized
> should not break
> anything.
>
> -M none
Let me ask differently: What does -machine none or -M none have to do
with probing? It reads as if you are introducing two probe modes. Why do
you need both? If we have -probe, isn't that independent of which
machine we specify? Who is going to call either, with which respective goal?
I think that changing the semantics of an absent ,accel=foo parameter to
mean something else than its longtime default of tcg is a bad idea.
Have you testing qtest with it? Doesn't -qtest imply accel=qtest or is
that always passed explicitly?
Regards,
Andreas
--
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 kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
