From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value Date: Mon, 20 Apr 2015 20:41:53 +0200 Message-ID: <55354871.5030208@siemens.com> References: <552B5128.4010909@siemens.com> <552B6923.3020602@siemens.com> <20150420161401.GB26491@potion.brq.redhat.com> <20150420171635.GC26491@potion.brq.redhat.com> <553535B1.3050901@siemens.com> <20150420173345.GB26478@potion.brq.redhat.com> <55353957.6010907@siemens.com> <55353B3A.6060907@siemens.com> <20150420183303.GF26491@potion.brq.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm , Joel Schopp To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from david.siemens.de ([192.35.17.14]:60188 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751722AbbDTSmE (ORCPT ); Mon, 20 Apr 2015 14:42:04 -0400 In-Reply-To: <20150420183303.GF26491@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2015-04-20 20:33, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2015-04-20 19:45+0200, Jan Kiszka: >> On 2015-04-20 19:37, Jan Kiszka wrote: >>> On 2015-04-20 19:33, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>>> 2015-04-20 19:21+0200, Jan Kiszka: >>>>> On 2015-04-20 19:16, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>>>>> 2015-04-20 18:14+0200, Radim Kr=C4=8Dm=C3=A1=C5=99: >>>>>>> Tested-by: Radim Kr=C4=8Dm=C3=A1=C5=99 >>>>>> >>>>>> Uncached accesses were roughly 20x slower. >>>>>> In case anyone wanted to reproduce, I used this as a kvm-unit-te= st: >>>>>> >>>>>> --- >>>> | [code] >>>>> >>>>> Great, thanks. Will you push it to the unit tests? Could raise >>>>> motivations to fix the !NPT/EPT case. >>>> >>>> It can't be included in `run_tests.sh`, because we intenionally ig= nore >>>> PAT for normal RAM on VMX and the test does "fail" ... >>> >>> That ignoring is encoded into the EPT? >=20 > Yes, it's the VMX_EPT_IPAT_BIT. >=20 >> And do you also know why is it ignored on Intel? Side effects on the= host? >=20 > I think it is an optimization exclusive to Intel. > We know that the other side is not real hardware, which could avoid C= PU > caches when accessing memory, so there is little reason to slow the > guest down. If the guest pushes data for DMA into RAM, it may assume that it lands there directly, without the need for explicit flushes, because it has caching disabled - no? Jan --=20 Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux