All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>, Andi Kleen <andi@firstfloor.org>,
	peterz@infradead.org, pbonzini@redhat.com, eranian@google.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] kvm: Implement PEBS virtualization
Date: Mon, 2 Jun 2014 16:09:07 -0300	[thread overview]
Message-ID: <20140602190907.GA7590@amt.cnet> (raw)
In-Reply-To: <20140602164534.GD4715@minantech.com>

On Mon, Jun 02, 2014 at 07:45:35PM +0300, Gleb Natapov wrote:
> On Fri, May 30, 2014 at 09:24:24AM -0700, Andi Kleen wrote:
> > > > To avoid any problems with guest pages being swapped by the host we
> > > > pin the pages when the PEBS buffer is setup, by intercepting
> > > > that MSR.
> > > It will avoid guest page to be swapped, but shadow paging code may still drop
> > > shadow PT pages that build a mapping from DS virtual address to the guest page.
> > 
> > You're saying the EPT code could tear down the EPT mappings?
> 
> Under memory pressure yes. mmu_shrink_scan() calls
> prepare_zap_oldest_mmu_page() which destroys oldest mmu pages like its
> name says. As far as I can tell running nested guest can also result in
> EPT mapping to be dropped since it will create a lot of shadow pages and
> this will cause make_mmu_pages_available() to destroy some shadow pages
> and it may choose EPT pages to destroy.
> 
> CCing Marcelo to confirm/correct.

Yes. Given SLAB pressure any shadow pages can be deleted except pinned 
via root_count=1 ones.

> > OK that would need to be prevented too. Any suggestions how?
> Only high level. Mark shadow pages involved in translation we want to keep and skip them in
> prepare_zap_oldest_mmu_page().

Should special case such translations so that they are not zapped
(either via page deletion or single entry EPT deletion). Them
and any other their parents, bummer.

Maybe its cleaner to check that DS area is EPT mapped before VM-entry.

No way the processor can generate VM-exits ?

Is it not an option to fake a DS-save area in the host (and trap
any accesses to the DS_AREA MSR from the guest) ? 
Then before notifying the PEBS event, copy from that host area to 
guests address. Slow probably.


  parent reply	other threads:[~2014-06-02 19:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-30  1:12 Implement PEBS virtualization for Silvermont Andi Kleen
2014-05-30  1:12 ` [PATCH 1/4] perf: Add PEBS virtualization enable " Andi Kleen
2014-05-30  1:12 ` [PATCH 2/4] perf: Allow guest PEBS for KVM owned counters Andi Kleen
2014-05-30  7:31   ` Peter Zijlstra
2014-05-30 16:03     ` Andi Kleen
2014-05-30 16:17       ` Peter Zijlstra
2014-05-30  1:12 ` [PATCH 3/4] perf: Handle guest PEBS events with a fake event Andi Kleen
2014-05-30  7:34   ` Peter Zijlstra
2014-05-30 16:29     ` Andi Kleen
2014-05-30  1:12 ` [PATCH 4/4] kvm: Implement PEBS virtualization Andi Kleen
2014-05-30  8:21   ` Gleb Natapov
2014-05-30 16:24     ` Andi Kleen
2014-06-02 16:45       ` Gleb Natapov
2014-06-02 16:52         ` Andi Kleen
2014-06-02 19:09         ` Marcelo Tosatti [this message]
2014-06-02 19:05   ` Eric Northup
2014-06-02 19:57     ` Andi Kleen
2014-06-19 14:39       ` Paolo Bonzini
2014-06-10 18:04   ` Marcelo Tosatti
2014-06-10 19:22     ` Andi Kleen
2014-06-10 21:06       ` Marcelo Tosatti
2014-06-19 14:42         ` Paolo Bonzini
2014-06-19 17:33           ` Andi Kleen
2014-06-19 20:33             ` Paolo Bonzini
2014-06-22 13:57   ` Avi Kivity
2014-06-22 19:02     ` Andi Kleen
2014-06-24 16:45       ` Marcelo Tosatti
2014-06-25  7:04         ` Avi Kivity
2014-05-30  7:39 ` Implement PEBS virtualization for Silvermont Peter Zijlstra

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=20140602190907.GA7590@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=gleb@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.