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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel