From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH] x86/Dom0: Don't allow dom0_max_vcpus to be zero Date: Tue, 14 Apr 2015 09:52:10 -0400 Message-ID: <552D1B8A.2020306@oracle.com> References: <1428611923-1282-1-git-send-email-boris.ostrovsky@oracle.com> <5526E818.4040300@citrix.com> <552CDC1B0200007800071B6B@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <552CDC1B0200007800071B6B@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Andrew Cooper Cc: keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 04/14/2015 03:21 AM, Jan Beulich wrote: >>>> On 09.04.15 at 22:59, wrote: >> On 09/04/2015 21:38, Boris Ostrovsky wrote: >>> In case dom0_max_vcpus is incorrectly specified on boot line make sure >>> we will still boot. >>> >>> Signed-off-by: Boris Ostrovsky >> Good catch - lets not do that. >> >> Reviewed-by: Andrew Cooper > I see it got committed already, and I don't really mind the change, > but - are we really in need of this? I.e. are we really rejecting bad > or insane command line option values everywhere else? I very > much doubt that, and it very much looks like a "then don't do this" > thing to me... This actually happened to me (something happened with our installer). I agree that we can't predict how every option can go bad but we do try to prevent obvious errors so I figured this was worth a patch, especially given that it was pretty trivial. -boris