qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel.a@redhat.com>
To: Greg Bellows <greg.bellows@linaro.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Fabian Aggeler" <aggelerf@ethz.ch>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Sergey Fedorov" <serge.fdrv@gmail.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 04/13] target-arm: Add secure qemu machine option
Date: Sat, 06 Dec 2014 00:44:45 +0200	[thread overview]
Message-ID: <1417819485.1456.35.camel@localhost.localdomain> (raw)
In-Reply-To: <CAOgzsHWpGXPfrzSRw1b_p_BXWSMhLc6Mu-R8wOFA=NTMv358mQ@mail.gmail.com>

On Fri, 2014-12-05 at 14:40 -0600, Greg Bellows wrote:
> Thanks Marcel.
> 
> 
> Just to make sure I understand, at this point do to limitations in the
> existing functionality, there is nothing that can be done other than
> adding the option to the global qemu_machine_opts list.  Once you add
> a fix then it will be possible to add it dynamically.

Yes, this is correct.

What we have now is a way to determine if an option belongs to a specific machine,
for example trying to use your "secure" option with a PC machine will fail
since PC machines do not have this property.

But you still need to define that option in the global qemu_machine_opts
in order to use it. This is of course not good enough and we will take care of it.

We have two options here:
1. You add the "secure" option to the machines opts and I'll remove it once
   I'll fix the above limitation.
2. You wait until I fix this and you'll not need it at all.

I am OK with it other way, but the decision is not only mine :)
I'll try to come up with something next week, but it will need reviews
and it may postpone your series. However I suppose the series is for 2.3,
so we have plenty of time to do it properly.

Thanks,
Marcel 

