Re: [PATCH v2] KVM: arm64: Allow to limit number of PMU counters

2020-09-08 Thread Andrew Jones
On Tue, Sep 08, 2020 at 10:57:30PM +0200, Alexander Graf wrote: > We currently pass through the number of PMU counters that we have available > in hardware to guests. So if my host supports 10 concurrently active PMU > counters, my guest will be able to spawn 10 counters as well. > > This is undes

Re: [PATCH stable 4.19 v2 0/2] arm64: entry: Place an SB sequence following an ERET instruction

2020-09-08 Thread Florian Fainelli
On 8/24/2020 11:35 AM, Florian Fainelli wrote: Changes in v2: - included missing preliminary patch to define the SB barrier instruction Will Deacon (2): arm64: Add support for SB barrier and patch in over DSB; ISB sequences arm64: entry: Place an SB sequence following an ERET instructi

Re: [PATCH v4 16/21] KVM: arm64: Add support for relaxing stage-2 perms in generic page-table code

2020-09-08 Thread Alexandru Elisei
Hi Will, Minor nitpick below. On 9/7/20 4:23 PM, Will Deacon wrote: > Add support for relaxing the permissions of a stage-2 mapping (i.e. > adding additional permissions) to the generic page-table code. > > Cc: Marc Zyngier > Cc: Quentin Perret > Reviewed-by: Gavin Shan > Signed-off-by: Will D

Re: [PATCH v4 11/21] KVM: arm64: Convert page-aging and access faults to generic page-table API

2020-09-08 Thread Alexandru Elisei
Hi Will, On 9/7/20 4:23 PM, Will Deacon wrote: > Convert the page-aging functions and access fault handler to use the > generic page-table code instead of walking the page-table directly. > > Cc: Marc Zyngier > Cc: Quentin Perret > Reviewed-by: Gavin Shan > Signed-off-by: Will Deacon > --- >

Re: [PATCH v4 10/21] KVM: arm64: Add support for stage-2 page-aging in generic page-table

2020-09-08 Thread Alexandru Elisei
Hi Will, The patch looks good to me, I have a question below. On 9/7/20 4:23 PM, Will Deacon wrote: > Add stage-2 mkyoung(), mkold() and is_young() operations to the generic > page-table code. > > Cc: Marc Zyngier > Cc: Quentin Perret > Reviewed-by: Gavin Shan > Signed-off-by: Will Deacon > -

Re: [PATCH v3 16/18] KVM: arm64: nVHE: Migrate hyp interface to SMCCC

2020-09-08 Thread Andrew Scull
On Mon, Sep 07, 2020 at 03:20:07PM +0100, Marc Zyngier wrote: > On Thu, 03 Sep 2020 14:53:05 +0100, > Andrew Scull wrote: > > > > Rather than passing arbitrary function pointers to run at hyp, define > > and equivalent set of SMCCC functions. > > > > Since the SMCCC functions are strongly tied t

Re: [PATCH v3 14/18] smccc: Cast arguments to unsigned long

2020-09-08 Thread Andrew Scull
On Mon, Sep 07, 2020 at 02:33:17PM +0100, Marc Zyngier wrote: > On Thu, 03 Sep 2020 14:53:03 +0100, > Andrew Scull wrote: > > > > To avoid warning about implicit casting, make the casting explicit. This > > allows, for example, pointers to be used as arguments as are used in the > > KVM hyp inter

Re: [PATCH v3 08/18] KVM: arm64: Introduce hyp context

2020-09-08 Thread Andrew Scull
On Mon, Sep 07, 2020 at 02:29:11PM +0100, Marc Zyngier wrote: > On Thu, 03 Sep 2020 14:52:57 +0100, > Andrew Scull wrote: > > > > During __guest_enter, save and restore from a new hyp context rather > > than the host context. This is preparation for separation of the hyp and > > host context in n

Re: [PATCH v3 12/18] KVM: arm64: nVHE: Switch to hyp context for EL2

