All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Yang, Sheng" <sheng.yang@intel.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: VMX: Move private memory slot position
Date: Thu, 16 Oct 2008 10:26:07 +0200	[thread overview]
Message-ID: <48F6FA9F.3080408@redhat.com> (raw)
In-Reply-To: <200810131717.26020.sheng.yang@intel.com>

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.

> (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.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2008-10-16  8:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-04  3:30 [PATCH] KVM: VMX: Move private memory slot position Yang, Sheng
2008-09-11  9:26 ` Yang, Sheng
2008-09-13  5:01   ` Avi Kivity
2008-09-13  8:55     ` Avi Kivity
2008-10-13  9:17       ` Yang, Sheng
2008-10-16  8:26         ` Avi Kivity [this message]
2008-10-16  8:42           ` Sheng Yang
2008-10-19 11:02             ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48F6FA9F.3080408@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=sheng.yang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.