From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: kvm <kvm@vger.kernel.org>, Joel Schopp <joel.schopp@amd.com>
Subject: Re: [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value
Date: Mon, 20 Apr 2015 20:33:03 +0200 [thread overview]
Message-ID: <20150420183303.GF26491@potion.brq.redhat.com> (raw)
In-Reply-To: <55353B3A.6060907@siemens.com>
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čmář wrote:
> >> 2015-04-20 19:21+0200, Jan Kiszka:
> >>> On 2015-04-20 19:16, Radim Krčmář wrote:
> >>>> 2015-04-20 18:14+0200, Radim Krčmář:
> >>>>> Tested-by: Radim Krčmář <rkrcmar@redhat.com>
> >>>>
> >>>> Uncached accesses were roughly 20x slower.
> >>>> In case anyone wanted to reproduce, I used this as a kvm-unit-test:
> >>>>
> >>>> ---
> >> | [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 ignore
> >> PAT for normal RAM on VMX and the test does "fail" ...
> >
> > 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.)
next prev parent reply other threads:[~2015-04-20 18:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-13 5:16 KVM: How does is PAT emulation supposed to work? Jan Kiszka
2015-04-13 6:58 ` [RFC][PATCH] KVM: SVM: Sync g_pat with guest-written PAT value Jan Kiszka
2015-04-17 16:59 ` Radim Krčmář
2015-04-20 16:14 ` Radim Krčmář
2015-04-20 17:16 ` Radim Krčmář
2015-04-20 17:21 ` Jan Kiszka
2015-04-20 17:33 ` Radim Krčmář
2015-04-20 17:37 ` Jan Kiszka
2015-04-20 17:45 ` Jan Kiszka
2015-04-20 18:33 ` Radim Krčmář [this message]
2015-04-20 18:41 ` Jan Kiszka
2015-04-21 12:10 ` Radim Krčmář
2015-04-21 12:11 ` Paolo Bonzini
2015-04-20 17:22 ` Radim Krčmář
2015-04-20 17:25 ` [PATCH v2] " Jan Kiszka
2015-04-20 17:35 ` Radim Krčmář
2015-04-21 11:09 ` Paolo Bonzini
2015-04-21 11:25 ` Jan Kiszka
2015-04-21 11:32 ` Paolo Bonzini
2015-04-21 11:56 ` Jan Kiszka
2015-04-21 12:12 ` Paolo Bonzini
2015-04-21 12:21 ` Radim Krčmář
2015-05-24 15:28 ` Jan Kiszka
2016-02-09 19:25 ` Jan Kiszka
2015-04-17 16:43 ` KVM: How does is PAT emulation supposed to work? Radim Krčmář
2015-04-17 17:12 ` Jan Kiszka
2015-04-17 20:28 ` Radim Krčmář
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150420183303.GF26491@potion.brq.redhat.com \
--to=rkrcmar@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=joel.schopp@amd.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).