Re: [PATCH v4 2/2] allow hardware domain != dom0

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 16/04/14 10:08, Jan Beulich wrote:
>>>> On 16.04.14 at 01:37, <andrew.cooper3@citrix.com> wrote:
>> On 15/04/2014 23:07, Daniel De Graaf wrote:
>>> On 04/15/2014 10:45 AM, Andrew Cooper wrote:
>>>> On 14/04/14 22:23, Daniel De Graaf wrote:
>>>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>>>> index 3c05711..11c905a 100644
>>>>> --- a/xen/common/domain.c
>>>>> +++ b/xen/common/domain.c
>>>>> @@ -61,6 +61,11 @@ struct domain *domain_list;
>>>>>
>>>>>   struct domain *hardware_domain __read_mostly;
>>>>>
>>>>> +#ifdef CONFIG_LATE_HWDOM
>>>>> +domid_t hardware_domid __read_mostly;
>>>>> +integer_param("hardware_dom", hardware_domid);
>>>>> +#endif
>>>>> +
>>>> Is it worth putting a custom_param() in here which clamps hardware_domid
>>>> below FIRST_RESERVED_DOMID, or allow anyone specifying
>>>> hardware_dom=0xffff to keep all the broken pieces they find?  Aliasing
>>>> the magic domids is sure to break things.
>>>>
>>>> ~Andrew
>>> I'm currently of the opinion that a custom_param is overkill to prevent
>>> users from deliberately doing bad things, but could easily write one if
>>> others think that it would be helpful.
>>>
>> I suppose the answer depends on how subtle the breakage will be if the
>> user gets it accidentally wrong.  Given that slightly over half the
>> domid space is reserved and domid_t signed value, I can forsee subtle
>> bugs if a domid_t ever used as an array index, as well as very unsubtle
>> breakage if the user aliases one of the magic domids.
>>
>> On the balance, a custom_param() is probably worthwhile for peace of mind.
> Why can't we just BUG_ON() or panic() the first time domain_create()
> gets to see the out of range domain ID?
>
> Jan
>

That would also work.

~Andrew