From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Izik Eidus" Subject: (no subject) Date: Sun, 12 Aug 2007 12:59:17 -0700 Message-ID: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7DD1B.43974EDA" To: Return-path: Content-class: urn:content-classes:message List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DD1B.43974EDA Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7DD1B.43974EDA" ------_=_NextPart_002_01C7DD1B.43974EDA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable we are working on swapping support for the guests in kvm. we want to allow management of the memory swapping of the guests from = kvm. i wrote this patch that move the guest allocated memory from the kernel = to the userspace for better management. plus in this way it will share more code for such soultion with s390 and = other archs. this is request for comment, so any idea you have please write to me. thanks ------_=_NextPart_002_01C7DD1B.43974EDA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

we are working on swapping support for the guests in = kvm.
we want to allow management of the memory swapping of the guests from = kvm.

i wrote this patch that move the guest allocated memory from the kernel = to the userspace for better management.
plus in this way it will share more code for such soultion with s390 and = other archs.

this is request for comment, so any idea you have please write to = me.

thanks

------_=_NextPart_002_01C7DD1B.43974EDA-- ------_=_NextPart_001_01C7DD1B.43974EDA Content-Type: application/octet-stream; name="kvmctl_patch" Content-Transfer-Encoding: base64 Content-Description: kvmctl_patch Content-Disposition: attachment; filename="kvmctl_patch" ZGlmZiAtLWdpdCBhL3VzZXIva3ZtY3RsLmMgYi91c2VyL2t2bWN0bC5jCmluZGV4IDQzYjM3NGQu Ljg4N2NiNjMgMTAwNjQ0Ci0tLSBhL3VzZXIva3ZtY3RsLmMKKysrIGIvdXNlci9rdm1jdGwuYwpA QCAtMjM5LDEyICsyMzksMTMgQEAgaW50IGt2bV9jcmVhdGUoa3ZtX2NvbnRleHRfdCBrdm0sIHVu c2lnbmVkIGxvbmcgbWVtb3J5LCB2b2lkICoqdm1fbWVtKQogCWludCBmZCA9IGt2bS0+ZmQ7CiAJ aW50IHpmZDsKIAlpbnQgcjsKLQlzdHJ1Y3Qga3ZtX21lbW9yeV9yZWdpb24gbG93X21lbW9yeSA9 IHsKKworCXN0cnVjdCBrdm1faG9zdF9tZW1vcnlfcmVnaW9uIGxvd19tZW1vcnkgPSB7CiAJCS5z bG90ID0gMywKIAkJLm1lbW9yeV9zaXplID0gbWVtb3J5ICA8IGRvc21lbSA/IG1lbW9yeSA6IGRv c21lbSwKIAkJLmd1ZXN0X3BoeXNfYWRkciA9IDAsCiAJfTsKLQlzdHJ1Y3Qga3ZtX21lbW9yeV9y ZWdpb24gZXh0ZW5kZWRfbWVtb3J5ID0geworCXN0cnVjdCBrdm1faG9zdF9tZW1vcnlfcmVnaW9u IGV4dGVuZGVkX21lbW9yeSA9IHsKIAkJLnNsb3QgPSAwLAogCQkubWVtb3J5X3NpemUgPSBtZW1v cnkgPCBleG1lbSA/IDAgOiBtZW1vcnkgLSBleG1lbSwKIAkJLmd1ZXN0X3BoeXNfYWRkciA9IGV4 bWVtLApAQCAtMjU5LDE0ICsyNjAsNDEgQEAgaW50IGt2bV9jcmVhdGUoa3ZtX2NvbnRleHRfdCBr dm0sIHVuc2lnbmVkIGxvbmcgbWVtb3J5LCB2b2lkICoqdm1fbWVtKQogCX0KIAlrdm0tPnZtX2Zk ID0gZmQ7CiAKKwkqdm1fbWVtID0gbW1hcChOVUxMLCBtZW1vcnksIFBST1RfUkVBRHxQUk9UX1dS SVRFLCBNQVBfQU5PTllNT1VTIHwgTUFQX1NIQVJFRCwgLTEsIDApOworCWlmICgqdm1fbWVtID09 IE1BUF9GQUlMRUQpIHsKKwkJZnByaW50ZihzdGRlcnIsICJrdm1fY3JlYXRlOiAlcyIsIHN0cmVy cm9yKGVycm5vKSk7CisJCXJldHVybiAtMTsKKwl9CisKKwlyID0gbXVubWFwKG1lbW9yeSArIGRv c21lbSwgZXhtZW0gLSBkb3NtZW0pOworCWlmIChyID09IC0xKSB7CisJCWZwcmludGYoc3RkZXJy LCAia3ZtX2NyZWF0ZTogJXMiLCBzdHJlcnJvcihlcnJubykpOworCQlyZXR1cm4gLTE7CisJfQor CisJbWVtc2V0KCp2bV9tZW0sIDAsIGRvc21lbSk7CisJbWVtc2V0KCp2bV9tZW0gKyBleG1lbSwg MCwgbWVtb3J5IC0gZXhtZW0pOworCiAJLyogNjQwSyBzaG91bGQgYmUgZW5vdWdoLiAqLwotCXIg PSBpb2N0bChmZCwgS1ZNX1NFVF9NRU1PUllfUkVHSU9OLCAmbG93X21lbW9yeSk7CisJbG93X21l bW9yeS5ndWVzdF9ob3N0X2FkZHIgPSAqdm1fbWVtOworCWlmICghbG93X21lbW9yeS5ndWVzdF9o b3N0X2FkZHIpIHsKKwkJZnByaW50ZihzdGRlcnIsICJrdm1fY3JlYXRlOiAlcyIsIHN0cmVycm9y KGVycm5vKSk7CisJCXJldHVybiAtMTsKKwl9CisKKwlyID0gaW9jdGwoZmQsIEtWTV9TRVRfVVNF Ul9NRU1PUllfUkVHSU9OLCAmbG93X21lbW9yeSk7CiAJaWYgKHIgPT0gLTEpIHsKIAkJZnByaW50 ZihzdGRlcnIsICJrdm1fY3JlYXRlX21lbW9yeV9yZWdpb246ICVtXG4iKTsKIAkJcmV0dXJuIC0x OwogCX0KIAlpZiAoZXh0ZW5kZWRfbWVtb3J5Lm1lbW9yeV9zaXplKSB7Ci0JCXIgPSBpb2N0bChm ZCwgS1ZNX1NFVF9NRU1PUllfUkVHSU9OLCAmZXh0ZW5kZWRfbWVtb3J5KTsKKwkJZXh0ZW5kZWRf bWVtb3J5Lmd1ZXN0X2hvc3RfYWRkciA9ICp2bV9tZW0gKyBleG1lbTsKKwkJaWYgKCFleHRlbmRl ZF9tZW1vcnkuZ3Vlc3RfaG9zdF9hZGRyKSB7CisJCQlmcHJpbnRmKHN0ZGVyciwgImt2bV9jcmVh dGU6ICVzIiwgc3RyZXJyb3IoZXJybm8pKTsKKwkJCXJldHVybiAtMTsKKwkJfQorCisJCXIgPSBp b2N0bChmZCwgS1ZNX1NFVF9VU0VSX01FTU9SWV9SRUdJT04sICZleHRlbmRlZF9tZW1vcnkpOwog CQlpZiAociA9PSAtMSkgewogCQkJZnByaW50ZihzdGRlcnIsICJrdm1fY3JlYXRlX21lbW9yeV9y ZWdpb246ICVtXG4iKTsKIAkJCXJldHVybiAtMTsKQEAgLTI3NiwxMSArMzA0LDYgQEAgaW50IGt2 bV9jcmVhdGUoa3ZtX2NvbnRleHRfdCBrdm0sIHVuc2lnbmVkIGxvbmcgbWVtb3J5LCB2b2lkICoq dm1fbWVtKQogCWt2bV9tZW1vcnlfcmVnaW9uX3NhdmVfcGFyYW1zKGt2bSwgJmxvd19tZW1vcnkp OwogCWt2bV9tZW1vcnlfcmVnaW9uX3NhdmVfcGFyYW1zKGt2bSwgJmV4dGVuZGVkX21lbW9yeSk7 CiAKLQkqdm1fbWVtID0gbW1hcChOVUxMLCBtZW1vcnksIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBN QVBfU0hBUkVELCBmZCwgMCk7Ci0JaWYgKCp2bV9tZW0gPT0gTUFQX0ZBSUxFRCkgewotCQlmcHJp bnRmKHN0ZGVyciwgIm1tYXA6ICVtXG4iKTsKLQkJcmV0dXJuIC0xOwotCX0KIAlrdm0tPnBoeXNp Y2FsX21lbW9yeSA9ICp2bV9tZW07CiAKIAl6ZmQgPSBvcGVuKCIvZGV2L3plcm8iLCBPX1JET05M WSk7CkBAIC0yOTEsNyArMzE0LDcgQEAgaW50IGt2bV9jcmVhdGUoa3ZtX2NvbnRleHRfdCBrdm0s IHVuc2lnbmVkIGxvbmcgbWVtb3J5LCB2b2lkICoqdm1fbWVtKQogCXIgPSBrdm1fY3JlYXRlX3Zj cHUoa3ZtLCAwKTsKIAlpZiAociA8IDApCiAJCXJldHVybiByOwotCisJCiAJcmV0dXJuIDA7CiB9 CiAKQEAgLTMwMiwyNSArMzI1LDM2IEBAIHZvaWQgKmt2bV9jcmVhdGVfcGh5c19tZW0oa3ZtX2Nv bnRleHRfdCBrdm0sIHVuc2lnbmVkIGxvbmcgcGh5c19zdGFydCwKIAlpbnQgcjsKIAlpbnQgZmQg PSBrdm0tPnZtX2ZkOwogCWludCBwcm90ID0gUFJPVF9SRUFEOwotCXN0cnVjdCBrdm1fbWVtb3J5 X3JlZ2lvbiBtZW1vcnkgPSB7CisJc3RydWN0IGt2bV9ob3N0X21lbW9yeV9yZWdpb24gbWVtb3J5 ID0gewogCQkuc2xvdCA9IHNsb3QsCiAJCS5tZW1vcnlfc2l6ZSA9IGxlbiwKIAkJLmd1ZXN0X3Bo eXNfYWRkciA9IHBoeXNfc3RhcnQsCiAJCS5mbGFncyA9IGxvZyA/IEtWTV9NRU1fTE9HX0RJUlRZ X1BBR0VTIDogMCwKIAl9OwotCi0JciA9IGlvY3RsKGZkLCBLVk1fU0VUX01FTU9SWV9SRUdJT04s ICZtZW1vcnkpOworCQorCWlmICh3cml0YWJsZSkKKwkJcHJvdCB8PSBQUk9UX1dSSVRFOworCQor CXB0ciA9IG1tYXAoTlVMTCwgbGVuLCBwcm90LCBNQVBfQU5PTllNT1VTIHwgTUFQX1NIQVJFRCwg LTEsIDApOworCWlmIChwdHIgPT0gTUFQX0ZBSUxFRCkgeworCQlmcHJpbnRmKHN0ZGVyciwgImt2 bV9jcmVhdGVfcGh5c19tZW06ICVzIiwgc3RyZXJyb3IoZXJybm8pKTsKKwkJcmV0dXJuIC0xOwor CX0KKwkKKwltZW1zZXQocHRyLCAwLCBsZW4pOworCQorCW1lbW9yeS5ndWVzdF9ob3N0X2FkZHIg PSBwdHI7CisJaWYgKCFtZW1vcnkuZ3Vlc3RfaG9zdF9hZGRyKSB7CisJCWZwcmludGYoc3RkZXJy LCAia3ZtX2NyZWF0ZV9waHlzX21lbTogJXMiLCBzdHJlcnJvcihlcnJubykpOworCQlyZXR1cm4g MDsKKwl9CisJCisJciA9IGlvY3RsKGZkLCBLVk1fU0VUX1VTRVJfTUVNT1JZX1JFR0lPTiwgJm1l bW9yeSk7CiAJaWYgKHIgPT0gLTEpCiAJICAgIHJldHVybiAwOwogCiAJa3ZtX21lbW9yeV9yZWdp b25fc2F2ZV9wYXJhbXMoa3ZtLCAmbWVtb3J5KTsKIAotCWlmICh3cml0YWJsZSkKLQkJcHJvdCB8 PSBQUk9UX1dSSVRFOwotCi0JcHRyID0gbW1hcChOVUxMLCBsZW4sIHByb3QsIE1BUF9TSEFSRUQs IGZkLCBwaHlzX3N0YXJ0KTsKLQlpZiAocHRyID09IE1BUF9GQUlMRUQpCi0JCXJldHVybiAwOwog CXJldHVybiBwdHI7CiB9CiAK ------_=_NextPart_001_01C7DD1B.43974EDA Content-Type: application/octet-stream; name="kvm_kernel_patch" Content-Transfer-Encoding: base64 Content-Description: kvm_kernel_patch Content-Disposition: attachment; filename="kvm_kernel_patch" ZGlmZiAtLWdpdCBhL2RyaXZlcnMva3ZtL2t2bS5oIGIvZHJpdmVycy9rdm0va3ZtLmgKaW5kZXgg ZmMyN2MyZi4uYTk0NzE0ZiAxMDA2NDQKLS0tIGEvZHJpdmVycy9rdm0va3ZtLmgKKysrIGIvZHJp dmVycy9rdm0va3ZtLmgKQEAgLTQxNSw2ICs0MTUsNyBAQCBzdHJ1Y3Qga3ZtX21lbW9yeV9zbG90 IHsKIAl1bnNpZ25lZCBsb25nIGZsYWdzOwogCXN0cnVjdCBwYWdlICoqcGh5c19tZW07CiAJdW5z aWduZWQgbG9uZyAqZGlydHlfYml0bWFwOworCWludCB1c2VyX2FsbG9jOyAvKiB1c2VyIGFsbG9j YXRlZCBtZW1vcnkgKi8KIH07CiAKIHN0cnVjdCBrdm0gewpkaWZmIC0tZ2l0IGEvZHJpdmVycy9r dm0va3ZtX21haW4uYyBiL2RyaXZlcnMva3ZtL2t2bV9tYWluLmMKaW5kZXggYmMxMWMyZC4uMWU2 ZmE1OCAxMDA2NDQKLS0tIGEvZHJpdmVycy9rdm0va3ZtX21haW4uYworKysgYi9kcml2ZXJzL2t2 bS9rdm1fbWFpbi5jCkBAIC0zNyw2ICszNyw3IEBACiAjaW5jbHVkZSA8bGludXgvY3B1bWFzay5o PgogI2luY2x1ZGUgPGxpbnV4L3NtcC5oPgogI2luY2x1ZGUgPGxpbnV4L2Fub25faW5vZGVzLmg+ CisjaW5jbHVkZSA8bGludXgvcGFnZW1hcC5oPgogCiAjaW5jbHVkZSA8YXNtL3Byb2Nlc3Nvci5o PgogI2luY2x1ZGUgPGFzbS9tc3IuaD4KQEAgLTMyMiwxOSArMzIzLDQwIEBAIHN0YXRpYyBpbnQg a3ZtX2Rldl9vcGVuKHN0cnVjdCBpbm9kZSAqaW5vZGUsIHN0cnVjdCBmaWxlICpmaWxwKQogCXJl dHVybiAwOwogfQogCitzdGF0aWMgdm9pZCBrdm1fZnJlZV91c2Vyc3BhY2VfcGh5c21lbShzdHJ1 Y3Qga3ZtX21lbW9yeV9zbG90ICpmcmVlKQoreworCWludCBpOworCQorCWZvciAoaSA9IDA7IGkg PCBmcmVlLT5ucGFnZXM7ICsraSkgeworCQlpZiAoZnJlZS0+cGh5c19tZW1baV0pIHsKKwkJCWlm ICghUGFnZVJlc2VydmVkKGZyZWUtPnBoeXNfbWVtW2ldKSkKKwkJCQlTZXRQYWdlRGlydHkoZnJl ZS0+cGh5c19tZW1baV0pOworCQkJcGFnZV9jYWNoZV9yZWxlYXNlKGZyZWUtPnBoeXNfbWVtW2ld KTsKKwkJfQorCX0KK30KKworc3RhdGljIHZvaWQga3ZtX2ZyZWVfa2VybmVsX3BoeXNtZW0oc3Ry dWN0IGt2bV9tZW1vcnlfc2xvdCAqZnJlZSkKK3sKKwlpbnQgaTsKKwkKKwlmb3IgKGkgPSAwOyBp IDwgZnJlZS0+bnBhZ2VzOyArK2kpCisJCWlmIChmcmVlLT5waHlzX21lbVtpXSkKKwkJCV9fZnJl ZV9wYWdlKGZyZWUtPnBoeXNfbWVtW2ldKTsKK30KKwogLyoKICAqIEZyZWUgYW55IG1lbW9yeSBp biBAZnJlZSBidXQgbm90IGluIEBkb250LgogICovCiBzdGF0aWMgdm9pZCBrdm1fZnJlZV9waHlz bWVtX3Nsb3Qoc3RydWN0IGt2bV9tZW1vcnlfc2xvdCAqZnJlZSwKIAkJCQkgIHN0cnVjdCBrdm1f bWVtb3J5X3Nsb3QgKmRvbnQpCiB7Ci0JaW50IGk7Ci0KIAlpZiAoIWRvbnQgfHwgZnJlZS0+cGh5 c19tZW0gIT0gZG9udC0+cGh5c19tZW0pCiAJCWlmIChmcmVlLT5waHlzX21lbSkgewotCQkJZm9y IChpID0gMDsgaSA8IGZyZWUtPm5wYWdlczsgKytpKQotCQkJCWlmIChmcmVlLT5waHlzX21lbVtp XSkKLQkJCQkJX19mcmVlX3BhZ2UoZnJlZS0+cGh5c19tZW1baV0pOworCQkJaWYgKGZyZWUtPnVz ZXJfYWxsb2MpCisJCQkJa3ZtX2ZyZWVfdXNlcnNwYWNlX3BoeXNtZW0oZnJlZSk7CisJCQllbHNl CisJCQkJa3ZtX2ZyZWVfa2VybmVsX3BoeXNtZW0oZnJlZSk7CiAJCQl2ZnJlZShmcmVlLT5waHlz X21lbSk7CiAJCX0KIApAQCAtNjcwLDcgKzY5Miw4IEBAIEVYUE9SVF9TWU1CT0xfR1BMKGZ4X2lu aXQpOwogICogRGlzY29udGlndW91cyBtZW1vcnkgaXMgYWxsb3dlZCwgbW9zdGx5IGZvciBmcmFt ZWJ1ZmZlcnMuCiAgKi8KIHN0YXRpYyBpbnQga3ZtX3ZtX2lvY3RsX3NldF9tZW1vcnlfcmVnaW9u KHN0cnVjdCBrdm0gKmt2bSwKLQkJCQkJICBzdHJ1Y3Qga3ZtX21lbW9yeV9yZWdpb24gKm1lbSkK KwkJCQkJICBzdHJ1Y3Qga3ZtX21lbW9yeV9yZWdpb24gKm1lbSwKKwkJCQkJCXVuc2lnbmVkIGxv bmcgZ3Vlc3RfaG9zdF9hZGRyKQogewogCWludCByOwogCWdmbl90IGJhc2VfZ2ZuOwpAQCAtNzQ4 LDEyICs3NzEsMjYgQEAgcmFjZWQ6CiAJCQlnb3RvIG91dF9mcmVlOwogCiAJCW1lbXNldChuZXcu cGh5c19tZW0sIDAsIG5wYWdlcyAqIHNpemVvZihzdHJ1Y3QgcGFnZSAqKSk7Ci0JCWZvciAoaSA9 IDA7IGkgPCBucGFnZXM7ICsraSkgewotCQkJbmV3LnBoeXNfbWVtW2ldID0gYWxsb2NfcGFnZShH RlBfSElHSFVTRVIKLQkJCQkJCSAgICAgfCBfX0dGUF9aRVJPKTsKLQkJCWlmICghbmV3LnBoeXNf bWVtW2ldKQorCQkKKwkJaWYgKGd1ZXN0X2hvc3RfYWRkcikgeworCQkJdW5zaWduZWQgbG9uZyBw YWdlc19udW07CisJCQkKKwkJCW5ldy51c2VyX2FsbG9jID0gMTsKKwkJCWRvd25fcmVhZCgmY3Vy cmVudC0+bW0tPm1tYXBfc2VtKTsKKwkJCXBhZ2VzX251bSA9IGdldF91c2VyX3BhZ2VzKGN1cnJl bnQsIGN1cnJlbnQtPm1tLCBndWVzdF9ob3N0X2FkZHIsCisJCQkJCQkJCW5wYWdlcywgMSwgMCwg bmV3LnBoeXNfbWVtLCBOVUxMKTsKKwkJCXVwX3JlYWQoJmN1cnJlbnQtPm1tLT5tbWFwX3NlbSk7 CisJCQlpZiAocGFnZXNfbnVtICE9IG5wYWdlcykKIAkJCQlnb3RvIG91dF9mcmVlOwotCQkJc2V0 X3BhZ2VfcHJpdmF0ZShuZXcucGh5c19tZW1baV0sMCk7CisJCX0gZWxzZSB7CisJCQluZXcudXNl cl9hbGxvYyA9IDA7CisJCQlmb3IgKGkgPSAwOyBpIDwgbnBhZ2VzOyArK2kpIHsKKwkJCQluZXcu cGh5c19tZW1baV0gPSBhbGxvY19wYWdlKEdGUF9ISUdIVVNFUgorCQkJCQkJCSAgICAgfCBfX0dG UF9aRVJPKTsKKwkJCQlpZiAoIW5ldy5waHlzX21lbVtpXSkKKwkJCQkJZ290byBvdXRfZnJlZTsK KwkJCQlzZXRfcGFnZV9wcml2YXRlKG5ldy5waHlzX21lbVtpXSwwKTsKKwkJCX0KIAkJfQogCX0K IApAQCAtMjc3MiwxMCArMjgwOSwzMiBAQCBzdGF0aWMgbG9uZyBrdm1fdm1faW9jdGwoc3RydWN0 IGZpbGUgKmZpbHAsCiAJCXIgPSAtRUZBVUxUOwogCQlpZiAoY29weV9mcm9tX3VzZXIoJmt2bV9t ZW0sIGFyZ3AsIHNpemVvZiBrdm1fbWVtKSkKIAkJCWdvdG8gb3V0OwotCQlyID0ga3ZtX3ZtX2lv Y3RsX3NldF9tZW1vcnlfcmVnaW9uKGt2bSwgJmt2bV9tZW0pOworCQlyID0ga3ZtX3ZtX2lvY3Rs X3NldF9tZW1vcnlfcmVnaW9uKGt2bSwgJmt2bV9tZW0sIDApOworCQlpZiAocikKKwkJCWdvdG8g b3V0OworCQlicmVhazsKKwl9CisJY2FzZSBLVk1fU0VUX1VTRVJfTUVNT1JZX1JFR0lPTjogewor CQlzdHJ1Y3Qga3ZtX21lbW9yeV9yZWdpb24ga3ZtX21lbTsKKwkJc3RydWN0IGt2bV9ob3N0X21l bW9yeV9yZWdpb24ga3ZtX2hvc3RfbWVtOworCQlyID0gLUVGQVVMVDsKKwkJaWYgKGNvcHlfZnJv bV91c2VyKCZrdm1faG9zdF9tZW0sIGFyZ3AsIHNpemVvZiBrdm1faG9zdF9tZW0pKQorCQkJZ290 byBvdXQ7CisKKwkJaWYgKCFrdm1faG9zdF9tZW0uZ3Vlc3RfaG9zdF9hZGRyKQorCQkJZ290byBv dXQ7CQkKKworCQlrdm1fbWVtLnNsb3QgPSBrdm1faG9zdF9tZW0uc2xvdDsKKwkJa3ZtX21lbS5m bGFncyA9IGt2bV9ob3N0X21lbS5mbGFnczsKKwkJa3ZtX21lbS5ndWVzdF9waHlzX2FkZHIgPSBr dm1faG9zdF9tZW0uZ3Vlc3RfcGh5c19hZGRyOworCQlrdm1fbWVtLm1lbW9yeV9zaXplID0ga3Zt X2hvc3RfbWVtLm1lbW9yeV9zaXplOworCQkKKwkJciA9IGt2bV92bV9pb2N0bF9zZXRfbWVtb3J5 X3JlZ2lvbihrdm0sICZrdm1fbWVtLAorCQkJCQlrdm1faG9zdF9tZW0uZ3Vlc3RfaG9zdF9hZGRy KTsKIAkJaWYgKHIpCiAJCQlnb3RvIG91dDsKIAkJYnJlYWs7CisKIAl9CiAJY2FzZSBLVk1fR0VU X0RJUlRZX0xPRzogewogCQlzdHJ1Y3Qga3ZtX2RpcnR5X2xvZyBsb2c7CmRpZmYgLS1naXQgYS9p bmNsdWRlL2xpbnV4L2t2bS5oIGIvaW5jbHVkZS9saW51eC9rdm0uaAppbmRleCA5MWE0NDZmLi5l NTNlNzBlIDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4L2t2bS5oCisrKyBiL2luY2x1ZGUvbGlu dXgva3ZtLmgKQEAgLTIzLDYgKzIzLDE1IEBAIHN0cnVjdCBrdm1fbWVtb3J5X3JlZ2lvbiB7CiAJ X191NjQgbWVtb3J5X3NpemU7IC8qIGJ5dGVzICovCiB9OwogCisvKiBmb3IgS1ZNX1NFVF9VU0VS X01FTU9SWV9SRUdJT04gKi8KK3N0cnVjdCBrdm1faG9zdF9tZW1vcnlfcmVnaW9uIHsKKwlfX3Uz MiBzbG90OworCV9fdTMyIGZsYWdzOworCV9fdTY0IGd1ZXN0X3BoeXNfYWRkcjsKKwlfX3U2NCBt ZW1vcnlfc2l6ZTsgLyogYnl0ZXMgKi8KKwlfX3U2NCBndWVzdF9ob3N0X2FkZHI7IC8qIGhvc3Qg dXNlcnNwYWNlIGFsbG9jYXRlZCBtZW1vcnkgYWRkcmVzcyAqLworfTsKKwogLyogZm9yIGt2bV9t ZW1vcnlfcmVnaW9uOjpmbGFncyAqLwogI2RlZmluZSBLVk1fTUVNX0xPR19ESVJUWV9QQUdFUyAg MVVMCiAKQEAgLTI1NCw0NyArMjYzLDUwIEBAIHN0cnVjdCBrdm1fc2lnbmFsX21hc2sgewogLyoK ICAqIGlvY3RscyBmb3IgL2Rldi9rdm0gZmRzOgogICovCi0jZGVmaW5lIEtWTV9HRVRfQVBJX1ZF UlNJT04gICAgICAgX0lPKEtWTUlPLCAgIDB4MDApCi0jZGVmaW5lIEtWTV9DUkVBVEVfVk0gICAg ICAgICAgICAgX0lPKEtWTUlPLCAgIDB4MDEpIC8qIHJldHVybnMgYSBWTSBmZCAqLwotI2RlZmlu ZSBLVk1fR0VUX01TUl9JTkRFWF9MSVNUICAgIF9JT1dSKEtWTUlPLCAweDAyLCBzdHJ1Y3Qga3Zt X21zcl9saXN0KQorI2RlZmluZSBLVk1fR0VUX0FQSV9WRVJTSU9OICAgICAgICBfSU8oS1ZNSU8s ICAgMHgwMCkKKyNkZWZpbmUgS1ZNX0NSRUFURV9WTSAgICAgICAgICAgICAgX0lPKEtWTUlPLCAg IDB4MDEpIC8qIHJldHVybnMgYSBWTSBmZCAqLworI2RlZmluZSBLVk1fR0VUX01TUl9JTkRFWF9M SVNUICAgICBfSU9XUihLVk1JTywgMHgwMiwgc3RydWN0IGt2bV9tc3JfbGlzdCkKIC8qCiAgKiBD aGVjayBpZiBhIGt2bSBleHRlbnNpb24gaXMgYXZhaWxhYmxlLiAgQXJndW1lbnQgaXMgZXh0ZW5z aW9uIG51bWJlciwKICAqIHJldHVybiBpcyAxICh5ZXMpIG9yIDAgKG5vLCBzb3JyeSkuCiAgKi8K LSNkZWZpbmUgS1ZNX0NIRUNLX0VYVEVOU0lPTiAgICAgICBfSU8oS1ZNSU8sICAgMHgwMykKKyNk ZWZpbmUgS1ZNX0NIRUNLX0VYVEVOU0lPTiAgICAgICAgX0lPKEtWTUlPLCAgIDB4MDMpCiAvKgog ICogR2V0IHNpemUgZm9yIG1tYXAodmNwdV9mZCkKICAqLwotI2RlZmluZSBLVk1fR0VUX1ZDUFVf TU1BUF9TSVpFICAgIF9JTyhLVk1JTywgICAweDA0KSAvKiBpbiBieXRlcyAqLworI2RlZmluZSBL Vk1fR0VUX1ZDUFVfTU1BUF9TSVpFICAgICBfSU8oS1ZNSU8sICAgMHgwNCkgLyogaW4gYnl0ZXMg Ki8KIAogLyoKICAqIGlvY3RscyBmb3IgVk0gZmRzCiAgKi8KLSNkZWZpbmUgS1ZNX1NFVF9NRU1P UllfUkVHSU9OICAgICBfSU9XKEtWTUlPLCAweDQwLCBzdHJ1Y3Qga3ZtX21lbW9yeV9yZWdpb24p CisjZGVmaW5lIEtWTV9TRVRfTUVNT1JZX1JFR0lPTiAgICAgIF9JT1coS1ZNSU8sIDB4NDAsIHN0 cnVjdCBrdm1fbWVtb3J5X3JlZ2lvbikKKyNkZWZpbmUgS1ZNX1NFVF9VU0VSX01FTU9SWV9SRUdJ T04gX0lPVyhLVk1JTywgMHg0NCxcCisJCQkJCSBzdHJ1Y3Qga3ZtX2hvc3RfbWVtb3J5X3JlZ2lv bikKKwogLyoKICAqIEtWTV9DUkVBVEVfVkNQVSByZWNlaXZlcyBhcyBhIHBhcmFtZXRlciB0aGUg dmNwdSBzbG90LCBhbmQgcmV0dXJucwogICogYSB2Y3B1IGZkLgogICovCi0jZGVmaW5lIEtWTV9D UkVBVEVfVkNQVSAgICAgICAgICAgX0lPKEtWTUlPLCAgMHg0MSkKLSNkZWZpbmUgS1ZNX0dFVF9E SVJUWV9MT0cgICAgICAgICBfSU9XKEtWTUlPLCAweDQyLCBzdHJ1Y3Qga3ZtX2RpcnR5X2xvZykK LSNkZWZpbmUgS1ZNX1NFVF9NRU1PUllfQUxJQVMgICAgICBfSU9XKEtWTUlPLCAweDQzLCBzdHJ1 Y3Qga3ZtX21lbW9yeV9hbGlhcykKKyNkZWZpbmUgS1ZNX0NSRUFURV9WQ1BVICAgICAgICAgICAg X0lPKEtWTUlPLCAgMHg0MSkKKyNkZWZpbmUgS1ZNX0dFVF9ESVJUWV9MT0cgICAgICAgICAgX0lP VyhLVk1JTywgMHg0Miwgc3RydWN0IGt2bV9kaXJ0eV9sb2cpCisjZGVmaW5lIEtWTV9TRVRfTUVN T1JZX0FMSUFTICAgICAgIF9JT1coS1ZNSU8sIDB4NDMsIHN0cnVjdCBrdm1fbWVtb3J5X2FsaWFz KQogCiAvKgogICogaW9jdGxzIGZvciB2Y3B1IGZkcwogICovCi0jZGVmaW5lIEtWTV9SVU4gICAg ICAgICAgICAgICAgICAgX0lPKEtWTUlPLCAgIDB4ODApCi0jZGVmaW5lIEtWTV9HRVRfUkVHUyAg ICAgICAgICAgICAgX0lPUihLVk1JTywgIDB4ODEsIHN0cnVjdCBrdm1fcmVncykKLSNkZWZpbmUg S1ZNX1NFVF9SRUdTICAgICAgICAgICAgICBfSU9XKEtWTUlPLCAgMHg4Miwgc3RydWN0IGt2bV9y ZWdzKQotI2RlZmluZSBLVk1fR0VUX1NSRUdTICAgICAgICAgICAgIF9JT1IoS1ZNSU8sICAweDgz LCBzdHJ1Y3Qga3ZtX3NyZWdzKQotI2RlZmluZSBLVk1fU0VUX1NSRUdTICAgICAgICAgICAgIF9J T1coS1ZNSU8sICAweDg0LCBzdHJ1Y3Qga3ZtX3NyZWdzKQotI2RlZmluZSBLVk1fVFJBTlNMQVRF ICAgICAgICAgICAgIF9JT1dSKEtWTUlPLCAweDg1LCBzdHJ1Y3Qga3ZtX3RyYW5zbGF0aW9uKQot I2RlZmluZSBLVk1fSU5URVJSVVBUICAgICAgICAgICAgIF9JT1coS1ZNSU8sICAweDg2LCBzdHJ1 Y3Qga3ZtX2ludGVycnVwdCkKLSNkZWZpbmUgS1ZNX0RFQlVHX0dVRVNUICAgICAgICAgICBfSU9X KEtWTUlPLCAgMHg4Nywgc3RydWN0IGt2bV9kZWJ1Z19ndWVzdCkKLSNkZWZpbmUgS1ZNX0dFVF9N U1JTICAgICAgICAgICAgICBfSU9XUihLVk1JTywgMHg4OCwgc3RydWN0IGt2bV9tc3JzKQotI2Rl ZmluZSBLVk1fU0VUX01TUlMgICAgICAgICAgICAgIF9JT1coS1ZNSU8sICAweDg5LCBzdHJ1Y3Qg a3ZtX21zcnMpCi0jZGVmaW5lIEtWTV9TRVRfQ1BVSUQgICAgICAgICAgICAgX0lPVyhLVk1JTywg IDB4OGEsIHN0cnVjdCBrdm1fY3B1aWQpCi0jZGVmaW5lIEtWTV9TRVRfU0lHTkFMX01BU0sgICAg ICAgX0lPVyhLVk1JTywgIDB4OGIsIHN0cnVjdCBrdm1fc2lnbmFsX21hc2spCi0jZGVmaW5lIEtW TV9HRVRfRlBVICAgICAgICAgICAgICAgX0lPUihLVk1JTywgIDB4OGMsIHN0cnVjdCBrdm1fZnB1 KQotI2RlZmluZSBLVk1fU0VUX0ZQVSAgICAgICAgICAgICAgIF9JT1coS1ZNSU8sICAweDhkLCBz dHJ1Y3Qga3ZtX2ZwdSkKKyNkZWZpbmUgS1ZNX1JVTiAgICAgICAgICAgICAgICAgICAgX0lPKEtW TUlPLCAgIDB4ODApCisjZGVmaW5lIEtWTV9HRVRfUkVHUyAgICAgICAgICAgICAgIF9JT1IoS1ZN SU8sICAweDgxLCBzdHJ1Y3Qga3ZtX3JlZ3MpCisjZGVmaW5lIEtWTV9TRVRfUkVHUyAgICAgICAg ICAgICAgIF9JT1coS1ZNSU8sICAweDgyLCBzdHJ1Y3Qga3ZtX3JlZ3MpCisjZGVmaW5lIEtWTV9H RVRfU1JFR1MgICAgICAgICAgICAgIF9JT1IoS1ZNSU8sICAweDgzLCBzdHJ1Y3Qga3ZtX3NyZWdz KQorI2RlZmluZSBLVk1fU0VUX1NSRUdTICAgICAgICAgICAgICBfSU9XKEtWTUlPLCAgMHg4NCwg c3RydWN0IGt2bV9zcmVncykKKyNkZWZpbmUgS1ZNX1RSQU5TTEFURSAgICAgICAgICAgICAgX0lP V1IoS1ZNSU8sIDB4ODUsIHN0cnVjdCBrdm1fdHJhbnNsYXRpb24pCisjZGVmaW5lIEtWTV9JTlRF UlJVUFQgICAgICAgICAgICAgIF9JT1coS1ZNSU8sICAweDg2LCBzdHJ1Y3Qga3ZtX2ludGVycnVw dCkKKyNkZWZpbmUgS1ZNX0RFQlVHX0dVRVNUICAgICAgICAgICAgX0lPVyhLVk1JTywgIDB4ODcs IHN0cnVjdCBrdm1fZGVidWdfZ3Vlc3QpCisjZGVmaW5lIEtWTV9HRVRfTVNSUyAgICAgICAgICAg ICAgIF9JT1dSKEtWTUlPLCAweDg4LCBzdHJ1Y3Qga3ZtX21zcnMpCisjZGVmaW5lIEtWTV9TRVRf TVNSUyAgICAgICAgICAgICAgIF9JT1coS1ZNSU8sICAweDg5LCBzdHJ1Y3Qga3ZtX21zcnMpCisj ZGVmaW5lIEtWTV9TRVRfQ1BVSUQgICAgICAgICAgICAgIF9JT1coS1ZNSU8sICAweDhhLCBzdHJ1 Y3Qga3ZtX2NwdWlkKQorI2RlZmluZSBLVk1fU0VUX1NJR05BTF9NQVNLICAgICAgICBfSU9XKEtW TUlPLCAgMHg4Yiwgc3RydWN0IGt2bV9zaWduYWxfbWFzaykKKyNkZWZpbmUgS1ZNX0dFVF9GUFUg ICAgICAgICAgICAgICAgX0lPUihLVk1JTywgIDB4OGMsIHN0cnVjdCBrdm1fZnB1KQorI2RlZmlu ZSBLVk1fU0VUX0ZQVSAgICAgICAgICAgICAgICBfSU9XKEtWTUlPLCAgMHg4ZCwgc3RydWN0IGt2 bV9mcHUpCiAKICNlbmRpZgo= ------_=_NextPart_001_01C7DD1B.43974EDA Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ------_=_NextPart_001_01C7DD1B.43974EDA Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel ------_=_NextPart_001_01C7DD1B.43974EDA-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: (no subject) Date: Sun, 12 Aug 2007 16:37:47 -0500 Message-ID: <1186954667.9418.19.camel@squirrel> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Izik Eidus Return-path: In-Reply-To: <64F9B87B6B770947A9F8391472E032160CBECF40-yEcIvxbTEBqsx+V+t5oei8rau4O3wl8o3fe8/T/H7NteoWH0uzbU5w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Hi Izik, On Sun, 2007-08-12 at 12:59 -0700, Izik Eidus wrote: > we are working on swapping support for the guests in kvm. > we want to allow management of the memory swapping of the guests from > kvm. > > i wrote this patch that move the guest allocated memory from the > kernel to the userspace for better management. > plus in this way it will share more code for such soultion with s390 > and other archs. Do we care much about maintaining the kvmctl API? I ask because I think it would be nice to provide a pointer to kvmctl instead of having it allocate the memory. I think there are a few advantages to this. It simplifies the QEMU patch and it allows for the logic for choosing how memory is allocated to be done in QEMU. I'm thinking about things like allocating memory from hugetlbfs. Since large pages are a sparse commodity, I don't think we want to use large pages unless the user asks us to. Seems like this logic is best suited to be in QEMU to me. Otherwise, this page seems pretty good to me. There's some whitespace damage in this patch to btw. Regards, Anthony Liguori > this is request for comment, so any idea you have please write to me. > > thanks > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Izik Eidus" Subject: FW: (no subject) Date: Sun, 12 Aug 2007 15:43:28 -0700 Message-ID: <64F9B87B6B770947A9F8391472E032160CBECF4B@ehost011-8.exch011.intermedia.net> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> <1186954667.9418.19.camel@squirrel> <64F9B87B6B770947A9F8391472E032160CBECF4A@ehost011-8.exch011.intermedia.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0895675839==" To: Return-path: Content-class: urn:content-classes:message List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org This is a multi-part message in MIME format. --===============0895675839== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DD32.3A108CC0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DD32.3A108CC0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable -----=E4=E5=E3=F2=E4 =EE=F7=E5=F8=E9=FA----- =EE=E0=FA: Izik Eidus =F0=F9=EC=E7: =E0 12/08/2007 15:43 =E0=EC: Anthony Liguori =F0=E5=F9=E0: RE: [kvm-devel] (no subject) =20 hey Anthony, yes i think you are right. passing a pointer sound smarter to me. i dont think we should care at all about the kvmctl API, and as you said in this way it would be possible to do the memory allocation at QEMU. (this evil whitespaces ...) thanks. -----=E4=E5=E3=F2=E4 =EE=F7=E5=F8=E9=FA----- =EE=E0=FA: Anthony Liguori [mailto:anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org] =F0=F9=EC=E7: =E0 12/08/2007 14:37 =E0=EC: Izik Eidus =F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org =F0=E5=F9=E0: Re: [kvm-devel] (no subject) =20 Hi Izik, On Sun, 2007-08-12 at 12:59 -0700, Izik Eidus wrote: > we are working on swapping support for the guests in kvm. > we want to allow management of the memory swapping of the guests from > kvm. >=20 > i wrote this patch that move the guest allocated memory from the > kernel to the userspace for better management. > plus in this way it will share more code for such soultion with s390 > and other archs. Do we care much about maintaining the kvmctl API? I ask because I think it would be nice to provide a pointer to kvmctl instead of having it allocate the memory. I think there are a few advantages to this. It simplifies the QEMU patch and it allows for the logic for choosing how memory is allocated to be done in QEMU. I'm thinking about things like allocating memory from hugetlbfs. Since large pages are a sparse commodity, I don't think we want to use large pages unless the user asks us to. Seems like this logic is best suited to be in QEMU to me. Otherwise, this page seems pretty good to me. There's some whitespace damage in this patch to btw. Regards, Anthony Liguori > this is request for comment, so any idea you have please write to me. >=20 > thanks >=20 >=20 >=20 > = -------------------------------------------------------------------------= > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a = browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ kvm-devel mailing list = kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org = https://lists.sourceforge.net/lists/listinfo/kvm-devel ------_=_NextPart_001_01C7DD32.3A108CC0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable FW: [kvm-devel] (no subject)


