qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
	Marcel Apfelbaum <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:35:05 +0200	[thread overview]
Message-ID: <54D29089.2050606@gmail.com> (raw)
In-Reply-To: <54D276F4.7050400@de.ibm.com>

On 02/04/2015 09:45 PM, Christian Borntraeger wrote:
> Am 04.02.2015 um 16:43 schrieb Marcel Apfelbaum:
>> Commit e79d5a6 ("machine: remove qemu_machine_opts global list") removed option
>> descriptions from the -machine QemuOptsList to avoid repeating MachineState's QOM properties.
>>
>> This results in a Qemu crash if a non string option is queried using qemu opts.
>> Fix this by querying machine properties through designated wrappers.
>>
>> I hope I didn't miss anything.
>> Comments are appreciated as always.
>>
>> Thanks,
>> Marcel
>>
>> Marcel Apfelbaum (8):
>>    machine: query iommu machine property rather than qemu opts
>>    hw/machine: kernel-irqchip property support for allowed/required
>>    machine: query kernel-irqchip machine property rather than qemu opts
>>    kvm: add machine state to kvm_arch_init
>>    machine: query kvm-shadow-mem machine property rather than qemu opts
>>    machine: query phandle-start machine property rather than qemu opts
>>    machine: query dump-guest-core machine property rather than qemu opts
>>    machine: query mem-merge machine property rather than qemu opts
>
> In general this seems to work.
Thanks!

> I have a question, though:
>
> What I like is a way to do some wrappers in the specific machines.
> For example, we plan to add
>
> static inline void s390_machine_initfn(Object *obj)
> {
>      object_property_add_bool(obj, "aes-key-wrap",
>                               machine_get_aes_key_wrap,
>                               machine_set_aes_key_wrap, NULL);
>      object_property_set_description(obj, "aes-key-wrap",
>              "enable/disable AES key wrapping using the CPACF wrapping key",
>              NULL);
>      object_property_add_bool(obj, "dea-key-wrap",
>                               machine_get_dea_key_wrap,
>                               machine_set_dea_key_wrap, NULL);
>      object_property_set_description(obj, "dea-key-wrap",
>              "enable/disable DEA key wrapping using the CPACF wrapping key",
>              NULL);
> }
OK, You add 2 QOM properties to TYPE_S390_CCW_MACHINE instances.
Of course your setters/getters need to save the property values into an actual field,
so you will need a S390State (derived from MachineState)

typedef struct {
   MachineState parent;

   bool   aes_key_wrap;
   ...

} S390State

>
>
>
> Previously we used
>   if (qemu_opt_get_bool(opts, "aes-key-wrap", false))
> if target-s390/kvm.c
> to query that.
>
> Now, these options are pretty specific to s390 and adding them to hw/core/machine.c
> to create wrappers seems strange.
Completely agree. This is the reason we wanted options(properties) per machine type.

  So implementing them in hw/s390/s390-virtio-ccw.c
> seems a much better place.
Indeed.

> 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.

>
> 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.

Hope I helped,
Marcel
>
>

  reply	other threads:[~2015-02-04 21:35 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 [this message]
2015-02-04 22:10     ` Christian Borntraeger
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=54D29089.2050606@gmail.com \
    --to=marcel.apfelbaum@gmail.com \
    --cc=agraf@suse.de \
    --cc=aurelien@aurel32.net \
    --cc=borntraeger@de.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).