From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts Date: Tue, 25 Jan 2011 08:36:20 +0100 Message-ID: <4D3E7D74.1030100@web.de> References: <20110121233040.22262.68117.stgit@s20.home> <20110124093241.GA28654@amt.cnet> <4D3D89B1.30300@siemens.com> <1295883899.3230.9.camel@x201> <1295933876.3230.46.camel@x201> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0E98B40802A966E88881A199" Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , "ddutile@redhat.com" , "mst@redhat.com" , "avi@redhat.com" , "chrisw@redhat.com" To: Alex Williamson Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:56735 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751724Ab1AYHhB (ORCPT ); Tue, 25 Jan 2011 02:37:01 -0500 In-Reply-To: <1295933876.3230.46.camel@x201> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0E98B40802A966E88881A199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-01-25 06:37, 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, >=20 > Here's a first cut just to see if this looks agreeable. This allows th= e > 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, >=20 > Alex >=20 >=20 > kvm: Allow memory slot array to grow on demand >=20 > 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, Hmm, doesn't current user space expect slots 8..11 to be the private ones and wouldn't it cause troubles if slots 0..3 are suddenly reserved? > 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. Is it possible for user space to increase the slot number to ridiculous amounts (at least as far as kmalloc allows) and then trigger a kernel walk through them in non-preemptible contexts? Just wondering, I haven't checked all contexts of functions like kvm_is_visible_gfn yet. If yes, we should already switch to rbtree or something like that. Otherwise that may wait a bit, but probably not too long. Jan --------------enig0E98B40802A966E88881A199 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0+fXQACgkQitSsb3rl5xSuHQCfYKauy04MDzobcQXu93hv7b0g cVgAoO3kZ1EmtkjVF0ee8Z1UdMltgtos =y9s4 -----END PGP SIGNATURE----- --------------enig0E98B40802A966E88881A199--