Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.07.18 at 09:34, <xin.li@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Friday, June 29, 2018 6:05 PM
>> >>> On 29.06.18 at 11:47, <andrew.cooper3@xxxxxxxxxx> wrote:
>> > On 29/06/18 10:28, Xin Li wrote:
>> >> --- a/docs/misc/xen-command-line.markdown
>> >> +++ b/docs/misc/xen-command-line.markdown
>> >> @@ -865,6 +865,19 @@ hardware domain is architecture dependent.
>> >>  Note that specifying zero as domU value means zero, while for dom0
>> >> it means  to use the default.
>> >>
>> >> +### xsm
>> >> +> `= dummy | silo | flask`
>> >
>> > This should be just "dummy | flask" in this patch, and extended with
>> > silo in the next path.  Also, options in this file should be sorted
>> > alphabetically, so ### xsm should be near the end, rather than beside 
>> > flask.
>> >
>> >> +
>> >> +> Default: `dummy`
>> >> +
>> >> +Specify which XSM module should be enabled.  This option is only
>> >> +available if the hypervisor was compiled with XSM support.
>> >> +
>> >> +* `dummy`: this is the default choice.  No special restriction will be 
>> >> applied.
>> >> +  it's also used when XSM is compiled out.
>> >> +enum xsm_bootparam __read_mostly xsm_bootparam =
>> >> +XSM_BOOTPARAM_DUMMY;
>> 
>> So why "dummy" instead of "none" (or one of the boolean false strings)?
> 
> It seems dummy is not fully stub. (some check by XSM_* classification)
> So we want to keep this "dummy" check, and override it.

Right, except that "dummy", while a reasonable name internally to the
implementation, is at least of questionable use/meaning as a part of a
command line option.

>> >> @@ -57,7 +81,20 @@ static int __init xsm_core_init(const void
>> *policy_buffer, size_t policy_size)
>> >>      }
>> >>
>> >>      xsm_ops = &dummy_xsm_ops;
>> >> -    flask_init(policy_buffer, policy_size);
>> >> +
>> >> +    switch ( xsm_bootparam )
>> >> +    {
>> >> +    case XSM_BOOTPARAM_DUMMY:
>> >> +        /* empty */
>> 
>> I'm not sure of the value of this comment.
> I just want avoid an empty switch case.

Well, it's not empty because of ...

>> >> +        break;

... this (without which it would be a fall-through one).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel