From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: agraf@suse.de, benh@kernel.crashing.org,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH 2/6] KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect
Date: Wed, 02 Jul 2014 17:42:25 +0530 [thread overview]
Message-ID: <87tx70m02e.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140702045002.GC16865@drongo>
Paul Mackerras <paulus@samba.org> writes:
> On Sun, Jun 29, 2014 at 04:47:31PM +0530, Aneesh Kumar K.V wrote:
>> This makes it consistent with h_enter where we clear the key
>> bits. We also want to use virtual page class key protection mechanism
>> for indicating host page fault. For that we will be using key class
>> index 30 and 31. So prevent the guest from updating key bits until
>> we add proper support for virtual page class protection mechanism for
>> the guest. This will not have any impact for PAPR linux guest because
>> Linux guest currently don't use virtual page class key protection model
>
> As things stand, without this patch series, we do actually have
> everything we need in the kernel for guests to use virtual page class
> keys. Arguably we should have a capability to tell userspace how many
> storage keys the guest can use, but that's the only missing piece as
> far as I can see.
yes.
>
> If we add such a capability, I can't see any reason why we should need
> to disable guest use of storage keys in this patchset.
With this patchset, we would need additonal changes to find out whether the key
fault happened because of the guest's usage of the key. I was planning to do
that as an add-on series to keep the changes in this minimal. Also since
linux didn't use keys i was not sure whether guest support of keys is an
important item.
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 2/6] KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect
Date: Wed, 02 Jul 2014 17:42:25 +0530 [thread overview]
Message-ID: <87tx70m02e.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140702045002.GC16865@drongo>
Paul Mackerras <paulus@samba.org> writes:
> On Sun, Jun 29, 2014 at 04:47:31PM +0530, Aneesh Kumar K.V wrote:
>> This makes it consistent with h_enter where we clear the key
>> bits. We also want to use virtual page class key protection mechanism
>> for indicating host page fault. For that we will be using key class
>> index 30 and 31. So prevent the guest from updating key bits until
>> we add proper support for virtual page class protection mechanism for
>> the guest. This will not have any impact for PAPR linux guest because
>> Linux guest currently don't use virtual page class key protection model
>
> As things stand, without this patch series, we do actually have
> everything we need in the kernel for guests to use virtual page class
> keys. Arguably we should have a capability to tell userspace how many
> storage keys the guest can use, but that's the only missing piece as
> far as I can see.
yes.
>
> If we add such a capability, I can't see any reason why we should need
> to disable guest use of storage keys in this patchset.
With this patchset, we would need additonal changes to find out whether the key
fault happened because of the guest's usage of the key. I was planning to do
that as an add-on series to keep the changes in this minimal. Also since
linux didn't use keys i was not sure whether guest support of keys is an
important item.
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: agraf@suse.de, benh@kernel.crashing.org,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH 2/6] KVM: PPC: BOOK3S: HV: Deny virtual page class key update via h_protect
Date: Wed, 02 Jul 2014 12:24:25 +0000 [thread overview]
Message-ID: <87tx70m02e.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140702045002.GC16865@drongo>
Paul Mackerras <paulus@samba.org> writes:
> On Sun, Jun 29, 2014 at 04:47:31PM +0530, Aneesh Kumar K.V wrote:
>> This makes it consistent with h_enter where we clear the key
>> bits. We also want to use virtual page class key protection mechanism
>> for indicating host page fault. For that we will be using key class
>> index 30 and 31. So prevent the guest from updating key bits until
>> we add proper support for virtual page class protection mechanism for
>> the guest. This will not have any impact for PAPR linux guest because
>> Linux guest currently don't use virtual page class key protection model
>
> As things stand, without this patch series, we do actually have
> everything we need in the kernel for guests to use virtual page class
> keys. Arguably we should have a capability to tell userspace how many
> storage keys the guest can use, but that's the only missing piece as
> far as I can see.
yes.
>
> If we add such a capability, I can't see any reason why we should need
> to disable guest use of storage keys in this patchset.
With this patchset, we would need additonal changes to find out whether the key
fault happened because of the guest's usage of the key. I was planning to do
that as an add-on series to keep the changes in this minimal. Also since
linux didn't use keys i was not sure whether guest support of keys is an
important item.
-aneesh
next prev parent reply other threads:[~2014-07-02 12:12 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 [this message]
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 ` [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 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=87tx70m02e.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=benh@kernel.crashing.org \
--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.