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