From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] libkvm-s390 Date: Mon, 14 Jul 2008 14:44:09 +0300 Message-ID: <487B3C09.9030406@qumranet.com> References: <1215797386.6014.4.camel@cotte.boeblingen.de.ibm.com> <4879BCFD.9030806@qumranet.com> <200807141333.56783.borntraeger@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Carsten Otte , kvm , Olaf Schnapper , Hollis Blanchard To: Christian Borntraeger Return-path: Received: from il.qumranet.com ([212.179.150.194]:44900 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752453AbYGNLoK (ORCPT ); Mon, 14 Jul 2008 07:44:10 -0400 In-Reply-To: <200807141333.56783.borntraeger@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Borntraeger wrote: > >>> +#define LIBKVM_S390_ORIGIN (0UL) >>> >> Thought you got rid of that? >> > > Sort of. We have the kernel code ready to move away the guest from address 0. > To achieve that goal we use the offset and limit field in the control block. > Thing is, on older models the offset and limit must be < 128GB. that means we > still cannot use randomly allocated memory. LIBKVM_S390_ORIGIN=1M,2M or 16M > would be perfectly fine, 2TB (typical malloc space) is not. > Furthermore, this change is still in kvm.git, but not in Linus git. > Therefore, we would like to keep the guest at 0 and fix that at a later time, > ok? > Certainly. I suggest exposing this via a KVM_CAP_blah and adapting at runtime. Placing the guest at offset zero is dangerous, since all a guest has to do is place a function at guest physical address zero and wait for a kernel bug that calls a null function pointer (at least, it would behave like that on x86, provided no-execute was disabled; it may well be that s390 has additional protection). -- error compiling committee.c: too many arguments to function