From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v4 2/2] allow hardware domain != dom0
Date: Wed, 16 Apr 2014 00:37:36 +0100
Message-ID: <534DC2C0.5040007@citrix.com>
References: <1397510594-5301-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1397510594-5301-2-git-send-email-dgdegra@tycho.nsa.gov>
	<534D4627.4050408@citrix.com> <534DADBB.8070107@tycho.nsa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <534DADBB.8070107@tycho.nsa.gov>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Tim Deegan <tim@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org, Jan Beulich <jbeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

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