2020-09-08 Thread Andrew Scull
On Mon, Sep 07, 2020 at 02:02:54PM +0100, Marc Zyngier wrote: > Hi Andrew, > > On Thu, 03 Sep 2020 14:53:01 +0100, > Andrew Scull wrote: > > > > Save and restore the host context when switching to and from hyp. This > > gives hyp its own context that the host will not see as a step towards a > >

Re: [PATCH v3 06/18] KVM: arm64: nVHE: Use separate vector for the host

2020-09-08 Thread Andrew Scull
On Mon, Sep 07, 2020 at 12:38:46PM +0100, Marc Zyngier wrote: > Hi Andrew, > > On Thu, 03 Sep 2020 14:52:55 +0100, > Andrew Scull wrote: > > > > The host is treated differently from the guests when an exception is > > taken so introduce a separate vector that is specialized for the host. > > Thi

Re: [PATCH v3 04/18] KVM: arm64: Restrict symbol aliasing to outside nVHE

2020-09-08 Thread Andrew Scull
On Mon, Sep 07, 2020 at 11:38:38AM +0100, Marc Zyngier wrote: > Hi Andrew, > > On Thu, 03 Sep 2020 14:52:53 +0100, > Andrew Scull wrote: > > > > nVHE symbols are prefixed but this is sometimes hidden from the host by > > aliasing the non-prefixed symbol to the prefixed version with a macro. > >

Re: [PATCH v3 09/21] KVM: arm64: Convert unmap_stage2_range() to generic page-table API

2020-09-08 Thread Alexandru Elisei
Hi Will, On 9/3/20 6:57 PM, Will Deacon wrote: > On Wed, Sep 02, 2020 at 05:23:08PM +0100, Alexandru Elisei wrote: >> On 8/25/20 10:39 AM, Will Deacon wrote: >>> Convert unmap_stage2_range() to use kvm_pgtable_stage2_unmap() instead >>> of walking the page-table directly. >>> >>> Cc: Marc Zyngier

Re: [PATCH 2/2] KVM: arm64: Try PMD block mappings if PUD mappings are not supported

2020-09-08 Thread Marc Zyngier
On 2020-09-08 13:23, Alexandru Elisei wrote: Hi Marc, On 9/4/20 10:58 AM, Marc Zyngier wrote: Hi Alex, On Tue, 01 Sep 2020 14:33:57 +0100, Alexandru Elisei wrote: When userspace uses hugetlbfs for the VM memory, user_mem_abort() tries to use the same block size to map the faulting IPA in sta

Re: [PATCH 2/2] KVM: arm64: Try PMD block mappings if PUD mappings are not supported

2020-09-08 Thread Alexandru Elisei
Hi Marc, On 9/4/20 10:58 AM, Marc Zyngier wrote: > Hi Alex, > > On Tue, 01 Sep 2020 14:33:57 +0100, > Alexandru Elisei wrote: >> When userspace uses hugetlbfs for the VM memory, user_mem_abort() tries to >> use the same block size to map the faulting IPA in stage 2. If stage 2 >> cannot use the s

Re: [PATCH v4 19/21] KVM: arm64: Remove unused page-table code

2020-09-08 Thread Marc Zyngier
Hi Will, On 2020-09-07 16:23, Will Deacon wrote: Now that KVM is using the generic page-table code to manage the guest stage-2 page-tables, we can remove a bunch of unused macros, #defines and static inline functions from the old implementation. Cc: Marc Zyngier Cc: Quentin Perret Reviewed-by

Re: [PATCH v3 5/5] KVM: arm64: Document PMU filtering API

2020-09-08 Thread Andrew Jones
On Tue, Sep 08, 2020 at 08:58:30AM +0100, Marc Zyngier wrote: > Add a small blurb describing how the event filtering API gets used. > > Signed-off-by: Marc Zyngier > --- > Documentation/virt/kvm/devices/vcpu.rst | 46 + > 1 file changed, 46 insertions(+) > > diff --git a

