qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V2 4/4] hw/machine: qemu machine opts as propert


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH V2 4/4] hw/machine: qemu machine opts as properties to QemuMachineState
Date: Fri, 30 May 2014 16:25:07 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, May 26, 2014 at 03:40:58PM +0300, Marcel Apfelbaum wrote:
[...]
> +static void machine_initfn(Object *obj)
> +{
> +    object_property_add_str(obj, "accel",
> +                            machine_get_accel, machine_set_accel, NULL);
> +    object_property_add_bool(obj, "kernel_irqchip",
> +                             machine_get_kernel_irqchip,
> +                             machine_set_kernel_irqchip,
> +                             NULL);

In the case of kernel_irqchip, the information contained in MachineState
is not a superset of the information contained on
qemu_get_machine_opts().

See hw/ppc/{e500,spapr}.c. They use kernel_irqchip like this:

    bool irqchip_allowed = qemu_opt_get_bool(machine_opts,
                                            "kernel_irqchip", true);
    bool irqchip_required = qemu_opt_get_bool(machine_opts,
                                              "kernel_irqchip", false);

    if (irqchip_allowed) {
        dev = ppce500_init_mpic_kvm(params, irqs);
    }

    if (irqchip_required && !dev) {
        fprintf(stderr, "%s: irqchip requested but unavailable\n",
                __func__);
        abort();
    }

This means kernel_irqchip have three possible states: "disabled", "required",
and "allowed".

This means that MachineState.kernel_irqchip is not usable by current
code that uses the kernel_irqchip option. I suppose we plan to address
this on MachineState, too, to not get stuck with a global
qemu_get_machine_opts() forever?

-- 
Eduardo



reply via email to

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