-----=E4=E5=E3=F2=E4 =EE=F7=E5=F8=E9=FA-----
=EE=E0=FA: Izik Eidus
=F0=F9=EC=E7: =E0 12/08/2007 15:43
=E0=EC: Anthony Liguori
=F0=E5=F9=E0: RE: [kvm-devel] (no subject)

hey Anthony,
yes i think you are right.
passing a pointer sound smarter to me.
i dont think we should care at all about the kvmctl API, and as you = said
in this way it would be possible to do the memory allocation at = QEMU.

(this evil whitespaces ...)

thanks.

-----=E4=E5=E3=F2=E4 =EE=F7=E5=F8=E9=FA-----
=EE=E0=FA: Anthony Liguori [mailto:anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org] =F0=F9=EC=E7: =E0 12/08/2007 14:37
=E0=EC: Izik Eidus
=F2=E5=FA=F7 =EC=E9=E3=E9=F2=E4: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
=F0=E5=F9=E0: Re: [kvm-devel] (no subject)

Hi Izik,

On Sun, 2007-08-12 at 12:59 -0700, Izik Eidus wrote:
> we are working on swapping support for the guests in kvm.
> we want to allow management of the memory swapping of the guests = from
> kvm.
>
> i wrote this patch that move the guest allocated memory from = the
> kernel to the userspace for better management.
> plus in this way it will share more code for such soultion with = s390
> and other archs.

