From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: agraf@suse.de, paulus@samba.org, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 0/6] Use virtual page class key protection mechanism for speeding up guest page fault
Date: Sun, 29 Jun 2014 21:26:06 +1000 [thread overview]
Message-ID: <1404041166.31323.2.camel@pasglop> (raw)
In-Reply-To: <1404040655-12076-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Sun, 2014-06-29 at 16:47 +0530, Aneesh Kumar K.V wrote:
> To achieve the above we use virtual page calss protection mechanism for
> covering (2) and (3). For both the above case we mark the hpte
> valid, but associate the page with virtual page class index 30 and 31.
> The authority mask register is configured such that class index 30 and 31
> will have read/write denied. The above change results in a key fault
> for (2) and (3). This allows us to forward a NO_HPTE fault directly to guest
> without doing the expensive hash pagetable lookup.
So we have a measurable performance benefit (about half a second out of
8) but you didn't explain the drawback here which is to essentially make
it impossible for guests to exploit virtual page class keys, or did you
find a way to still make that possible ?
As it-is, it's not a huge issue for Linux but we might have to care with
other OSes that do care...
Do we have a way in PAPR to signify to the guest that the keys are not
available ?
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, paulus@samba.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 0/6] Use virtual page class key protection mechanism for speeding up guest page fault
Date: Sun, 29 Jun 2014 21:26:06 +1000 [thread overview]
Message-ID: <1404041166.31323.2.camel@pasglop> (raw)
In-Reply-To: <1404040655-12076-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Sun, 2014-06-29 at 16:47 +0530, Aneesh Kumar K.V wrote:
> To achieve the above we use virtual page calss protection mechanism for
> covering (2) and (3). For both the above case we mark the hpte
> valid, but associate the page with virtual page class index 30 and 31.
> The authority mask register is configured such that class index 30 and 31
> will have read/write denied. The above change results in a key fault
> for (2) and (3). This allows us to forward a NO_HPTE fault directly to guest
> without doing the expensive hash pagetable lookup.
So we have a measurable performance benefit (about half a second out of
8) but you didn't explain the drawback here which is to essentially make
it impossible for guests to exploit virtual page class keys, or did you
find a way to still make that possible ?
As it-is, it's not a huge issue for Linux but we might have to care with
other OSes that do care...
Do we have a way in PAPR to signify to the guest that the keys are not
available ?
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: agraf@suse.de, paulus@samba.org, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 0/6] Use virtual page class key protection mechanism for speeding up guest page fault
Date: Sun, 29 Jun 2014 11:26:06 +0000 [thread overview]
Message-ID: <1404041166.31323.2.camel@pasglop> (raw)
In-Reply-To: <1404040655-12076-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Sun, 2014-06-29 at 16:47 +0530, Aneesh Kumar K.V wrote:
> To achieve the above we use virtual page calss protection mechanism for
> covering (2) and (3). For both the above case we mark the hpte
> valid, but associate the page with virtual page class index 30 and 31.
> The authority mask register is configured such that class index 30 and 31
> will have read/write denied. The above change results in a key fault
> for (2) and (3). This allows us to forward a NO_HPTE fault directly to guest
> without doing the expensive hash pagetable lookup.
So we have a measurable performance benefit (about half a second out of
8) but you didn't explain the drawback here which is to essentially make
it impossible for guests to exploit virtual page class keys, or did you
find a way to still make that possible ?
As it-is, it's not a huge issue for Linux but we might have to care with
other OSes that do care...
Do we have a way in PAPR to signify to the guest that the keys are not
available ?
Cheers,
Ben.
next prev parent reply other threads:[~2014-06-29 11:26 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-29 11:17 [PATCH 0/6] Use virtual page class key protection mechanism for speeding up guest page fault Aneesh Kumar K.V
2014-06-29 11:29 ` Aneesh Kumar K.V
2014-06-29 11:17 ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 1/6] KVM: PPC: BOOK3S: HV: Clear hash pte bits from do_h_enter callers Aneesh Kumar K.V
2014-06-29 11:29 ` Aneesh Kumar K.V
2014-06-29 11:17 ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH] KVM: PPC: BOOK3S: HV: Update compute_tlbie_rb to handle 16MB base page Aneesh Kumar K.V
2014-06-29 11:29 ` Aneesh Kumar K.V
2014-06-29 11:17 ` Aneesh Kumar K.V
2014-07-02 4:00 ` Paul Mackerras
2014-07-02 4:00 ` Paul Mackerras
2014-07-02 4:00 ` Paul Mackerras
2014-06-29 11:17 ` [PATCH 2/6] KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect Aneesh Kumar K.V
2014-06-29 11:29 ` Aneesh Kumar K.V
2014-06-29 11:17 ` Aneesh Kumar K.V
2014-07-02 4:50 ` Paul Mackerras
2014-07-02 4:50 ` Paul Mackerras
2014-07-02 4:50 ` Paul Mackerras
2014-07-02 12:12 ` Aneesh Kumar K.V
2014-07-02 12:24 ` Aneesh Kumar K.V
2014-07-02 12:12 ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 3/6] KVM: PPC: BOOK3S: HV: Remove dead code Aneesh Kumar K.V
2014-06-29 11:29 ` Aneesh Kumar K.V
2014-06-29 11:17 ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 4/6] KVM: PPC: BOOK3S: HV: Use new functions for mapping/unmapping hpte in host Aneesh Kumar K.V
2014-06-29 11:29 ` Aneesh Kumar K.V
2014-06-29 11:17 ` Aneesh Kumar K.V
2014-07-02 4:28 ` Paul Mackerras
2014-07-02 4:28 ` Paul Mackerras
2014-07-02 4:28 ` Paul Mackerras
2014-07-02 11:49 ` Aneesh Kumar K.V
2014-07-02 11:50 ` Aneesh Kumar K.V
2014-07-02 11:49 ` Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte update Aneesh Kumar K.V
2014-06-29 11:29 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte updat Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte update Aneesh Kumar K.V
2014-07-02 5:41 ` Paul Mackerras
2014-07-02 5:41 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte u Paul Mackerras
2014-07-02 5:41 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte update Paul Mackerras
2014-07-02 11:57 ` Aneesh Kumar K.V
2014-07-02 11:57 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte u Aneesh Kumar K.V
2014-07-02 11:57 ` [PATCH 5/6] KVM: PPC: BOOK3S: Use hpte_update_in_progress to track invalid hpte during an hpte update Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 6/6] KVM: PPC: BOOK3S: HV: Use virtual page class protection mechanism for host fault and mmio Aneesh Kumar K.V
2014-06-29 11:29 ` [PATCH 6/6] KVM: PPC: BOOK3S: HV: Use virtual page class protection mechanism for host fault and mmi Aneesh Kumar K.V
2014-06-29 11:17 ` [PATCH 6/6] KVM: PPC: BOOK3S: HV: Use virtual page class protection mechanism for host fault and mmio Aneesh Kumar K.V
2014-06-29 11:26 ` Benjamin Herrenschmidt [this message]
2014-06-29 11:26 ` [PATCH 0/6] Use virtual page class key protection mechanism for speeding up guest page fault Benjamin Herrenschmidt
2014-06-29 11:26 ` Benjamin Herrenschmidt
2014-06-29 16:57 ` Aneesh Kumar K.V
2014-06-29 16:57 ` Aneesh Kumar K.V
2014-06-29 16:57 ` Aneesh Kumar K.V
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=1404041166.31323.2.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.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.