From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value Date: Mon, 20 Apr 2015 20:33:03 +0200 Message-ID: <20150420183303.GF26491@potion.brq.redhat.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm , Joel Schopp To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54222 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752466AbbDTSdH (ORCPT ); Mon, 20 Apr 2015 14:33:07 -0400 Content-Disposition: inline In-Reply-To: <55353B3A.6060907@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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" ... > >=20 > > That ignoring is encoded into the EPT? Yes, it's the VMX_EPT_IPAT_BIT. > And do you also know why is it ignored on Intel? Side effects on the = host? I think it is an optimization exclusive to Intel. We know that the other side is not real hardware, which could avoid CPU caches when accessing memory, so there is little reason to slow the guest down. > > Hmm... Maybe we can create a > > ivshmem device and use that as test target. Good idea, thanks. (Haven't used it yet, so its parts might be able to do what is needed without creating a dependency on the whole ivshmem system.)