From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34376 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLo3X-0001PS-Av for qemu-devel@nongnu.org; Mon, 07 Jun 2010 21:56:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLo3W-0008TD-3B for qemu-devel@nongnu.org; Mon, 07 Jun 2010 21:56:43 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:57817) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLo3W-0008T7-09 for qemu-devel@nongnu.org; Mon, 07 Jun 2010 21:56:42 -0400 Received: by gyd5 with SMTP id 5so2928562gyd.4 for ; Mon, 07 Jun 2010 18:56:41 -0700 (PDT) Message-ID: <4C0DA356.8030506@codemonkey.ws> Date: Mon, 07 Jun 2010 20:56:38 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 15/22] machine: make max_cpus a -machine option References: <1275954730-8196-1-git-send-email-aliguori@us.ibm.com> <1275954730-8196-16-git-send-email-aliguori@us.ibm.com> <201006080201.08018.paul@codesourcery.com> In-Reply-To: <201006080201.08018.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Glauber Costa , qemu-devel@nongnu.org On 06/07/2010 08:01 PM, Paul Brook wrote: >> diff --git a/hw/realview.c b/hw/realview.c >> index a36bdbe..8dcef80 100644 >> --- a/hw/realview.c >> +++ b/hw/realview.c >> @@ -444,9 +444,9 @@ static QEMUMachine realview_eb_mpcore_machine = { >> .init = realview_eb_mpcore_init, >> .opts_default = (QemuOptValue[]) { >> QOPT_VALUE("default_drive", "scsi"), >> + QOPT_VALUE("max_cpus", "4"), >> { /* end of list */ } >> }, >> - .max_cpus = 4, >> }; >> > By my reading this allows the user to modify this value. If so it is wrong. > max_cpus is complicated because it was used for multiple purposes. I think max_cpus ought to be configurable. The reason it's useful to configure it that it lets a downstream specify a recommended max cpu that's mostly relevant from a scalability perspective. For instance, you may want to set the pc max_cpus to 64 since this is the highest that KVM supports today. > This is a fundamental property/limitation of the hardware. Expect qemu to > crash if the value is modified. > In this case, the machine cores should be rejecting totally invalid values to prevent crashes from occurring. My reading of realview does not suggest that a crash would occur. Are you speaking in general terms or do you think it will actually fail in realview? Regards, Anthony Liguori > Paul > >