From mboxrd@z Thu Jan  1 00:00:00 1970
From: Carsten Otte <cotte@de.ibm.com>
Subject: Re: [RFC/PATCH 15/15] guest: virtio device support,
 and kvm hypercalls
Date: Fri, 21 Mar 2008 08:12:15 +0100
Message-ID: <47E35FCF.80306@de.ibm.com>
References: <1206028710.6690.21.camel@cotte.boeblingen.de.ibm.com>
	<1206030328.6690.66.camel@cotte.boeblingen.de.ibm.com>
	<200803211124.49829.rusty@rustcorp.com.au>
Reply-To: carsteno@de.ibm.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Christian Ehrhardt <EHRHARDT@de.ibm.com>, arnd@arndb.de,
	hollisb@us.ibm.com, kvm-devel@lists.sourceforge.net,
	mschwid2@linux.vnet.ibm.com, heicars2@linux.vnet.ibm.com,
	jeroney@us.ibm.com, Avi Kivity <avi@qumranet.com>,
	virtualization@lists.linux-foundation.org,
	borntrae@linux.vnet.ibm.com, rvdheij@gmail.com,
	Olaf Schnapper <os@de.ibm.com>, jblunck@suse.de,
	"Zhang,  Xiantao" <xiantao.zhang@intel.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Return-path: <kvm-devel-bounces@lists.sourceforge.net>
In-Reply-To: <200803211124.49829.rusty@rustcorp.com.au>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel@lists.sourceforge.net>
List-Help: <mailto:kvm-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: kvm-devel-bounces@lists.sourceforge.net
Errors-To: kvm-devel-bounces@lists.sourceforge.net
List-Id: kvm.vger.kernel.org

Rusty Russell wrote:
>> +static int __init kvm_devices_init(void)
>> +{
>> +	if (!MACHINE_IS_KVM)
>> +		return -ENODEV;
>> +
>> +	if (device_register(&kvm_root) != 0)
>> +		panic("Could not register kvm root");
>> +
>> +	if (add_shared_memory((max_pfn) << PAGE_SHIFT, PAGE_SIZE)) {
>> +		device_unregister(&kvm_root);
>> +		return -ENOMEM;
>> +	}
> 
> Hmm, panic on device_register fail, but -ENOMEM on add_shared_memory fail?
> My theory was that since this is boot time, panic() is the right thing.
We can't tell whether or not this is an important device or not. Maybe 
the guest is running with ramdisk as rootfs and can have a happy life 
if we don't kill it here. Return the rc from device register seems to 
be the right thing to me, if it was an important device we'll see 
"panic: cannot mount rootfs" or something later.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/