Do we care much about maintaining the kvmctl API?  I ask because I = think
it would be nice to provide a pointer to kvmctl instead of having it
allocate the memory.  I think there are a few advantages to = this.

It simplifies the QEMU patch and it allows for the logic for = choosing
how memory is allocated to be done in QEMU.  I'm thinking about = things
like allocating memory from hugetlbfs.  Since large pages are a = sparse
commodity, I don't think we want to use large pages unless the user = asks
us to.  Seems like this logic is best suited to be in QEMU to = me.

Otherwise, this page seems pretty good to me.

There's some whitespace damage in this patch to btw.

Regards,

Anthony Liguori


> this is request for comment, so any idea you have please write to = me.
>
> thanks
>
>
>
> = -------------------------------------------------------------------------=
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a = browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________ kvm-devel mailing = list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://l= ists.sourceforge.net/lists/listinfo/kvm-devel

------_=_NextPart_001_01C7DD32.3A108CC0-- --===============0895675839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============0895675839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============0895675839==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: (no subject) Date: Mon, 13 Aug 2007 11:10:30 +0300 Message-ID: <46C011F6.7070201@qumranet.com> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> <1186954667.9418.19.camel@squirrel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Izik Eidus , kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Anthony Liguori Return-path: In-Reply-To: <1186954667.9418.19.camel@squirrel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Anthony Liguori wrote: > Hi Izik, > > On Sun, 2007-08-12 at 12:59 -0700, Izik Eidus wrote: > >> we are working on swapping support for the guests in kvm. >> we want to allow management of the memory swapping of the guests from >> kvm. >> >> i wrote this patch that move the guest allocated memory from the >> kernel to the userspace for better management. >> plus in this way it will share more code for such soultion with s390 >> and other archs. >> > > Do we care much about maintaining the kvmctl API? Not so much at this time. We will later on (it will also be a dynamic library at that time). > I ask because I think > it would be nice to provide a pointer to kvmctl instead of having it > allocate the memory. I think there are a few advantages to this. > > It simplifies the QEMU patch and it allows for the logic for choosing > how memory is allocated to be done in QEMU. I'm thinking about things > like allocating memory from hugetlbfs. Since large pages are a sparse > commodity, I don't think we want to use large pages unless the user asks > us to. Seems like this logic is best suited to be in QEMU to me. > Yes, that is one of the motivations for this patch. Indeed it is a lot closer than guest paging. However this can be modified later, let's keep this patchset small for now. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Otte Subject: Re: (no subject) Date: Tue, 14 Aug 2007 12:38:14 +0200 Message-ID: <46C18616.5000005@de.ibm.com> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> Reply-To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Izik Eidus Return-path: In-Reply-To: <64F9B87B6B770947A9F8391472E032160CBECF40-yEcIvxbTEBqsx+V+t5oei8rau4O3wl8o3fe8/T/H7NteoWH0uzbU5w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Izik Eidus wrote: > we are working on swapping support for the guests in kvm. > we want to allow management of the memory swapping of the guests from kvm. This is excellent, thank you! > this is request for comment, so any idea you have please write to me. I ran into a few while reading the code: +static void kvm_free_userspace_physmem(struct kvm_memory_slot *free) +{ + int i; + + for (i = 0; i < free->npages; ++i) { + if (free->phys_mem[i]) { + if (!PageReserved(free->phys_mem[i])) + SetPageDirty(free->phys_mem[i]); + page_cache_release(free->phys_mem[i]); + } + } +} I don't see why we would want to dirty a page we release in general. We do only need to dirty it, if the corresponding page table entry indicates so (dirty bit). Did I miss something? @@ -670,7 +692,8 @@ EXPORT_SYMBOL_GPL(fx_init); * Discontiguous memory is allowed, mostly for framebuffers. */ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm, - struct kvm_memory_region *mem) + struct kvm_memory_region *mem, + unsigned long guest_host_addr) { int r; gfn_t base_gfn; @@ -748,12 +771,26 @@ raced: goto out_free; memset(new.phys_mem, 0, npages * sizeof(struct page *)); - for (i = 0; i < npages; ++i) { - new.phys_mem[i] = alloc_page(GFP_HIGHUSER - | __GFP_ZERO); - if (!new.phys_mem[i]) + + if (guest_host_addr) { + unsigned long pages_num; + + new.user_alloc = 1; + down_read(¤t->mm->mmap_sem); + pages_num = get_user_pages(current, current->mm, guest_host_addr, + npages, 1, 0, new.phys_mem, NULL); + up_read(¤t->mm->mmap_sem); + if (pages_num != npages) goto out_free; - set_page_private(new.phys_mem[i],0); + } else { + new.user_alloc = 0; + for (i = 0; i < npages; ++i) { + new.phys_mem[i] = alloc_page(GFP_HIGHUSER + | __GFP_ZERO); + if (!new.phys_mem[i]) + goto out_free; + set_page_private(new.phys_mem[i],0); + } } } Do we intend to maintain both pathes in the long run, or wait until we don't care about ancient userland anymore that does'nt do the allocation on its own? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Izik Eidus" Subject: FW: (no subject) Date: Tue, 14 Aug 2007 04:11:40 -0700 Message-ID: <64F9B87B6B770947A9F8391472E032160CBECF53@ehost011-8.exch011.intermedia.net> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> <46C18616.5000005@de.ibm.com> <64F9B87B6B770947A9F8391472E032160CBECF52@ehost011-8.exch011.intermedia.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1843125940==" To: Return-path: Content-class: urn:content-classes:message List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org This is a multi-part message in MIME format. --===============1843125940== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DE63.EBA4A30E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DE63.EBA4A30E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hey Carsten, about the dirty pages, i think you are right, i will look at this!. about the api, as far as i can tell yes, we are going to keep the api to = both options. (when i wrote it, i wrote it with thought about how not breaking the old = api.) thanks for the comments! :) -----Original Message----- From: Carsten Otte [mailto:cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org] Sent: Tue 8/14/2007 3:38 AM To: Izik Eidus Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Subject: Re: [kvm-devel] (no subject) =20 Izik Eidus wrote: > we are working on swapping support for the guests in kvm. > we want to allow management of the memory swapping of the guests from = kvm. This is excellent, thank you! > this is request for comment, so any idea you have please write to me. I ran into a few while reading the code: +static void kvm_free_userspace_physmem(struct kvm_memory_slot *free) +{ + int i; +=09 + for (i =3D 0; i < free->npages; ++i) { + if (free->phys_mem[i]) { + if (!PageReserved(free->phys_mem[i])) + SetPageDirty(free->phys_mem[i]); + page_cache_release(free->phys_mem[i]); + } + } +} I don't see why we would want to dirty a page we release in general.=20 We do only need to dirty it, if the corresponding page table entry=20 indicates so (dirty bit). Did I miss something? @@ -670,7 +692,8 @@ EXPORT_SYMBOL_GPL(fx_init); * Discontiguous memory is allowed, mostly for framebuffers. */ static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm, - struct kvm_memory_region *mem) + struct kvm_memory_region *mem, + unsigned long guest_host_addr) { int r; gfn_t base_gfn; @@ -748,12 +771,26 @@ raced: goto out_free; memset(new.phys_mem, 0, npages * sizeof(struct page *)); - for (i =3D 0; i < npages; ++i) { - new.phys_mem[i] =3D alloc_page(GFP_HIGHUSER - | __GFP_ZERO); - if (!new.phys_mem[i]) + =09 + if (guest_host_addr) { + unsigned long pages_num; + =09 + new.user_alloc =3D 1; + down_read(¤t->mm->mmap_sem); + pages_num =3D get_user_pages(current, current->mm, guest_host_addr, + npages, 1, 0, new.phys_mem, NULL); + up_read(¤t->mm->mmap_sem); + if (pages_num !=3D npages) goto out_free; - set_page_private(new.phys_mem[i],0); + } else { + new.user_alloc =3D 0; + for (i =3D 0; i < npages; ++i) { + new.phys_mem[i] =3D alloc_page(GFP_HIGHUSER + | __GFP_ZERO); + if (!new.phys_mem[i]) + goto out_free; + set_page_private(new.phys_mem[i],0); + } } } Do we intend to maintain both pathes in the long run, or wait until we=20 don't care about ancient userland anymore that does'nt do the=20 allocation on its own? ------_=_NextPart_001_01C7DE63.EBA4A30E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [kvm-devel] (no subject)

