Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts

[Christian Borntraeger]

Am 04.02.2015 um 22:35 schrieb Marcel Apfelbaum:
[...]
>> Would a function there that does  gets 
>> S390_CCW_MACHINE(current_machine)->aes_key_wrap
>> considered ok, or do we need to pollute hw/core/machine.c with architecture 
>> specific
>> options?
> We surely don't add this to hw/core/machine.c because is specific to 
> TYPE_S390_CCW_MACHINE.
> 
> Let's say you want to use this property in kvm_arch_init of 
> target-s390x/kvm.c.
>  - After this series you already have an instance of MachineState initialized 
> with your new properties.
>  - My assumption is that TYPE_S390_CCW_MACHINE is the only s390 machine or 
> the base type of all s390 machines.
> You have three options here:
>  1. Use QOM infrastucture:
>     bool aes_key_wrap = object_property_get_bool(OBJECT(machine), 
> "aes-key-wrap", NULL);
>  2. Add a wrapper somewhere in  include/hw/s390x/
>     that gets MachineState, cast it into S390State and return the field value.
>  3. Directly downcast MachineState to S390State and get the value.
> * All of the above use my assumption that all s390 machines derive from this 
> one.

Yes, we derive CCW_MACHINE from the base machine type. Thanks

> 
>>
>> Christian
>>
>> PS: The same is somewhat true for qemu-options.hx. Having such specific 
>> machine option
>> in the global help offers room for improvement
> Can you please elaborate? I didn't fully understand what exactly are you 
> referring to.

lets take for example vmport. This is only relevant for x86, but it seems that 
there
is nothing like QEMU_ARCH_ALL  QEMU_ARCH_ARM | QEMU_ARCH_M68K | 
QEMU_ARCH_XTENSA | QEMU_ARCH_LM32
for machine properties. Now that we actually move this into the backends, we 
could do it
here as well. 
 
> Hope I helped,
> Marcel

Absolutely