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.
>
> 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().
>
> > With EPT it is less likely to happen (but still possible IIRC depending on memory
> > pressure and how much memory shadow paging code is allowed to use), without EPT
> > it will happen for sure.
>
> Don't care about the non EPT case, this is white listed only for EPT supporting
> CPUs.
User may still disable EPT during module load, so pebs should be dropped
from a guest's cpuid in this case.
>
> > There is nothing, as far as I can see, that says what will happen if the
> > condition is not met. I always interpreted it as undefined behaviour so
> > anything can happen including CPU dies completely. You are saying above
> > on one hand that CPU cannot handle any kinds of faults during write to
> > DS area, but on the other hand a guest could only crash itself. Is this
> > architecturally guarantied?
>
> You essentially would get random page faults, and the PEBS event will
> be cancelled. No hangs.
Is this a guest who will get those random page faults or a host?
>
> It's not architecturally guaranteed, but we white list anyways so
> we only care about the white listed CPUs at this point. For them
> I have confirmation that it works.
>
> -Andi
--
Gleb.
BTW I found some more problems in the v1 version.
> > > With EPT it is less likely to happen (but still possible IIRC depending on memory
> > > pressure and how much memory shadow paging code is allowed to use), without EPT
> > > it will happen for sure.
> >
> > Don't care about the non EPT case, this is white listed only for EPT supporting
> > CPUs.
> User may still disable EPT during module load, so pebs should be dropped
> from a guest's cpuid in this case.
Ok.
>
> >
> > > There is nothing, as far as I can see, that says what will happen if the
> > > condition is not met. I always interpreted it as undefined behaviour so
> > > anything can happen including CPU dies completely. You are saying above
> > > on one hand that CPU cannot handle any kinds of faults during write to
> > > DS area, but on the other hand a guest could only crash itself. Is this
> > > architecturally guarantied?
> >
> > You essentially would get random page faults, and the PEBS event will
> > be cancelled. No hangs.
> Is this a guest who will get those random page faults or a host?
The guest (on the white listed CPU models)
-Andi
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.