From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] kvm tools: Fix type mismatches on GCC 4.4 on 32-bit
 systems
Date: Fri, 13 May 2011 10:37:18 +0200
Message-ID: <20110513083718.GD13647@elte.hu>
References: <20110513081909.GA14603@elte.hu>
 <BANLkTimPruk_knjTPZTNio1o4vKPb8CXXA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
	Asias He <asias.hejun@gmail.com>,
	Prasad Joshi <prasadjoshi124@gmail.com>,
	Sasha Levin <levinsasha928@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>
To: Pekka Enberg <penberg@kernel.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.mail.elte.hu ([157.181.151.9]:39740 "EHLO mx2.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1758029Ab1EMIhZ (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 13 May 2011 04:37:25 -0400
Content-Disposition: inline
In-Reply-To: <BANLkTimPruk_knjTPZTNio1o4vKPb8CXXA@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* Pekka Enberg <penberg@kernel.org> wrote:

> On Fri, May 13, 2011 at 11:19 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > @@ -162,7 +162,7 @@ static void kvm_register_mem_slot(struct kvm *k=
vm, u32 slot, u64 guest_phys, u64
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.slot =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =3D slot,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.guest_phys_addr =A0 =A0 =A0 =A0=3D =
guest_phys,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.memory_size =A0 =A0 =A0 =A0 =A0 =A0=
=3D size,
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 .userspace_addr =A0 =A0 =A0 =A0 =3D (=
u64)userspace_addr,
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .userspace_addr =A0 =A0 =A0 =A0 =3D (=
u64)(long)userspace_addr,
> > =A0 =A0 =A0 =A0};
>=20
> Isn't
>=20
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .userspace_addr =A0 =A0 =A0 =A0 =3D (un=
signed long)userspace_addr,
>=20
> the right thing to do here?

Yeah, you are right - and userspace_addr will always be 32-bit on 32-bi=
t hosts=20
so this is unrelated to the guest-pfn conversion thing.

More than 1-2 GB of RAM can be supported in the future by mmap()-ing a =
chunk,=20
passing the address to KVM and then unmapping it. In theory it is possi=
ble to=20
implement more than 4GB RAM support on 32-bit hosts without having to d=
o=20
highmem alike tricks in tools/kvm/, but i doubt there's much interest i=
n that -=20
everything is so much easier on 64-bit systems ...

Thanks,

	Ingo