From: Alex Williamson <alex.williamson@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"ddutile@redhat.com" <ddutile@redhat.com>,
"mst@redhat.com" <mst@redhat.com>,
"avi@redhat.com" <avi@redhat.com>,
"chrisw@redhat.com" <chrisw@redhat.com>
Subject: Re: [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts
Date: Wed, 23 Feb 2011 14:46:45 -0700 [thread overview]
Message-ID: <1298497605.18387.70.camel@x201> (raw)
In-Reply-To: <20110131191834.GA27154@amt.cnet>
On Mon, 2011-01-31 at 17:18 -0200, Marcelo Tosatti wrote:
> On Mon, Jan 24, 2011 at 10:37:56PM -0700, Alex Williamson wrote:
> > On Mon, 2011-01-24 at 08:44 -0700, Alex Williamson wrote:
> > > I'll look at how we might be
> > > able to allocate slots on demand. Thanks,
> >
> > Here's a first cut just to see if this looks agreeable. This allows the
> > slot array to grow on demand. This works with current userspace, as
> > well as userspace trivially modified to double KVMState.slots and
> > hotplugging enough pci-assign devices to exceed the previous limit (w/ &
> > w/o ept). Hopefully I got the rcu bits correct. Does this look like
> > the right path? If so, I'll work on removing the fixed limit from
> > userspace next. Thanks,
> >
> > Alex
> >
> >
> > kvm: Allow memory slot array to grow on demand
> >
> > Remove fixed KVM_MEMORY_SLOTS limit, allowing the slot array
> > to grow on demand. Private slots are now allocated at the
> > front instead of the end. Only x86 seems to use private slots,
> > so this is now zero for all other archs. The memslots pointer
> > is already updated using rcu, so changing the size off the
> > array when it's replaces is straight forward. x86 also keeps
> > a bitmap of slots used by a kvm_mmu_page, which requires a
> > shadow tlb flush whenever we increase the number of slots.
> > This forces the pages to be rebuilt with the new bitmap size.
> >
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> >
> > arch/ia64/include/asm/kvm_host.h | 4 --
> > arch/ia64/kvm/kvm-ia64.c | 2 +
> > arch/powerpc/include/asm/kvm_host.h | 3 --
> > arch/s390/include/asm/kvm_host.h | 3 --
> > arch/x86/include/asm/kvm_host.h | 3 +-
> > arch/x86/include/asm/vmx.h | 6 ++-
> > arch/x86/kvm/mmu.c | 7 +++-
> > arch/x86/kvm/x86.c | 6 ++-
> > include/linux/kvm_host.h | 7 +++-
> > virt/kvm/kvm_main.c | 65 ++++++++++++++++++++++++-----------
> > 10 files changed, 63 insertions(+), 43 deletions(-)
[snip]
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index fd67bcd..32f023c 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
[snip]
> > @@ -752,12 +753,19 @@ skip_lpage:
> >
> > if (!npages) {
> > r = -ENOMEM;
> > - slots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
> > +
> > + nmemslots = (mem->slot >= kvm->memslots->nmemslots) ?
> > + mem->slot + 1 : kvm->memslots->nmemslots;
> > +
> > + slots = kzalloc(sizeof(struct kvm_memslots) +
> > + nmemslots * sizeof(struct kvm_memory_slot),
> > + GFP_KERNEL);
> > if (!slots)
> > goto out_free;
> > - memcpy(slots, kvm->memslots, sizeof(struct kvm_memslots));
> > - if (mem->slot >= slots->nmemslots)
> > - slots->nmemslots = mem->slot + 1;
> > + memcpy(slots, kvm->memslots,
> > + sizeof(struct kvm_memslots) + kvm->memslots->nmemslots *
> > + sizeof(struct kvm_memory_slot));
> > + slots->nmemslots = nmemslots;
>
> Other than the upper limit, should disallow increasing the number of
> slots in case the new slot is being deleted (npages == 0). So none of
> this additions to !npages case should be necessary.
The existing code currently allows adding a slot with !npages. I'll
create a small separate patch to make this behavioral change.
> Also, must disallow shrinking the number of slots.
Right, we only grow, never shrink.
> > slots->generation++;
> > slots->memslots[mem->slot].flags |= KVM_MEMSLOT_INVALID;
> >
> > @@ -787,12 +795,21 @@ skip_lpage:
> > }
> >
> > r = -ENOMEM;
> > - slots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
> > +
> > + if (mem->slot >= kvm->memslots->nmemslots) {
> > + nmemslots = mem->slot + 1;
> > + flush = true;
> > + } else
> > + nmemslots = kvm->memslots->nmemslots;
> > +
> > + slots = kzalloc(sizeof(struct kvm_memslots) +
> > + nmemslots * sizeof(struct kvm_memory_slot),
> > + GFP_KERNEL);
> > if (!slots)
> > goto out_free;
> > - memcpy(slots, kvm->memslots, sizeof(struct kvm_memslots));
> > - if (mem->slot >= slots->nmemslots)
> > - slots->nmemslots = mem->slot + 1;
> > + memcpy(slots, kvm->memslots, sizeof(struct kvm_memslots) +
> > + kvm->memslots->nmemslots * sizeof(struct kvm_memory_slot));
> > + slots->nmemslots = nmemslots;
> > slots->generation++;
> >
> > /* actual memory is freed via old in kvm_free_physmem_slot below */
> > @@ -808,6 +825,9 @@ skip_lpage:
> > rcu_assign_pointer(kvm->memslots, slots);
>
> It should be:
>
> spin_lock(kvm->mmu_lock)
> rcu_assign_pointer()
> kvm_arch_flush_shadow()
> spin_unlock(kvm->mmu_lock)
>
> But kvm_arch_flush_shadow() takes mmu_lock currently, so that needs
> fixing.
Hmm, I tried to follow the example in the !npages path just above this
that does:
rcu_assign_pointer()
synchronize_srcu_expedited()
kvm_arch_flush_shadow()
Do we have an existing issue there with mmu_lock? Thanks,
Alex
next prev parent reply other threads:[~2011-02-23 21:46 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-21 23:48 [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts Alex Williamson
2011-01-21 23:48 ` [RFC PATCH 1/2] kvm: Allow querying free slots Alex Williamson
2011-01-21 23:48 ` [RFC PATCH 2/2] device-assignment: Count required kvm memory slots Alex Williamson
2011-01-22 22:11 ` [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts Michael S. Tsirkin
2011-01-24 9:32 ` Marcelo Tosatti
2011-01-24 14:16 ` Jan Kiszka
2011-01-24 15:44 ` Alex Williamson
2011-01-25 5:37 ` Alex Williamson
2011-01-25 7:36 ` Jan Kiszka
2011-01-25 14:41 ` Alex Williamson
2011-01-25 14:45 ` Michael S. Tsirkin
2011-01-25 14:54 ` Avi Kivity
2011-01-25 14:53 ` Avi Kivity
2011-01-25 14:59 ` Michael S. Tsirkin
2011-01-25 17:33 ` Avi Kivity
2011-01-25 17:58 ` Michael S. Tsirkin
2011-01-26 9:17 ` Avi Kivity
2011-01-26 9:20 ` Michael S. Tsirkin
2011-01-26 9:23 ` Avi Kivity
2011-01-26 9:39 ` Michael S. Tsirkin
2011-01-26 9:54 ` Avi Kivity
2011-01-26 12:08 ` Michael S. Tsirkin
2011-01-27 9:21 ` Avi Kivity
2011-01-27 9:26 ` Michael S. Tsirkin
2011-01-27 9:28 ` Avi Kivity
2011-01-27 9:29 ` Michael S. Tsirkin
2011-01-27 9:51 ` Avi Kivity
2011-01-27 9:28 ` Michael S. Tsirkin
2011-01-25 16:35 ` Jan Kiszka
2011-01-25 19:13 ` Alex Williamson
2011-01-26 8:14 ` Jan Kiszka
2011-01-25 10:23 ` Avi Kivity
2011-01-25 14:57 ` Alex Williamson
2011-01-25 17:11 ` Avi Kivity
2011-01-25 17:43 ` Alex Williamson
2011-01-26 9:22 ` Avi Kivity
2011-01-31 19:18 ` Marcelo Tosatti
2011-02-23 21:46 ` Alex Williamson [this message]
2011-02-24 12:34 ` Avi Kivity
2011-02-24 12:37 ` Avi Kivity
2011-02-24 18:10 ` Alex Williamson
2011-01-25 10:20 ` Avi Kivity
2011-01-25 14:46 ` Alex Williamson
2011-01-25 14:56 ` Avi Kivity
2011-01-25 14:55 ` Michael S. Tsirkin
2011-01-25 14:58 ` Avi Kivity
2011-01-25 15:23 ` Michael S. Tsirkin
2011-01-25 17:34 ` Avi Kivity
2011-01-25 18:00 ` Michael S. Tsirkin
2011-01-26 9:25 ` 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=1298497605.18387.70.camel@x201 \
--to=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=ddutile@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).