From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH] KVM: VMX: Move private memory slot position Date: Thu, 16 Oct 2008 16:42:29 +0800 Message-ID: <200810161642.29201.sheng@linux.intel.com> References: <200809041130.20249.sheng.yang@intel.com> <200810131717.26020.sheng.yang@intel.com> <48F6FA9F.3080408@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from mga10.intel.com ([192.55.52.92]:40984 "EHLO fmsmga102.fm.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752710AbYJPIoM (ORCPT ); Thu, 16 Oct 2008 04:44:12 -0400 In-Reply-To: <48F6FA9F.3080408@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Thursday 16 October 2008 16:26:07 Avi Kivity wrote: > Yang, Sheng wrote: > > I've found the reason... It's because that kvm_mmu_page->slot_bitmap is > > unsigned long, and if use KVM_MEMORY_SLOTS + xxx, it would beyond 32 in > > pae, then memory corrupted. > > > > But reduce supported memory slot number to 28 or extend slot_bitmap, or > > other methods? Slot_bitmap have bitops, so keep unsigned long would be > > better... Now reduce supported memory slot number seems reasonable to me. > > We could change it to DECLARE_BITMAP, and thus support >= 32 slots even > on i386. But I agree that 28 slots would be sufficient. DECLARE_BITMAP looks like a flexible solution, I forgot it...(and I also don't like to change a lot of macro in kernel and userspace). I will post the patch soon. > > > (I also want to have this fix into 2.6.28, for some device would easily > > overlapped with current private memory slot) > > I've been thinking that we can get rid of internal slots, by placing the > TSS, real mode identity map, and APIC access page in the bios. Of > course we would need a new ioctl to let the kernel know where the > scratch memory is located and how much of it is available. > How about put into userspace e.g. pc_init()? I think more easy than keeping bios sync with KVM. Anyway, vmx specific thing would become generic. I'd like to keep it as what it is at least for now... -- regards Yang, Sheng