Re: [PATCH v3 3/5] KVM: arm64: Add PMU event filtering infrastructure

2020-09-08 Thread Andrew Jones
On Tue, Sep 08, 2020 at 08:58:28AM +0100, Marc Zyngier wrote: > It can be desirable to expose a PMU to a guest, and yet not want the > guest to be able to count some of the implemented events (because this > would give information on shared resources, for example. > > For this, let's extend the PM

Re: [PATCH v3 1/5] KVM: arm64: Refactor PMU attribute error handling

2020-09-08 Thread Marc Zyngier
Hi Andrew, On 2020-09-08 10:53, Andrew Jones wrote: Hi Marc, On Tue, Sep 08, 2020 at 08:58:26AM +0100, Marc Zyngier wrote: The PMU emulation error handling is pretty messy when dealing with attributes. Let's refactor it so that we have less duplication, and that it is easy to extend later on.

Re: [PATCH v3 2/5] KVM: arm64: Use event mask matching architecture revision

2020-09-08 Thread Andrew Jones
On Tue, Sep 08, 2020 at 08:58:27AM +0100, Marc Zyngier wrote: > The PMU code suffers from a small defect where we assume that the event > number provided by the guest is always 16 bit wide, even if the CPU only > implements the ARMv8.0 architecture. This isn't really problematic in > the sense that

Re: [PATCH v3 1/5] KVM: arm64: Refactor PMU attribute error handling

2020-09-08 Thread Andrew Jones
Hi Marc, On Tue, Sep 08, 2020 at 08:58:26AM +0100, Marc Zyngier wrote: > The PMU emulation error handling is pretty messy when dealing with > attributes. Let's refactor it so that we have less duplication, > and that it is easy to extend later on. > > A functional change is that kvm_arm_pmu_v3_in

[PATCH v3 1/5] KVM: arm64: Refactor PMU attribute error handling

2020-09-08 Thread Marc Zyngier
The PMU emulation error handling is pretty messy when dealing with attributes. Let's refactor it so that we have less duplication, and that it is easy to extend later on. A functional change is that kvm_arm_pmu_v3_init() used to return -ENXIO when the PMU feature wasn't set. The error is now repor

[PATCH v3 0/5] KVM: arm64: Filtering PMU events

2020-09-08 Thread Marc Zyngier
It is at times necessary to prevent a guest from being able to sample certain events if multiple CPUs share resources such as a cache level. In this case, it would be interesting if the VMM could simply prevent certain events from being counted instead of hiding the PMU. Given that most events are

[PATCH v3 3/5] KVM: arm64: Add PMU event filtering infrastructure

2020-09-08 Thread Marc Zyngier
It can be desirable to expose a PMU to a guest, and yet not want the guest to be able to count some of the implemented events (because this would give information on shared resources, for example. For this, let's extend the PMUv3 device API, and offer a way to setup a bitmap of the allowed events

[PATCH v3 5/5] KVM: arm64: Document PMU filtering API

2020-09-08 Thread Marc Zyngier
Add a small blurb describing how the event filtering API gets used. Signed-off-by: Marc Zyngier --- Documentation/virt/kvm/devices/vcpu.rst | 46 + 1 file changed, 46 insertions(+) diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcp

[PATCH v3 4/5] KVM: arm64: Mask out filtered events in PCMEID{0, 1}_EL1

2020-09-08 Thread Marc Zyngier
As we can now hide events from the guest, let's also adjust its view of PCMEID{0,1}_EL1 so that it can figure out why some common events are not counting as they should. The astute user can still look into the TRM for their CPU and find out they've been cheated, though. Nobody's perfect. Signed-o

[PATCH v3 2/5] KVM: arm64: Use event mask matching architecture revision

2020-09-08 Thread Marc Zyngier
The PMU code suffers from a small defect where we assume that the event number provided by the guest is always 16 bit wide, even if the CPU only implements the ARMv8.0 architecture. This isn't really problematic in the sense that the event number ends up in a system register, cropping it to the rig