From: Christian Borntraeger <borntraeger@de.ibm.com>
To: marcel@redhat.com, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com,
james.hogan@imgtec.com, mst@redhat.com, jan.kiszka@siemens.com,
agraf@suse.de, scottwood@freescale.com, cornelia.huck@de.ibm.com,
pbonzini@redhat.com, leon.alrae@imgtec.com, aurelien@aurel32.net
Subject: Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts
Date: Wed, 04 Feb 2015 23:10:51 +0100 [thread overview]
Message-ID: <54D298EB.80303@de.ibm.com> (raw)
In-Reply-To: <54D29089.2050606@gmail.com>
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
next prev parent reply other threads:[~2015-02-04 22:11 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-04 15:43 [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 1/8] machine: query iommu machine property " Marcel Apfelbaum
2015-02-04 16:47 ` Markus Armbruster
2015-02-04 19:30 ` Marcel Apfelbaum
2015-02-05 8:18 ` Markus Armbruster
2015-03-11 14:43 ` Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 2/8] hw/machine: kernel-irqchip property support for allowed/required Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 3/8] machine: query kernel-irqchip machine property rather than qemu opts Marcel Apfelbaum
2015-03-11 14:41 ` Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 4/8] kvm: add machine state to kvm_arch_init Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 5/8] machine: query kvm-shadow-mem machine property rather than qemu opts Marcel Apfelbaum
2015-03-11 14:37 ` Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 6/8] machine: query phandle-start " Marcel Apfelbaum
2015-03-11 14:32 ` Marcel Apfelbaum
2015-03-11 14:34 ` Marcel Apfelbaum
2015-03-11 14:39 ` Michael S. Tsirkin
2015-03-11 14:48 ` Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 7/8] machine: query dump-guest-core " Marcel Apfelbaum
2015-03-10 17:50 ` Andreas Färber
2015-03-10 21:24 ` Michael S. Tsirkin
2015-03-10 21:36 ` Andreas Färber
2015-03-11 7:34 ` Markus Armbruster
2015-03-11 8:45 ` Michael S. Tsirkin
2015-03-11 9:42 ` Marcel Apfelbaum
2015-03-11 8:56 ` Michael S. Tsirkin
2015-03-11 11:06 ` Andreas Färber
2015-03-11 13:04 ` Marcel Apfelbaum
2015-03-11 14:22 ` Michael S. Tsirkin
2015-03-11 15:08 ` Markus Armbruster
2015-03-11 9:44 ` Marcel Apfelbaum
2015-03-11 14:25 ` Marcel Apfelbaum
2015-02-04 15:43 ` [Qemu-devel] [PATCH 8/8] machine: query mem-merge " Marcel Apfelbaum
2015-03-10 15:11 ` Michael S. Tsirkin
2015-03-10 16:22 ` Marcel Apfelbaum
2015-02-04 16:00 ` [Qemu-devel] [PATCH 0/8] machine: query machine properties " Paolo Bonzini
2015-02-04 19:45 ` Christian Borntraeger
2015-02-04 21:35 ` Marcel Apfelbaum
2015-02-04 22:10 ` Christian Borntraeger [this message]
2015-02-25 11:55 ` Marcel Apfelbaum
2015-03-04 15:37 ` Marcel Apfelbaum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D298EB.80303@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=agraf@suse.de \
--cc=aurelien@aurel32.net \
--cc=cornelia.huck@de.ibm.com \
--cc=james.hogan@imgtec.com \
--cc=jan.kiszka@siemens.com \
--cc=leon.alrae@imgtec.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=scottwood@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.