[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 2/2] allow hardware domain != dom0
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |