From xen-devel-bounces@lists.xen.org Tue Feb 18 15:34:19 2014 Received: (at maildrop) by bugs.xenproject.org; 18 Feb 2014 15:34:19 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WFmgd-00008j-U0 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 18 Feb 2014 15:34:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFmbB-0002lr-SS; Tue, 18 Feb 2014 15:28:41 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFmbA-0002kt-8K for xen-devel@lists.xen.org; Tue, 18 Feb 2014 15:28:40 +0000 Received: from [193.109.254.147:18837] by server-12.bemta-14.messagelabs.com id 37/40-17220-72C73035; Tue, 18 Feb 2014 15:28:39 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1392737318!5202835!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ4MDU=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3926 invoked from network); 18 Feb 2014 15:28:38 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Feb 2014 15:28:38 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Tue, 18 Feb 2014 15:28:38 +0000 Message-Id: <53038A33020000780011D5FD@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Tue, 18 Feb 2014 15:28:35 +0000 From: "Jan Beulich" To: "Dongxiao Xu" , "Xiantao Zhang" , "Yang Z Zhang" References: <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> <20140211115553.GB97288@deinos.phlegethon.org> <52FA2C63020000780011B201@nat28.tlf.novell.com> <52FA480D.9040707@eu.citrix.com> <52FCE8BE.8050105@eu.citrix.com> <52FCF90F020000780011C29A@nat28.tlf.novell.com> <20140213162022.GE82703@deinos.phlegethon.org> <5301F000020000780011CCE0@nat28.tlf.novell.com> <53023239020000780011CED9@nat28.tlf.novell.com> <53035628020000780011D3EE@nat28.tlf.novell.com> In-Reply-To: <53035628020000780011D3EE@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part77452A33.3__=" Cc: George Dunlap , "andrew.cooper3@citrix.com" , Tim Deegan , DonaldD Dugger , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part77452A33.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline >>> On 18.02.14 at 12:46, "Jan Beulich" wrote: > Nothing at all, as it turns out. The regression is due to Dongxiao's >=20 > http://lists.xenproject.org/archives/html/xen-devel/2013-12/msg00367.html= =20 >=20 > which I have in my tree as part of various things pending for 4.5. > And which at the first, second, and third glance looks pretty > innocent (IOW I still have to find out _why_ it is wrong). And here's a fixed version of the patch - we simply can't drop the bogus HVM_PARAM_IDENT_PT check entirely yet. In the course of fixing this I also found two other shortcomings: - EPT EMT field should be updated upon guest MTRR writes (the lack thereof is the reason for needing to retain the bogus check) - epte_get_entry_emt() either needs "order" passed, or its callers must call it more than once for big/huge pages Jan x86/hvm: refine the judgment on IDENT_PT for EMT When trying to get the EPT EMT type, the judgment on HVM_PARAM_IDENT_PT is not correct which always returns WB type if the parameter is not set. Remove the related code. Signed-off-by: Dongxiao Xu We can't fully drop the dependency yet, but we should certainly avoid overriding cases already properly handled. The reason for this is that the guest setting up its MTRRs happens _after_ the EPT tables got already constructed, and no code is in place to propagate this to the EPT code. Without this check we're forcing the guest to run with all of its memory uncachable until something happens to re-write every single EPT entry. But of course this has to be just a temporary solution. In the same spirit we should defer the "very early" (when the guest is still being constructed and has no vCPU yet) override to the last possible point. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/mtrr.c +++ b/xen/arch/x86/hvm/mtrr.c @@ -689,13 +689,8 @@ uint8_t epte_get_entry_emt(struct domain =20 *ipat =3D 0; =20 - if ( (current->domain !=3D d) && - ((d->vcpu =3D=3D NULL) || ((v =3D d->vcpu[0]) =3D=3D NULL)) ) - return MTRR_TYPE_WRBACK; - - if ( !is_pvh_vcpu(v) && - !v->domain->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] ) - return MTRR_TYPE_WRBACK; + if ( v->domain !=3D d ) + v =3D d->vcpu ? d->vcpu[0] : NULL; =20 if ( !mfn_valid(mfn_x(mfn)) ) return MTRR_TYPE_UNCACHABLE; @@ -718,7 +713,8 @@ uint8_t epte_get_entry_emt(struct domain return MTRR_TYPE_WRBACK; } =20 - gmtrr_mtype =3D is_hvm_vcpu(v) ? + gmtrr_mtype =3D is_hvm_domain(d) && v && + d->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] ? get_mtrr_type(&v->arch.hvm_vcpu.mtrr, (gfn << PAGE_SHIFT= )) : MTRR_TYPE_WRBACK; =20 --=__Part77452A33.3__= Content-Type: application/octet-stream; name="EPT-ignore-IDENT_PT" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="EPT-ignore-IDENT_PT" eDg2L2h2bTogcmVmaW5lIHRoZSBqdWRnbWVudCBvbiBJREVOVF9QVCBmb3IgRU1UCgpXaGVuIHRy eWluZyB0byBnZXQgdGhlIEVQVCBFTVQgdHlwZSwgdGhlIGp1ZGdtZW50IG9uCkhWTV9QQVJBTV9J REVOVF9QVCBpcyBub3QgY29ycmVjdCB3aGljaCBhbHdheXMgcmV0dXJucyBXQiB0eXBlIGlmCnRo ZSBwYXJhbWV0ZXIgaXMgbm90IHNldC4gUmVtb3ZlIHRoZSByZWxhdGVkIGNvZGUuCgpTaWduZWQt b2ZmLWJ5OiBEb25neGlhbyBYdSA8ZG9uZ3hpYW8ueHVAaW50ZWwuY29tPgoKV2UgY2FuJ3QgZnVs bHkgZHJvcCB0aGUgZGVwZW5kZW5jeSB5ZXQsIGJ1dCB3ZSBzaG91bGQgY2VydGFpbmx5IGF2b2lk Cm92ZXJyaWRpbmcgY2FzZXMgYWxyZWFkeSBwcm9wZXJseSBoYW5kbGVkLiBUaGUgcmVhc29uIGZv ciB0aGlzIGlzIHRoYXQKdGhlIGd1ZXN0IHNldHRpbmcgdXAgaXRzIE1UUlJzIGhhcHBlbnMgX2Fm dGVyXyB0aGUgRVBUIHRhYmxlcyBnb3QKYWxyZWFkeSBjb25zdHJ1Y3RlZCwgYW5kIG5vIGNvZGUg aXMgaW4gcGxhY2UgdG8gcHJvcGFnYXRlIHRoaXMgdG8gdGhlCkVQVCBjb2RlLiBXaXRob3V0IHRo aXMgY2hlY2sgd2UncmUgZm9yY2luZyB0aGUgZ3Vlc3QgdG8gcnVuIHdpdGggYWxsIG9mCml0cyBt ZW1vcnkgdW5jYWNoYWJsZSB1bnRpbCBzb21ldGhpbmcgaGFwcGVucyB0byByZS13cml0ZSBldmVy eSBzaW5nbGUKRVBUIGVudHJ5LiBCdXQgb2YgY291cnNlIHRoaXMgaGFzIHRvIGJlIGp1c3QgYSB0 ZW1wb3Jhcnkgc29sdXRpb24uCgpJbiB0aGUgc2FtZSBzcGlyaXQgd2Ugc2hvdWxkIGRlZmVyIHRo ZSAidmVyeSBlYXJseSIgKHdoZW4gdGhlIGd1ZXN0IGlzCnN0aWxsIGJlaW5nIGNvbnN0cnVjdGVk IGFuZCBoYXMgbm8gdkNQVSB5ZXQpIG92ZXJyaWRlIHRvIHRoZSBsYXN0CnBvc3NpYmxlIHBvaW50 LgoKU2lnbmVkLW9mZi1ieTogSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPgoKLS0tIGEv eGVuL2FyY2gveDg2L2h2bS9tdHJyLmMKKysrIGIveGVuL2FyY2gveDg2L2h2bS9tdHJyLmMKQEAg LTY4OSwxMyArNjg5LDggQEAgdWludDhfdCBlcHRlX2dldF9lbnRyeV9lbXQoc3RydWN0IGRvbWFp bgogCiAgICAgKmlwYXQgPSAwOwogCi0gICAgaWYgKCAoY3VycmVudC0+ZG9tYWluICE9IGQpICYm Ci0gICAgICAgICAoKGQtPnZjcHUgPT0gTlVMTCkgfHwgKCh2ID0gZC0+dmNwdVswXSkgPT0gTlVM TCkpICkKLSAgICAgICAgcmV0dXJuIE1UUlJfVFlQRV9XUkJBQ0s7Ci0KLSAgICBpZiAoICFpc19w dmhfdmNwdSh2KSAmJgotICAgICAgICAgIXYtPmRvbWFpbi0+YXJjaC5odm1fZG9tYWluLnBhcmFt c1tIVk1fUEFSQU1fSURFTlRfUFRdICkKLSAgICAgICAgcmV0dXJuIE1UUlJfVFlQRV9XUkJBQ0s7 CisgICAgaWYgKCB2LT5kb21haW4gIT0gZCApCisgICAgICAgIHYgPSBkLT52Y3B1ID8gZC0+dmNw dVswXSA6IE5VTEw7CiAKICAgICBpZiAoICFtZm5fdmFsaWQobWZuX3gobWZuKSkgKQogICAgICAg ICByZXR1cm4gTVRSUl9UWVBFX1VOQ0FDSEFCTEU7CkBAIC03MTgsNyArNzEzLDggQEAgdWludDhf dCBlcHRlX2dldF9lbnRyeV9lbXQoc3RydWN0IGRvbWFpbgogICAgICAgICByZXR1cm4gTVRSUl9U WVBFX1dSQkFDSzsKICAgICB9CiAKLSAgICBnbXRycl9tdHlwZSA9IGlzX2h2bV92Y3B1KHYpID8K KyAgICBnbXRycl9tdHlwZSA9IGlzX2h2bV9kb21haW4oZCkgJiYgdiAmJgorICAgICAgICAgICAg ICAgICAgZC0+YXJjaC5odm1fZG9tYWluLnBhcmFtc1tIVk1fUEFSQU1fSURFTlRfUFRdID8KICAg ICAgICAgICAgICAgICAgIGdldF9tdHJyX3R5cGUoJnYtPmFyY2guaHZtX3ZjcHUubXRyciwgKGdm biA8PCBQQUdFX1NISUZUKSkgOgogICAgICAgICAgICAgICAgICAgTVRSUl9UWVBFX1dSQkFDSzsK IAo= --=__Part77452A33.3__= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --=__Part77452A33.3__=--