> 
> 
> If I missed anything please let me know.
> 
> 
> Regards,
> 
> 
> Greg
> 
> On 5 December 2014 at 13:40, Marcel Apfelbaum <marcel.a@redhat.com>
> wrote:
>         On Fri, 2014-12-05 at 15:39 +0000, Peter Maydell wrote:
>         > On 5 December 2014 at 15:33, Greg Bellows
>         <greg.bellows@linaro.org> wrote:
>         > >
>         > >
>         > > On 5 December 2014 at 09:18, Peter Maydell
>         <peter.maydell@linaro.org> wrote:
>         > >>
>         > >> On 3 December 2014 at 20:05, Greg Bellows
>         <greg.bellows@linaro.org> wrote:
>         > >> > Added 'secure' qemu boolean option to
>         qemu_machine_opts[].
>         > >> >
>         > >> > Signed-off-by: Greg Bellows <greg.bellows@linaro.org>
>         > >> > ---
>         > >> >  vl.c | 4 ++++
>         > >> >  1 file changed, 4 insertions(+)
>         > >> >
>         > >> > diff --git a/vl.c b/vl.c
>         > >> > index eb89d62..5d640f7 100644
>         > >> > --- a/vl.c
>         > >> > +++ b/vl.c
>         > >> > @@ -387,6 +387,10 @@ static QemuOptsList
>         qemu_machine_opts = {
>         > >> >              .name = "iommu",
>         > >> >              .type = QEMU_OPT_BOOL,
>         > >> >              .help = "Set on/off to enable/disable
>         Intel IOMMU (VT-d)",
>         > >> > +        },{
>         > >> > +            .name = "secure",
>         > >> > +            .type = QEMU_OPT_BOOL,
>         > >> > +            .help = "Set on/off to enable/disable
>         secure state",
>         > >> >          },
>         > >>
>         > >> If patch 5 adds 'secure' as a machine property for only
>         those
>         > >> boards where it makes sense, why do we need this global
>         switch?
>         > >>
>         > >
>         > > That is what I thought as well, but this is apparently
>         needed as we get an
>         > > invalid machine property otherwise.  Below is the error,
>         I'll look again,
>         > > but it appeared all machine properties were defined here.
>         > >
>         > > qemu-system-aarch64: -machine
>         type=vexpress-a15,secure=off: Invalid
>         > > parameter 'secure'
>         >
>         > That would seem to defeat the point of the machine opts
>         design,
>         > so it looks a bit strange. Marcel: how is this supposed to
>         work
>         > for board-specific -machine options?
>         
>         Hi Peter,
>         
>         We have indeed properties per machine type and it works like
>         this:
>         1. You add a QOM property in the specific machine init code.
>            (Exactly as in [PATCH 05/13] target-arm: Add vexpress
>         machine secure property)
>         
>         2. In vl.c the following code should automatically fill in the
>         per machine properties.
>         
>            machine_opts = qemu_get_machine_opts();
>            if (qemu_opt_foreach(machine_opts, machine_set_property,
>         current_machine,
>                                  1) < 0) {
>                 object_unref(OBJECT(current_machine));
>                 exit(1);
>            }
>         
>         3. machine_set_property should handle the "per machine"
>         properties.
>         
>         That being said, we do have a problem in the way the
>         machine_opts are built.
>         In order for the property to be "visible", we need to add it
>         to a global
>         qemu_machine_opts list.
>         The reason (I think) is the parsing code that checks it
>         against a predefined list:
>         
>         The correct way to to this is to build the machine option list
>         dynamically
>         and not from the predefined global list and check them against
>         the
>         specific machine instance.
>         Andreas, does it seems right to you?
>         
>         Thanks for bringing this to my attention!
>         I'll fix this and submit a patch shortly.
>         
>         Thanks,
>         Marcel
>         
>         
>         
>         
>         >
>         > thanks
>         > -- PMM
>         
>         
>         
> 
> 

  reply	other threads:[~2014-12-05 22:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03 20:05 [Qemu-devel] [PATCH 00/13] target-arm: Add CPU security extension enablement Greg Bellows
2014-12-03 20:05 ` [Qemu-devel] [PATCH 01/13] target-arm: Add vexpress class and machine types Greg Bellows
2014-12-05 15:16   ` Peter Maydell
2014-12-05 19:02     ` Marcel Apfelbaum
2014-12-05 20:04       ` Greg Bellows
2014-12-03 20:05 ` [Qemu-devel] [PATCH 02/13] target-arm: Add vexpress a9 & a15 machine objects Greg Bellows
2014-12-03 20:05 ` [Qemu-devel] [PATCH 03/13] target-arm: Switch to common vexpress machine init Greg Bellows
2014-12-03 20:05 ` [Qemu-devel] [PATCH 04/13] target-arm: Add secure qemu machine option Greg Bellows
2014-12-05 15:18   ` Peter Maydell
2014-12-05 15:33     ` Greg Bellows
2014-12-05 15:39       ` Peter Maydell
2014-12-05 19:40         ` Marcel Apfelbaum
2014-12-05 20:40           ` Greg Bellows
2014-12-05 22:44             ` Marcel Apfelbaum [this message]
2014-12-05 22:53               ` Greg Bellows
2014-12-03 20:05 ` [Qemu-devel] [PATCH 05/13] target-arm: Add vexpress machine secure property Greg Bellows
2014-12-05 15:20   ` Peter Maydell
2014-12-03 20:06 ` [Qemu-devel] [PATCH 06/13] target-arm: Change vexpress daughterboard init arg Greg Bellows
2014-12-03 20:06 ` [Qemu-devel] [PATCH 07/13] target-arm: Add virt class and machine types Greg Bellows
2014-12-03 20:06 ` [Qemu-devel] [PATCH 08/13] target-arm: Add virt machine secure property Greg Bellows
2014-12-03 20:06 ` [Qemu-devel] [PATCH 09/13] target-arm: Add feature unset function Greg Bellows
2014-12-05 15:22   ` Peter Maydell
2014-12-03 20:06 ` [Qemu-devel] [PATCH 10/13] target-arm: Add ARMCPU secure property Greg Bellows
2014-12-05 15:26   ` Peter Maydell
2014-12-05 19:41     ` Greg Bellows
2014-12-03 20:06 ` [Qemu-devel] [PATCH 11/13] target-arm: Set CPU secure prop during VE init Greg Bellows
2014-12-03 20:06 ` [Qemu-devel] [PATCH 12/13] target-arm: Set CPU secure prop during virt init Greg Bellows
2014-12-03 20:06 ` [Qemu-devel] [PATCH 13/13] target-arm: add cpu feature EL3 to CPUs with Security Extensions Greg Bellows

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=1417819485.1456.35.camel@localhost.localdomain \
    --to=marcel.a@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aggelerf@ethz.ch \
    --cc=edgar.iglesias@gmail.com \
    --cc=greg.bellows@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=serge.fdrv@gmail.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).