hey Carsten,
about the dirty pages, i think you are right, i will look at this!.
about the api, as far as i can tell yes, we are going to keep the api to = both options.
(when i wrote it, i wrote it with thought about how not breaking the old = api.)

thanks for the comments! :)

-----Original Message-----
From: Carsten Otte [mailto:cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org]
Sent: Tue 8/14/2007 3:38 AM
To: Izik Eidus
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [kvm-devel] (no subject)

Izik Eidus wrote:
> we are working on swapping support for the guests in kvm.
> we want to allow management of the memory swapping of the guests = from kvm.
This is excellent, thank you!

> this is request for comment, so any idea you have please write to = me.
I ran into a few while reading the code:

+static void kvm_free_userspace_physmem(struct kvm_memory_slot = *free)
+{
+       int i;
+      
+       for (i =3D 0; i < = free->npages; ++i) {
+       =         if (free->phys_mem[i]) = {
+       =         =         if = (!PageReserved(free->phys_mem[i]))
+       =         =         =         = SetPageDirty(free->phys_mem[i]);
+       =         =         = page_cache_release(free->phys_mem[i]);
+       =         }
+       }
+}
I don't see why we would want to dirty a page we release in general.
We do only need to dirty it, if the corresponding page table entry
indicates so (dirty bit). Did I miss something?



