All of lore.kernel.org
 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 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.