Hi James,
On 21/05/2019 18:25, James Morse wrote:
> KVM's pmu.c contains the __hyp_text needed to switch the pmu registers
> between host and guest. Because this isn't covered by the 'hyp' Makefile,
> it can be built with kasan and friends when these are enabled in Kconfig.
>
> When starting a gu
KVM has helpers to handle the condition codes of trapped aarch32
instructions. These are marked __hyp_text and used from HYP, but they
aren't built by the 'hyp' Makefile, which has all the runes to avoid ASAN
and KCOV instrumentation, used when debugging.
Move this code to a new hyp/aarch32.c to a
KVM's pmu.c contains the __hyp_text needed to switch the pmu registers
between host and guest. Because this isn't covered by the 'hyp' Makefile,
it can be built with kasan and friends when these are enabled in Kconfig.
When starting a guest, this results in:
| Kernel panic - not syncing: HYP panic
The fancy new pmu code added its __hyp_text code in part of the tree that
doesn't get covered by the no-asan/no-kcov kconfig decorations.
This shows up as a hyp-panic on v8.0 hardware when the host kernel is
built with debug options like kasan.
This same bug has been living happily in the aarch32
When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
the kernel may be able to use FPSIMD/SVE. This is for instance the case
for crypto code.
Any use of FPSIMD/SVE in the kernel are clearly marked by using the
function kernel_neon_{begin, end}. Furthermore, this can only be used
Hi all,
This patch series keeps softirqs enabled while touching FPSIMD/SVE state.
For more details on the impact see patch #3.
This patch series has been benchmarked on Linux 5.1-rc4 with defconfig.
On Juno2:
* hackbench 100 process 1000 (10 times)
* .7% quicker
On ThunderX 2:
* hac
The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is
the KVM FPSIMD code.
A following patch will introduce a mechanism to acquire owernship of the
FPSIMD/SVE context for performing context management operations. Rather
than having to export the new helpers to get/put the context
The function sve_flush_cpu_state() has been removed in commit 21cdd7fd76e3
("KVM: arm64: Remove eager host SVE state saving").
So remove the associated prototype in asm/fpsimd.h.
Signed-off-by: Julien Grall
Reviewed-by: Dave Martin
---
Changes in v3:
- Add Dave's reviewed-by
Hi Andrew,
On 05/21/2019 04:52 PM, Andrew Murray wrote:
> ARMv8 provides support for chained PMU counters, where an event type
> of 0x001E is set for odd-numbered counters, the event counter will
> increment by one for each overflow of the preceding even-numbered
> counter. Let's emulate this in K
On Sun, May 19, 2019 at 06:05:59PM +0800, Xiang Zheng wrote:
> Guest will adjust the sample period and set PMU counter value when
> it takes a long time to handle the PMU interrupts.
>
> However, we don't have a corresponding change on the virtual PMU
> which is emulated via a perf event. It could
On 21/05/2019 16:52, Andrew Murray wrote:
> ARMv8 provides support for chained PMU counters, where an event type
> of 0x001E is set for odd-numbered counters, the event counter will
> increment by one for each overflow of the preceding even-numbered
> counter. Let's emulate this in KVM by creating
On 21/05/2019 16:52, Andrew Murray wrote:
The ARMv8 Performance Monitors Extension includes an architectural
event type named CHAIN which allows for chaining counters together.
Let's extract the test for this event into a header file such that
other users, such as KVM (for PMU emulation) can
The perf event sample_period is currently set based upon the current
counter value, when PMXEVTYPER is written to and the perf event is created.
However the user may choose to write the type before the counter value in
which case sample_period will be set incorrectly. Let's instead decouple
event c
ARMv8 provides support for chained PMU counters, where an event type
of 0x001E is set for odd-numbered counters, the event counter will
increment by one for each overflow of the preceding even-numbered
counter. Let's emulate this in KVM by creating a 64 bit perf counter
when a user chains two emula
The ARMv8 Performance Monitors Extension includes an architectural
event type named CHAIN which allows for chaining counters together.
Let's extract the test for this event into a header file such that
other users, such as KVM (for PMU emulation) can make use of.
Signed-off-by: Andrew Murray
---
ARMv8 provides support for chained PMU counters, where an event type
of 0x001E is set for odd-numbered counters, the event counter will
increment by one for each overflow of the preceding even-numbered
counter. Let's emulate this in KVM by creating a 64 bit perf counter
when a user chains two emula
Let's reduce code duplication by extracting common code to its own
function.
Signed-off-by: Andrew Murray
Reviewed-by: Suzuki K Poulose
---
virt/kvm/arm/pmu.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu
The kvm_pmu_{enable/disable}_counter functions can enabled/disable
multiple counters at once as they operate on a bitmask. Let's
make this clearer by renaming the function.
Suggested-by: Suzuki K Poulose
Signed-off-by: Andrew Murray
Reviewed-by: Julien Thierry
Reviewed-by: Suzuki K Poulose
---
On Wed, May 15, 2019 at 09:25:46AM +0100, Julien Thierry wrote:
> Hi Andrew,
>
> It might be just my personal taste, but I'm not entirely sold on the
> introduction of get/set_perf_event. Having both this and the concept of
> getting the "canonical" pmc feels a bit redundant, or that we're
> hidin
I no longer have time to actively review patches and manage the tree and
it's time to make that official.
Huge thanks to the incredible Linux community and all the contributors
who have put up with me over the past years.
I also take this opportunity to remove the website link to the Columbia
web
20 matches
Mail list logo