@@ -670,7 +692,8 @@ EXPORT_SYMBOL_GPL(fx_init);
   * Discontiguous memory is allowed, mostly for = framebuffers.
   */
  static int kvm_vm_ioctl_set_memory_region(struct kvm *kvm,
-       =         =         =         =           struct = kvm_memory_region *mem)
+       =         =         =         =           struct = kvm_memory_region *mem,
+       =         =         =         =         =         unsigned long = guest_host_addr)
  {
        int r;
        gfn_t base_gfn;
@@ -748,12 +771,26 @@ raced:
        =         =         goto out_free;

        =         memset(new.phys_mem, 0, = npages * sizeof(struct page *));
-       =         for (i =3D 0; i < npages; = ++i) {
-       =         =         new.phys_mem[i] =3D = alloc_page(GFP_HIGHUSER
-       =         =         =         =         =              | = __GFP_ZERO);
-       =         =         if (!new.phys_mem[i])
+       =        
+       =         if (guest_host_addr) {
+       =         =         unsigned long pages_num;
+       =         =        
+       =         =         new.user_alloc =3D 1;
+       =         =         = down_read(&current->mm->mmap_sem);
+       =         =         pages_num =3D = get_user_pages(current, current->mm, guest_host_addr,
+       =         =         =         =         =         =         =         npages, 1, 0, new.phys_mem, = NULL);
+       =         =         = up_read(&current->mm->mmap_sem);
+       =         =         if (pages_num !=3D = npages)
        =         =         =         goto out_free;
-       =         =         = set_page_private(new.phys_mem[i],0);
+       =         } else {
+       =         =         new.user_alloc =3D 0;
+       =         =         for (i =3D 0; i < npages; = ++i) {
+       =         =         =         new.phys_mem[i] =3D = alloc_page(GFP_HIGHUSER
+       =         =         =         =         =         =              | = __GFP_ZERO);
+       =         =         =         if (!new.phys_mem[i])
+       =         =         =         =         goto out_free;
+       =         =         =         = set_page_private(new.phys_mem[i],0);
+       =         =         }
        =         }
        }
Do we intend to maintain both pathes in the long run, or wait until = we
don't care about ancient userland anymore that does'nt do the
allocation on its own?

------_=_NextPart_001_01C7DE63.EBA4A30E-- --===============1843125940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============1843125940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel --===============1843125940==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: user-allocated memory Date: Tue, 14 Aug 2007 14:52:24 +0300 Message-ID: <46C19778.4090502@qumranet.com> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> <46C18616.5000005@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Izik Eidus , kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org Return-path: In-Reply-To: <46C18616.5000005-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Carsten Otte wrote: > Izik Eidus wrote: > >> we are working on swapping support for the guests in kvm. >> we want to allow management of the memory swapping of the guests from kvm. >> > This is excellent, thank you! > > >> this is request for comment, so any idea you have please write to me. >> > I ran into a few while reading the code: > > +static void kvm_free_userspace_physmem(struct kvm_memory_slot *free) > +{ > + int i; > + > + for (i = 0; i < free->npages; ++i) { > + if (free->phys_mem[i]) { > + if (!PageReserved(free->phys_mem[i])) > + SetPageDirty(free->phys_mem[i]); > + page_cache_release(free->phys_mem[i]); > + } > + } > +} > I don't see why we would want to dirty a page we release in general. > We do only need to dirty it, if the corresponding page table entry > indicates so (dirty bit). Did I miss something? > > kvm only tracks dirty bits if requested by userspace (for live migration). Checking the pte is not so easy because the pte contains only host addresses, not page addresses (well, we could consult the guest page table, but...). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Otte Subject: Re: user-allocated memory Date: Tue, 14 Aug 2007 14:54:12 +0200 Message-ID: <46C1A5F4.4070006@de.ibm.com> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> <46C18616.5000005@de.ibm.com> <46C19778.4090502@qumranet.com> Reply-To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org, Izik Eidus , kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Avi Kivity Return-path: In-Reply-To: <46C19778.4090502-atKUWr5tajBWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Avi Kivity wrote: > kvm only tracks dirty bits if requested by userspace (for live > migration). Checking the pte is not so easy because the pte contains > only host addresses, not page addresses (well, we could consult the > guest page table, but...). As far as I undstand this code, this function is used to release a memory page. Hopefully at this time the guest has not set up any page table entries to this page, because we're releasing the target page. When the guest migrates the dirty bit from its pte to its struct page (it always does this at least when removing the pte), we could indicate this to the hypervisor e.g. via hypercall. This way the hypervisor would know if the page is dirty or not, without asking the guest if the guest is paravirtual. That said, for ept/npt/s390 we have the information anyway without the need to do above trick, due to the double dirty/reference tracking approach. That would also work for non-paravirtual guests in that case. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: user-allocated memory Date: Tue, 14 Aug 2007 16:01:55 +0300 Message-ID: <46C1A7C3.6050809@qumranet.com> References: <64F9B87B6B770947A9F8391472E032160CBECF40@ehost011-8.exch011.intermedia.net> <46C18616.5000005@de.ibm.com> <46C19778.4090502@qumranet.com> <46C1A5F4.4070006@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Izik Eidus , kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org Return-path: In-Reply-To: <46C1A5F4.4070006-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Carsten Otte wrote: > Avi Kivity wrote: >> kvm only tracks dirty bits if requested by userspace (for live >> migration). Checking the pte is not so easy because the pte contains >> only host addresses, not page addresses (well, we could consult the >> guest page table, but...). > As far as I undstand this code, this function is used to release a > memory page. Hopefully at this time the guest has not set up any page > table entries to this page, because we're releasing the target page. > When the guest migrates the dirty bit from its pte to its struct page > (it always does this at least when removing the pte), we could > indicate this to the hypervisor e.g. via hypercall. This way the > hypervisor would know if the page is dirty or not, without asking the > guest if the guest is paravirtual. > That said, for ept/npt/s390 we have the information anyway without the > need to do above trick, due to the double dirty/reference tracking > approach. That would also work for non-paravirtual guests in that case. We can actually make it work for non-paravirt, non-npt as well; when removing the shadow pte, set the page dirty bit. I forgot that the gfn is immaterial for this. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/