[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather th
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts |
Date: |
Wed, 04 Feb 2015 23:10:51 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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
- [Qemu-devel] [PATCH 3/8] machine: query kernel-irqchip machine property rather than qemu opts, (continued)
- [Qemu-devel] [PATCH 3/8] machine: query kernel-irqchip machine property rather than qemu opts, Marcel Apfelbaum, 2015/02/04
- [Qemu-devel] [PATCH 6/8] machine: query phandle-start machine property rather than qemu opts, Marcel Apfelbaum, 2015/02/04
- [Qemu-devel] [PATCH 7/8] machine: query dump-guest-core machine property rather than qemu opts, Marcel Apfelbaum, 2015/02/04
- [Qemu-devel] [PATCH 5/8] machine: query kvm-shadow-mem machine property rather than qemu opts, Marcel Apfelbaum, 2015/02/04
- Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts, Paolo Bonzini, 2015/02/04
- [Qemu-devel] [PATCH 2/8] hw/machine: kernel-irqchip property support for allowed/required, Marcel Apfelbaum, 2015/02/04
- [Qemu-devel] [PATCH 4/8] kvm: add machine state to kvm_arch_init, Marcel Apfelbaum, 2015/02/04
- [Qemu-devel] [PATCH 8/8] machine: query mem-merge machine property rather than qemu opts, Marcel Apfelbaum, 2015/02/04
- Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts, Christian Borntraeger, 2015/02/04
- Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts, Marcel Apfelbaum, 2015/02/25