* Re: [PATCH 1/2] mm: move force_dma_unencrypted() to mem_encrypt.h
From: Christian Borntraeger @ 2020-02-20 17:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-s390, Janosch Frank, Michael S. Tsirkin, Jason Wang,
Cornelia Huck, Ram Pai, linux-kernel, virtualization, Halil Pasic,
iommu, David Gibson, Michael Mueller, Lendacky, Thomas,
Viktor Mihajlovski, Robin Murphy
In-Reply-To: <20200220163135.GA13192@lst.de>
On 20.02.20 17:31, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 05:23:20PM +0100, Christian Borntraeger wrote:
>> >From a users perspective it makes absolutely perfect sense to use the
>> bounce buffers when they are NEEDED.
>> Forcing the user to specify iommu_platform just because you need bounce buffers
>> really feels wrong. And obviously we have a severe performance issue
>> because of the indirections.
>
> The point is that the user should not have to specify iommu_platform.
I (and Halil) agree on that. From a user perspective we want to
have the right thing in the guest without any command option. The iommu_plaform
thing was indeed a first step to make things work.
I might mis-read Halils patch, but isnt one effect of this patch set
that things WILL work without iommu_platform?
> We need to make sure any new hypervisor (especially one that might require
> bounce buffering) always sets it, as was a rather bogus legacy hack
> that isn't extensibe for cases that for example require bounce buffering.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH 3/3] arm64: Ask the compiler to __always_inline functions used by KVM at HYP
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Suzuki K Poulose, James Morse,
Sami Tolvanen, Catalin Marinas, Will Deacon, Julien Thierry
In-Reply-To: <20200220165839.256881-1-james.morse@arm.com>
KVM uses some of the static-inline helpers like icache_is_vipt() from
its HYP code. This assumes the function is inlined so that the code is
mapped to EL2. The compiler may decide not to inline these, and the
out-of-line version may not be in the __hyp_text section.
Add the additional __always_ hint to these static-inlines that are used
by KVM.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/include/asm/cache.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 8 ++++----
arch/arm64/include/asm/io.h | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 806e9dc2a852..a4d1b5f771f6 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -69,7 +69,7 @@ static inline int icache_is_aliasing(void)
return test_bit(ICACHEF_ALIASING, &__icache_flags);
}
-static inline int icache_is_vpipt(void)
+static __always_inline int icache_is_vpipt(void)
{
return test_bit(ICACHEF_VPIPT, &__icache_flags);
}
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index 665c78e0665a..e6cca3d4acf7 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -145,7 +145,7 @@ extern void copy_to_user_page(struct vm_area_struct *, struct page *,
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
extern void flush_dcache_page(struct page *);
-static inline void __flush_icache_all(void)
+static __always_inline void __flush_icache_all(void)
{
if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
return;
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 42ce41eef274..2a746b99e937 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -435,13 +435,13 @@ cpuid_feature_extract_signed_field(u64 features, int field)
return cpuid_feature_extract_signed_field_width(features, field, 4);
}
-static inline unsigned int __attribute_const__
+static __always_inline unsigned int __attribute_const__
cpuid_feature_extract_unsigned_field_width(u64 features, int field, int width)
{
return (u64)(features << (64 - width - field)) >> (64 - width);
}
-static inline unsigned int __attribute_const__
+static __always_inline unsigned int __attribute_const__
cpuid_feature_extract_unsigned_field(u64 features, int field)
{
return cpuid_feature_extract_unsigned_field_width(features, field, 4);
@@ -564,7 +564,7 @@ static inline bool system_supports_mixed_endian(void)
return val == 0x1;
}
-static inline bool system_supports_fpsimd(void)
+static __always_inline bool system_supports_fpsimd(void)
{
return !cpus_have_const_cap(ARM64_HAS_NO_FPSIMD);
}
@@ -575,7 +575,7 @@ static inline bool system_uses_ttbr0_pan(void)
!cpus_have_const_cap(ARM64_HAS_PAN);
}
-static inline bool system_supports_sve(void)
+static __always_inline bool system_supports_sve(void)
{
return IS_ENABLED(CONFIG_ARM64_SVE) &&
cpus_have_const_cap(ARM64_SVE);
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 4e531f57147d..6facd1308e7c 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -34,7 +34,7 @@ static inline void __raw_writew(u16 val, volatile void __iomem *addr)
}
#define __raw_writel __raw_writel
-static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
{
asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
}
@@ -69,7 +69,7 @@ static inline u16 __raw_readw(const volatile void __iomem *addr)
}
#define __raw_readl __raw_readl
-static inline u32 __raw_readl(const volatile void __iomem *addr)
+static __always_inline u32 __raw_readl(const volatile void __iomem *addr)
{
u32 val;
asm volatile(ALTERNATIVE("ldr %w0, [%1]",
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Jason A. Donenfeld @ 2020-02-20 16:59 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CACT4Y+ZZM-nW--q6kzKpw4tJ+tmsS=SK13SChtD__r5-k5hH_Q@mail.gmail.com>
On Thu, Feb 20, 2020 at 5:45 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> If it's aimed only at, say, wireguard netlink interface, then it's not
> distracted by bugs in other parts. But as you add some ipv4/6 tcp/udp
> sockets, more netlink to change these net namespaces, namespaces
> related syscalls, packet injection, etc, in the end it covers quite a
> significant part of kernel. You know how fuzzing works, right. You
> really need to fix the current layer of bugs to get to the next one.
> And we accumulated 600+ open bugs. It still finds some new ones, but I
> guess these are really primitive ones (as compared to its full bug
> finding potential).
Yea, seems reasonable. I need to get a local syzkaller instance set up
for customization and then start patching the things that seem to be
standing in the way. Either way, so long as there isn't some
implementation issue or logical problem getting in the way of calling
that codepath, I'm satisfied in knowing that syzkaller will get there
eventually.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: syzkaller wireguard key situation [was: Re: [PATCH net-next v2] net: WireGuard secure network tunnel]
From: Jason A. Donenfeld @ 2020-02-20 16:59 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: netdev, syzbot, WireGuard mailing list
In-Reply-To: <CACT4Y+ZZM-nW--q6kzKpw4tJ+tmsS=SK13SChtD__r5-k5hH_Q@mail.gmail.com>
On Thu, Feb 20, 2020 at 5:45 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> If it's aimed only at, say, wireguard netlink interface, then it's not
> distracted by bugs in other parts. But as you add some ipv4/6 tcp/udp
> sockets, more netlink to change these net namespaces, namespaces
> related syscalls, packet injection, etc, in the end it covers quite a
> significant part of kernel. You know how fuzzing works, right. You
> really need to fix the current layer of bugs to get to the next one.
> And we accumulated 600+ open bugs. It still finds some new ones, but I
> guess these are really primitive ones (as compared to its full bug
> finding potential).
Yea, seems reasonable. I need to get a local syzkaller instance set up
for customization and then start patching the things that seem to be
standing in the way. Either way, so long as there isn't some
implementation issue or logical problem getting in the way of calling
that codepath, I'm satisfied in knowing that syzkaller will get there
eventually.
^ permalink raw reply
* [PATCH 2/3] KVM: arm64: define our own swab32() to avoid a uapi static inline
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Suzuki K Poulose, James Morse,
Sami Tolvanen, Catalin Marinas, Will Deacon, Julien Thierry
In-Reply-To: <20200220165839.256881-1-james.morse@arm.com>
KVM uses swab32() when mediating GIC MMIO accesses if the GICV is badly
aligned, and the host and guest differ in endianness.
arm64 doesn't provide a __arch_swab32(), so __fswab32() is always backed
by the macro implementation that the compiler reduces to a single
instruction. But the static-inline causes problems for KVM if the compiler
chooses not to inline this function, it may not be located in the
__hyp_text where __vgic_v2_perform_cpuif_access() needs it.
Create our own __kvm_swab32() macro that calls ___constant_swab32()
directly. This way we know it will always be inlined.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/include/asm/kvm_hyp.h | 7 +++++++
arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index a3a6a2ba9a63..fe57f60f06a8 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -47,6 +47,13 @@
#define read_sysreg_el2(r) read_sysreg_elx(r, _EL2, _EL1)
#define write_sysreg_el2(v,r) write_sysreg_elx(v, r, _EL2, _EL1)
+/*
+ * Without an __arch_swab32(), we fall back to ___constant_swab32(), but the
+ * static inline can allow the compiler to out-of-line this. KVM always wants
+ * the macro version as its always inlined.
+ */
+#define __kvm_swab32(x) ___constant_swab32(x)
+
int __vgic_v2_perform_cpuif_access(struct kvm_vcpu *vcpu);
void __vgic_v3_save_state(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c b/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
index 29ee1feba4eb..4f3a087e36d5 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
@@ -69,14 +69,14 @@ int __hyp_text __vgic_v2_perform_cpuif_access(struct kvm_vcpu *vcpu)
u32 data = vcpu_get_reg(vcpu, rd);
if (__is_be(vcpu)) {
/* guest pre-swabbed data, undo this for writel() */
- data = swab32(data);
+ data = __kvm_swab32(data);
}
writel_relaxed(data, addr);
} else {
u32 data = readl_relaxed(addr);
if (__is_be(vcpu)) {
/* guest expects swabbed data */
- data = swab32(data);
+ data = __kvm_swab32(data);
}
vcpu_set_reg(vcpu, rd, data);
}
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] KVM: arm64: Ask the compiler to __always_inline functions used at HYP
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Suzuki K Poulose, James Morse,
Sami Tolvanen, Catalin Marinas, Will Deacon, Julien Thierry
In-Reply-To: <20200220165839.256881-1-james.morse@arm.com>
On non VHE CPUs, KVM's __hyp_text contains code run at EL2 while the rest
of the kernel runs at EL1. This code lives in its own section with start
and end markers so we can map it to EL2.
The compiler may decide not to inline static-inline functions from the
header file. It may also decide not to put these out-of-line functions
in the same section, meaning they aren't mapped when called at EL2.
Clang-9 does exactly this with __kern_hyp_va() and a few others when
x18 is reserved for the shadow call stack. Add the additional __always_
hint to all the static-inlines that are called from a hyp file.
Signed-off-by: James Morse <james.morse@arm.com>
----
kvm_get_hyp_vector() pulls in all the regular per-cpu accessors
and this_cpu_has_cap(), fortunately its only called for VHE.
---
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/kvm_emulate.h | 48 ++++++++++++++--------------
arch/arm64/include/asm/kvm_mmu.h | 3 +-
arch/arm64/include/asm/virt.h | 2 +-
5 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
index 25fec4bde43a..a358e97572c1 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -32,7 +32,7 @@ static inline void gic_write_eoir(u32 irq)
isb();
}
-static inline void gic_write_dir(u32 irq)
+static __always_inline void gic_write_dir(u32 irq)
{
write_sysreg_s(irq, SYS_ICC_DIR_EL1);
isb();
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 92ef9539874a..42ce41eef274 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -581,7 +581,7 @@ static inline bool system_supports_sve(void)
cpus_have_const_cap(ARM64_SVE);
}
-static inline bool system_supports_cnp(void)
+static __always_inline bool system_supports_cnp(void)
{
return IS_ENABLED(CONFIG_ARM64_CNP) &&
cpus_have_const_cap(ARM64_HAS_CNP);
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 688c63412cc2..f658dda12364 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -36,7 +36,7 @@ void kvm_inject_undef32(struct kvm_vcpu *vcpu);
void kvm_inject_dabt32(struct kvm_vcpu *vcpu, unsigned long addr);
void kvm_inject_pabt32(struct kvm_vcpu *vcpu, unsigned long addr);
-static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
+static __always_inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
{
return !(vcpu->arch.hcr_el2 & HCR_RW);
}
@@ -127,7 +127,7 @@ static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
vcpu->arch.vsesr_el2 = vsesr;
}
-static inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
{
return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.pc;
}
@@ -153,17 +153,17 @@ static inline void vcpu_write_elr_el1(const struct kvm_vcpu *vcpu, unsigned long
*__vcpu_elr_el1(vcpu) = v;
}
-static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
{
return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.pstate;
}
-static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
+static __always_inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
{
return !!(*vcpu_cpsr(vcpu) & PSR_MODE32_BIT);
}
-static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
{
if (vcpu_mode_is_32bit(vcpu))
return kvm_condition_valid32(vcpu);
@@ -181,13 +181,13 @@ static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
* coming from a read of ESR_EL2. Otherwise, it may give the wrong result on
* AArch32 with banked registers.
*/
-static inline unsigned long vcpu_get_reg(const struct kvm_vcpu *vcpu,
+static __always_inline unsigned long vcpu_get_reg(const struct kvm_vcpu *vcpu,
u8 reg_num)
{
return (reg_num == 31) ? 0 : vcpu_gp_regs(vcpu)->regs.regs[reg_num];
}
-static inline void vcpu_set_reg(struct kvm_vcpu *vcpu, u8 reg_num,
+static __always_inline void vcpu_set_reg(struct kvm_vcpu *vcpu, u8 reg_num,
unsigned long val)
{
if (reg_num != 31)
@@ -264,12 +264,12 @@ static inline bool vcpu_mode_priv(const struct kvm_vcpu *vcpu)
return mode != PSR_MODE_EL0t;
}
-static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
+static __always_inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
{
return vcpu->arch.fault.esr_el2;
}
-static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
+static __always_inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
{
u32 esr = kvm_vcpu_get_hsr(vcpu);
@@ -279,12 +279,12 @@ static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
return -1;
}
-static inline unsigned long kvm_vcpu_get_hfar(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long kvm_vcpu_get_hfar(const struct kvm_vcpu *vcpu)
{
return vcpu->arch.fault.far_el2;
}
-static inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
+static __always_inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
{
return ((phys_addr_t)vcpu->arch.fault.hpfar_el2 & HPFAR_MASK) << 8;
}
@@ -299,7 +299,7 @@ static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
}
-static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_ISV);
}
@@ -319,17 +319,17 @@ static inline bool kvm_vcpu_dabt_issf(const struct kvm_vcpu *vcpu)
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SF);
}
-static inline int kvm_vcpu_dabt_get_rd(const struct kvm_vcpu *vcpu)
+static __always_inline int kvm_vcpu_dabt_get_rd(const struct kvm_vcpu *vcpu)
{
return (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SRT_MASK) >> ESR_ELx_SRT_SHIFT;
}
-static inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
}
-static inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WNR) ||
kvm_vcpu_dabt_iss1tw(vcpu); /* AF/DBM update */
@@ -340,18 +340,18 @@ static inline bool kvm_vcpu_dabt_is_cm(const struct kvm_vcpu *vcpu)
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
}
-static inline unsigned int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
{
return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
}
/* This one is not specific to Data Abort */
-static inline bool kvm_vcpu_trap_il_is32bit(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_trap_il_is32bit(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_IL);
}
-static inline u8 kvm_vcpu_trap_get_class(const struct kvm_vcpu *vcpu)
+static __always_inline u8 kvm_vcpu_trap_get_class(const struct kvm_vcpu *vcpu)
{
return ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
}
@@ -361,17 +361,17 @@ static inline bool kvm_vcpu_trap_is_iabt(const struct kvm_vcpu *vcpu)
return kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_IABT_LOW;
}
-static inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
+static __always_inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
{
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC;
}
-static inline u8 kvm_vcpu_trap_get_fault_type(const struct kvm_vcpu *vcpu)
+static __always_inline u8 kvm_vcpu_trap_get_fault_type(const struct kvm_vcpu *vcpu)
{
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC_TYPE;
}
-static inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
{
switch (kvm_vcpu_trap_get_fault(vcpu)) {
case FSC_SEA:
@@ -390,7 +390,7 @@ static inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
}
}
-static inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
+static __always_inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
{
u32 esr = kvm_vcpu_get_hsr(vcpu);
return ESR_ELx_SYS64_ISS_RT(esr);
@@ -504,7 +504,7 @@ static inline unsigned long vcpu_data_host_to_guest(struct kvm_vcpu *vcpu,
return data; /* Leave LE untouched */
}
-static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
+static __always_inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
{
if (vcpu_mode_is_32bit(vcpu))
kvm_skip_instr32(vcpu, is_wide_instr);
@@ -519,7 +519,7 @@ static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
* Skip an instruction which has been emulated at hyp while most guest sysregs
* are live.
*/
-static inline void __hyp_text __kvm_skip_instr(struct kvm_vcpu *vcpu)
+static __always_inline void __hyp_text __kvm_skip_instr(struct kvm_vcpu *vcpu)
{
*vcpu_pc(vcpu) = read_sysreg_el2(SYS_ELR);
vcpu->arch.ctxt.gp_regs.regs.pstate = read_sysreg_el2(SYS_SPSR);
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 53d846f1bfe7..785762860c63 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -93,7 +93,7 @@ void kvm_update_va_mask(struct alt_instr *alt,
__le32 *origptr, __le32 *updptr, int nr_inst);
void kvm_compute_layout(void);
-static inline unsigned long __kern_hyp_va(unsigned long v)
+static __always_inline unsigned long __kern_hyp_va(unsigned long v)
{
asm volatile(ALTERNATIVE_CB("and %0, %0, #1\n"
"ror %0, %0, #1\n"
@@ -473,6 +473,7 @@ static inline int kvm_write_guest_lock(struct kvm *kvm, gpa_t gpa,
extern void *__kvm_bp_vect_base;
extern int __kvm_harden_el2_vector_slot;
+/* This is only called on a VHE system */
static inline void *kvm_get_hyp_vector(void)
{
struct bp_hardening_data *data = arm64_get_bp_hardening_data();
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 0958ed6191aa..61fd26752adc 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -83,7 +83,7 @@ static inline bool is_kernel_in_hyp_mode(void)
return read_sysreg(CurrentEL) == CurrentEL_EL2;
}
-static inline bool has_vhe(void)
+static __always_inline bool has_vhe(void)
{
if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
return true;
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 2/2] RDMA/rw: map P2P memory correctly for signature operations
From: Max Gurtovoy @ 2020-02-20 16:57 UTC (permalink / raw)
To: Logan Gunthorpe, jgg, leon, linux-rdma; +Cc: israelr
In-Reply-To: <9e68c521-f083-c713-c19a-c08a0227c95e@deltatee.com>
On 2/20/2020 6:51 PM, Logan Gunthorpe wrote:
>
> On 2020-02-20 3:08 a.m., Max Gurtovoy wrote:
>> Since RDMA rw API support operations with P2P memory sg list, make sure
>> to map/unmap the scatter list for signature operation correctly.
> Does anyone actually use P2P pages with rdma_rw_ctx_signature_init()?
We're adding support for NVMf/target in these days.
Nevertheless, the RW API defined as an API that might use P2P pages.
>
> Logan
>
>> Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
>> ---
>> drivers/infiniband/core/rw.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c
>> index 69513b484507..6eba8453f206 100644
>> --- a/drivers/infiniband/core/rw.c
>> +++ b/drivers/infiniband/core/rw.c
>> @@ -392,13 +392,13 @@ int rdma_rw_ctx_signature_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
>> return -EINVAL;
>> }
>>
>> - ret = ib_dma_map_sg(dev, sg, sg_cnt, dir);
>> + ret = rdma_rw_map_sg(dev, sg, sg_cnt, dir);
>> if (!ret)
>> return -ENOMEM;
>> sg_cnt = ret;
>>
>> if (prot_sg_cnt) {
>> - ret = ib_dma_map_sg(dev, prot_sg, prot_sg_cnt, dir);
>> + ret = rdma_rw_map_sg(dev, prot_sg, prot_sg_cnt, dir);
>> if (!ret) {
>> ret = -ENOMEM;
>> goto out_unmap_sg;
>> @@ -467,9 +467,9 @@ int rdma_rw_ctx_signature_init(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
>> kfree(ctx->reg);
>> out_unmap_prot_sg:
>> if (prot_sg_cnt)
>> - ib_dma_unmap_sg(dev, prot_sg, prot_sg_cnt, dir);
>> + rdma_rw_unmap_sg(dev, prot_sg, prot_sg_cnt, dir);
>> out_unmap_sg:
>> - ib_dma_unmap_sg(dev, sg, sg_cnt, dir);
>> + rdma_rw_unmap_sg(dev, sg, sg_cnt, dir);
>> return ret;
>> }
>> EXPORT_SYMBOL(rdma_rw_ctx_signature_init);
>> @@ -629,9 +629,9 @@ void rdma_rw_ctx_destroy_signature(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
>> ib_mr_pool_put(qp, &qp->sig_mrs, ctx->reg->mr);
>> kfree(ctx->reg);
>>
>> - ib_dma_unmap_sg(qp->pd->device, sg, sg_cnt, dir);
>> if (prot_sg_cnt)
>> - ib_dma_unmap_sg(qp->pd->device, prot_sg, prot_sg_cnt, dir);
>> + rdma_rw_unmap_sg(qp->pd->device, prot_sg, prot_sg_cnt, dir);
>> + rdma_rw_unmap_sg(qp->pd->device, sg, sg_cnt, dir);
>> }
>> EXPORT_SYMBOL(rdma_rw_ctx_destroy_signature);
>>
>>
^ permalink raw reply
* [PATCH 3/3] arm64: Ask the compiler to __always_inline functions used by KVM at HYP
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Sami Tolvanen, Catalin Marinas,
Will Deacon
In-Reply-To: <20200220165839.256881-1-james.morse@arm.com>
KVM uses some of the static-inline helpers like icache_is_vipt() from
its HYP code. This assumes the function is inlined so that the code is
mapped to EL2. The compiler may decide not to inline these, and the
out-of-line version may not be in the __hyp_text section.
Add the additional __always_ hint to these static-inlines that are used
by KVM.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/include/asm/cache.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 8 ++++----
arch/arm64/include/asm/io.h | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h
index 806e9dc2a852..a4d1b5f771f6 100644
--- a/arch/arm64/include/asm/cache.h
+++ b/arch/arm64/include/asm/cache.h
@@ -69,7 +69,7 @@ static inline int icache_is_aliasing(void)
return test_bit(ICACHEF_ALIASING, &__icache_flags);
}
-static inline int icache_is_vpipt(void)
+static __always_inline int icache_is_vpipt(void)
{
return test_bit(ICACHEF_VPIPT, &__icache_flags);
}
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index 665c78e0665a..e6cca3d4acf7 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -145,7 +145,7 @@ extern void copy_to_user_page(struct vm_area_struct *, struct page *,
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
extern void flush_dcache_page(struct page *);
-static inline void __flush_icache_all(void)
+static __always_inline void __flush_icache_all(void)
{
if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC))
return;
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 42ce41eef274..2a746b99e937 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -435,13 +435,13 @@ cpuid_feature_extract_signed_field(u64 features, int field)
return cpuid_feature_extract_signed_field_width(features, field, 4);
}
-static inline unsigned int __attribute_const__
+static __always_inline unsigned int __attribute_const__
cpuid_feature_extract_unsigned_field_width(u64 features, int field, int width)
{
return (u64)(features << (64 - width - field)) >> (64 - width);
}
-static inline unsigned int __attribute_const__
+static __always_inline unsigned int __attribute_const__
cpuid_feature_extract_unsigned_field(u64 features, int field)
{
return cpuid_feature_extract_unsigned_field_width(features, field, 4);
@@ -564,7 +564,7 @@ static inline bool system_supports_mixed_endian(void)
return val == 0x1;
}
-static inline bool system_supports_fpsimd(void)
+static __always_inline bool system_supports_fpsimd(void)
{
return !cpus_have_const_cap(ARM64_HAS_NO_FPSIMD);
}
@@ -575,7 +575,7 @@ static inline bool system_uses_ttbr0_pan(void)
!cpus_have_const_cap(ARM64_HAS_PAN);
}
-static inline bool system_supports_sve(void)
+static __always_inline bool system_supports_sve(void)
{
return IS_ENABLED(CONFIG_ARM64_SVE) &&
cpus_have_const_cap(ARM64_SVE);
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 4e531f57147d..6facd1308e7c 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -34,7 +34,7 @@ static inline void __raw_writew(u16 val, volatile void __iomem *addr)
}
#define __raw_writel __raw_writel
-static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
{
asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
}
@@ -69,7 +69,7 @@ static inline u16 __raw_readw(const volatile void __iomem *addr)
}
#define __raw_readl __raw_readl
-static inline u32 __raw_readl(const volatile void __iomem *addr)
+static __always_inline u32 __raw_readl(const volatile void __iomem *addr)
{
u32 val;
asm volatile(ALTERNATIVE("ldr %w0, [%1]",
--
2.24.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH 2/3] KVM: arm64: define our own swab32() to avoid a uapi static inline
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Sami Tolvanen, Catalin Marinas,
Will Deacon
In-Reply-To: <20200220165839.256881-1-james.morse@arm.com>
KVM uses swab32() when mediating GIC MMIO accesses if the GICV is badly
aligned, and the host and guest differ in endianness.
arm64 doesn't provide a __arch_swab32(), so __fswab32() is always backed
by the macro implementation that the compiler reduces to a single
instruction. But the static-inline causes problems for KVM if the compiler
chooses not to inline this function, it may not be located in the
__hyp_text where __vgic_v2_perform_cpuif_access() needs it.
Create our own __kvm_swab32() macro that calls ___constant_swab32()
directly. This way we know it will always be inlined.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/include/asm/kvm_hyp.h | 7 +++++++
arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index a3a6a2ba9a63..fe57f60f06a8 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -47,6 +47,13 @@
#define read_sysreg_el2(r) read_sysreg_elx(r, _EL2, _EL1)
#define write_sysreg_el2(v,r) write_sysreg_elx(v, r, _EL2, _EL1)
+/*
+ * Without an __arch_swab32(), we fall back to ___constant_swab32(), but the
+ * static inline can allow the compiler to out-of-line this. KVM always wants
+ * the macro version as its always inlined.
+ */
+#define __kvm_swab32(x) ___constant_swab32(x)
+
int __vgic_v2_perform_cpuif_access(struct kvm_vcpu *vcpu);
void __vgic_v3_save_state(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c b/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
index 29ee1feba4eb..4f3a087e36d5 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c
@@ -69,14 +69,14 @@ int __hyp_text __vgic_v2_perform_cpuif_access(struct kvm_vcpu *vcpu)
u32 data = vcpu_get_reg(vcpu, rd);
if (__is_be(vcpu)) {
/* guest pre-swabbed data, undo this for writel() */
- data = swab32(data);
+ data = __kvm_swab32(data);
}
writel_relaxed(data, addr);
} else {
u32 data = readl_relaxed(addr);
if (__is_be(vcpu)) {
/* guest expects swabbed data */
- data = swab32(data);
+ data = __kvm_swab32(data);
}
vcpu_set_reg(vcpu, rd, data);
}
--
2.24.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH 1/3] KVM: arm64: Ask the compiler to __always_inline functions used at HYP
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Sami Tolvanen, Catalin Marinas,
Will Deacon
In-Reply-To: <20200220165839.256881-1-james.morse@arm.com>
On non VHE CPUs, KVM's __hyp_text contains code run at EL2 while the rest
of the kernel runs at EL1. This code lives in its own section with start
and end markers so we can map it to EL2.
The compiler may decide not to inline static-inline functions from the
header file. It may also decide not to put these out-of-line functions
in the same section, meaning they aren't mapped when called at EL2.
Clang-9 does exactly this with __kern_hyp_va() and a few others when
x18 is reserved for the shadow call stack. Add the additional __always_
hint to all the static-inlines that are called from a hyp file.
Signed-off-by: James Morse <james.morse@arm.com>
----
kvm_get_hyp_vector() pulls in all the regular per-cpu accessors
and this_cpu_has_cap(), fortunately its only called for VHE.
---
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/kvm_emulate.h | 48 ++++++++++++++--------------
arch/arm64/include/asm/kvm_mmu.h | 3 +-
arch/arm64/include/asm/virt.h | 2 +-
5 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
index 25fec4bde43a..a358e97572c1 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -32,7 +32,7 @@ static inline void gic_write_eoir(u32 irq)
isb();
}
-static inline void gic_write_dir(u32 irq)
+static __always_inline void gic_write_dir(u32 irq)
{
write_sysreg_s(irq, SYS_ICC_DIR_EL1);
isb();
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 92ef9539874a..42ce41eef274 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -581,7 +581,7 @@ static inline bool system_supports_sve(void)
cpus_have_const_cap(ARM64_SVE);
}
-static inline bool system_supports_cnp(void)
+static __always_inline bool system_supports_cnp(void)
{
return IS_ENABLED(CONFIG_ARM64_CNP) &&
cpus_have_const_cap(ARM64_HAS_CNP);
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 688c63412cc2..f658dda12364 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -36,7 +36,7 @@ void kvm_inject_undef32(struct kvm_vcpu *vcpu);
void kvm_inject_dabt32(struct kvm_vcpu *vcpu, unsigned long addr);
void kvm_inject_pabt32(struct kvm_vcpu *vcpu, unsigned long addr);
-static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
+static __always_inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
{
return !(vcpu->arch.hcr_el2 & HCR_RW);
}
@@ -127,7 +127,7 @@ static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
vcpu->arch.vsesr_el2 = vsesr;
}
-static inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long *vcpu_pc(const struct kvm_vcpu *vcpu)
{
return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.pc;
}
@@ -153,17 +153,17 @@ static inline void vcpu_write_elr_el1(const struct kvm_vcpu *vcpu, unsigned long
*__vcpu_elr_el1(vcpu) = v;
}
-static inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long *vcpu_cpsr(const struct kvm_vcpu *vcpu)
{
return (unsigned long *)&vcpu_gp_regs(vcpu)->regs.pstate;
}
-static inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
+static __always_inline bool vcpu_mode_is_32bit(const struct kvm_vcpu *vcpu)
{
return !!(*vcpu_cpsr(vcpu) & PSR_MODE32_BIT);
}
-static inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_condition_valid(const struct kvm_vcpu *vcpu)
{
if (vcpu_mode_is_32bit(vcpu))
return kvm_condition_valid32(vcpu);
@@ -181,13 +181,13 @@ static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
* coming from a read of ESR_EL2. Otherwise, it may give the wrong result on
* AArch32 with banked registers.
*/
-static inline unsigned long vcpu_get_reg(const struct kvm_vcpu *vcpu,
+static __always_inline unsigned long vcpu_get_reg(const struct kvm_vcpu *vcpu,
u8 reg_num)
{
return (reg_num == 31) ? 0 : vcpu_gp_regs(vcpu)->regs.regs[reg_num];
}
-static inline void vcpu_set_reg(struct kvm_vcpu *vcpu, u8 reg_num,
+static __always_inline void vcpu_set_reg(struct kvm_vcpu *vcpu, u8 reg_num,
unsigned long val)
{
if (reg_num != 31)
@@ -264,12 +264,12 @@ static inline bool vcpu_mode_priv(const struct kvm_vcpu *vcpu)
return mode != PSR_MODE_EL0t;
}
-static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
+static __always_inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu *vcpu)
{
return vcpu->arch.fault.esr_el2;
}
-static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
+static __always_inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
{
u32 esr = kvm_vcpu_get_hsr(vcpu);
@@ -279,12 +279,12 @@ static inline int kvm_vcpu_get_condition(const struct kvm_vcpu *vcpu)
return -1;
}
-static inline unsigned long kvm_vcpu_get_hfar(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned long kvm_vcpu_get_hfar(const struct kvm_vcpu *vcpu)
{
return vcpu->arch.fault.far_el2;
}
-static inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
+static __always_inline phys_addr_t kvm_vcpu_get_fault_ipa(const struct kvm_vcpu *vcpu)
{
return ((phys_addr_t)vcpu->arch.fault.hpfar_el2 & HPFAR_MASK) << 8;
}
@@ -299,7 +299,7 @@ static inline u32 kvm_vcpu_hvc_get_imm(const struct kvm_vcpu *vcpu)
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_xVC_IMM_MASK;
}
-static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_ISV);
}
@@ -319,17 +319,17 @@ static inline bool kvm_vcpu_dabt_issf(const struct kvm_vcpu *vcpu)
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SF);
}
-static inline int kvm_vcpu_dabt_get_rd(const struct kvm_vcpu *vcpu)
+static __always_inline int kvm_vcpu_dabt_get_rd(const struct kvm_vcpu *vcpu)
{
return (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SRT_MASK) >> ESR_ELx_SRT_SHIFT;
}
-static inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
}
-static inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WNR) ||
kvm_vcpu_dabt_iss1tw(vcpu); /* AF/DBM update */
@@ -340,18 +340,18 @@ static inline bool kvm_vcpu_dabt_is_cm(const struct kvm_vcpu *vcpu)
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
}
-static inline unsigned int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
+static __always_inline unsigned int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
{
return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
}
/* This one is not specific to Data Abort */
-static inline bool kvm_vcpu_trap_il_is32bit(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_trap_il_is32bit(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_IL);
}
-static inline u8 kvm_vcpu_trap_get_class(const struct kvm_vcpu *vcpu)
+static __always_inline u8 kvm_vcpu_trap_get_class(const struct kvm_vcpu *vcpu)
{
return ESR_ELx_EC(kvm_vcpu_get_hsr(vcpu));
}
@@ -361,17 +361,17 @@ static inline bool kvm_vcpu_trap_is_iabt(const struct kvm_vcpu *vcpu)
return kvm_vcpu_trap_get_class(vcpu) == ESR_ELx_EC_IABT_LOW;
}
-static inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
+static __always_inline u8 kvm_vcpu_trap_get_fault(const struct kvm_vcpu *vcpu)
{
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC;
}
-static inline u8 kvm_vcpu_trap_get_fault_type(const struct kvm_vcpu *vcpu)
+static __always_inline u8 kvm_vcpu_trap_get_fault_type(const struct kvm_vcpu *vcpu)
{
return kvm_vcpu_get_hsr(vcpu) & ESR_ELx_FSC_TYPE;
}
-static inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
+static __always_inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
{
switch (kvm_vcpu_trap_get_fault(vcpu)) {
case FSC_SEA:
@@ -390,7 +390,7 @@ static inline bool kvm_vcpu_dabt_isextabt(const struct kvm_vcpu *vcpu)
}
}
-static inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
+static __always_inline int kvm_vcpu_sys_get_rt(struct kvm_vcpu *vcpu)
{
u32 esr = kvm_vcpu_get_hsr(vcpu);
return ESR_ELx_SYS64_ISS_RT(esr);
@@ -504,7 +504,7 @@ static inline unsigned long vcpu_data_host_to_guest(struct kvm_vcpu *vcpu,
return data; /* Leave LE untouched */
}
-static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
+static __always_inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
{
if (vcpu_mode_is_32bit(vcpu))
kvm_skip_instr32(vcpu, is_wide_instr);
@@ -519,7 +519,7 @@ static inline void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
* Skip an instruction which has been emulated at hyp while most guest sysregs
* are live.
*/
-static inline void __hyp_text __kvm_skip_instr(struct kvm_vcpu *vcpu)
+static __always_inline void __hyp_text __kvm_skip_instr(struct kvm_vcpu *vcpu)
{
*vcpu_pc(vcpu) = read_sysreg_el2(SYS_ELR);
vcpu->arch.ctxt.gp_regs.regs.pstate = read_sysreg_el2(SYS_SPSR);
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 53d846f1bfe7..785762860c63 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -93,7 +93,7 @@ void kvm_update_va_mask(struct alt_instr *alt,
__le32 *origptr, __le32 *updptr, int nr_inst);
void kvm_compute_layout(void);
-static inline unsigned long __kern_hyp_va(unsigned long v)
+static __always_inline unsigned long __kern_hyp_va(unsigned long v)
{
asm volatile(ALTERNATIVE_CB("and %0, %0, #1\n"
"ror %0, %0, #1\n"
@@ -473,6 +473,7 @@ static inline int kvm_write_guest_lock(struct kvm *kvm, gpa_t gpa,
extern void *__kvm_bp_vect_base;
extern int __kvm_harden_el2_vector_slot;
+/* This is only called on a VHE system */
static inline void *kvm_get_hyp_vector(void)
{
struct bp_hardening_data *data = arm64_get_bp_hardening_data();
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 0958ed6191aa..61fd26752adc 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -83,7 +83,7 @@ static inline bool is_kernel_in_hyp_mode(void)
return read_sysreg(CurrentEL) == CurrentEL_EL2;
}
-static inline bool has_vhe(void)
+static __always_inline bool has_vhe(void)
{
if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
return true;
--
2.24.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Suzuki K Poulose, James Morse,
Sami Tolvanen, Catalin Marinas, Will Deacon, Julien Thierry
Hello!
It turns out KVM relies on the inline hint being honoured by the compiler
in quite a few more places than expected. Something about the Shadow Call
Stack support[0] causes the compiler to avoid inline-ing and to place
these functions outside the __hyp_text. This ruins KVM's day.
Add the simon-says __always_inline annotation to all the static
inlines that KVM calls from HYP code.
This series based on v5.6-rc2.
[0] https://lore.kernel.org/linux-arm-kernel/20200219000817.195049-1-samitolvanen@google.com/
Thanks,
James Morse (3):
KVM: arm64: Ask the compiler to __always_inline functions used at HYP
KVM: arm64: define our own swab32() to avoid a uapi static inline
arm64: Ask the compiler to __always_inline functions used by KVM at
HYP
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/cache.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 10 ++---
arch/arm64/include/asm/io.h | 4 +-
arch/arm64/include/asm/kvm_emulate.h | 48 ++++++++++++------------
arch/arm64/include/asm/kvm_hyp.h | 7 ++++
arch/arm64/include/asm/kvm_mmu.h | 3 +-
arch/arm64/include/asm/virt.h | 2 +-
arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 +-
10 files changed, 46 insertions(+), 38 deletions(-)
--
2.24.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] KVM: arm64: Ask the compiler to __always_inline functions used by KVM at HYP
From: James Morse @ 2020-02-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm
Cc: Ard Biesheuvel, Marc Zyngier, Sami Tolvanen, Catalin Marinas,
Will Deacon
Hello!
It turns out KVM relies on the inline hint being honoured by the compiler
in quite a few more places than expected. Something about the Shadow Call
Stack support[0] causes the compiler to avoid inline-ing and to place
these functions outside the __hyp_text. This ruins KVM's day.
Add the simon-says __always_inline annotation to all the static
inlines that KVM calls from HYP code.
This series based on v5.6-rc2.
[0] https://lore.kernel.org/linux-arm-kernel/20200219000817.195049-1-samitolvanen@google.com/
Thanks,
James Morse (3):
KVM: arm64: Ask the compiler to __always_inline functions used at HYP
KVM: arm64: define our own swab32() to avoid a uapi static inline
arm64: Ask the compiler to __always_inline functions used by KVM at
HYP
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/cache.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 10 ++---
arch/arm64/include/asm/io.h | 4 +-
arch/arm64/include/asm/kvm_emulate.h | 48 ++++++++++++------------
arch/arm64/include/asm/kvm_hyp.h | 7 ++++
arch/arm64/include/asm/kvm_mmu.h | 3 +-
arch/arm64/include/asm/virt.h | 2 +-
arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 +-
10 files changed, 46 insertions(+), 38 deletions(-)
--
2.24.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [PATCH 5/8] xfs_db: check that metadata updates have been committed
From: Darrick J. Wong @ 2020-02-20 16:58 UTC (permalink / raw)
To: Brian Foster; +Cc: sandeen, linux-xfs
In-Reply-To: <20200220140623.GC48977@bfoster>
On Thu, Feb 20, 2020 at 09:06:23AM -0500, Brian Foster wrote:
> On Wed, Feb 19, 2020 at 05:42:13PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> >
> > Add a new function that will ensure that everything we scribbled on has
> > landed on stable media, and report the results.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > db/init.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> >
> > diff --git a/db/init.c b/db/init.c
> > index 0ac37368..e92de232 100644
> > --- a/db/init.c
> > +++ b/db/init.c
> > @@ -184,6 +184,7 @@ main(
> > char *input;
> > char **v;
> > int start_iocur_sp;
> > + int d, l, r;
> >
> > init(argc, argv);
> > start_iocur_sp = iocur_sp;
> > @@ -216,6 +217,19 @@ main(
> > */
> > while (iocur_sp > start_iocur_sp)
> > pop_cur();
> > +
> > + libxfs_flush_devices(mp, &d, &l, &r);
> > + if (d)
> > + fprintf(stderr, _("%s: cannot flush data device (%d).\n"),
> > + progname, d);
> > + if (l)
> > + fprintf(stderr, _("%s: cannot flush log device (%d).\n"),
> > + progname, l);
> > + if (r)
> > + fprintf(stderr, _("%s: cannot flush realtime device (%d).\n"),
> > + progname, r);
> > +
> > +
>
> Seems like we could reduce some boilerplate by passing progname into
> libxfs_flush_devices() and letting it dump out of the error messages,
> unless there's some future code that cares about individual device error
> state.
Such a program could call libxfs_flush_devices directly, as we do here.
Also, progname is defined in libxfs so we don't even need to pass it as
an argument.
I had originally thought that we should try not to add fprintf calls to
libxfs because libraries aren't really supposed to be doing things like
that, but perhaps you're right that all of this should be melded into
something else.
> That said, it also seems the semantics of libxfs_flush_devices() are a
> bit different from convention. Just below we invoke
> libxfs_device_close() for each device (rather than for all three), and
> device_close() also happens to call fsync() and platform_flush_device()
> itself...
Yeah, the division of responsibilities is a little hazy here -- I would
think that unmounting a filesystem should flush all the memory caches
and then the disk cache, but OTOH it's the utility that opens the
devices and should therefore flush and close them.
I dunno. My current thinking is that libxfs_umount should call
libxfs_flush_devices() and print error messages as necessary, and return
error codes as appropriate. xfs_repair can then check the umount return
value and translate that into exit(1) as required. The device_close
functions will fsync a second time, but that shouldn't be a big deal
because we haven't dirtied anything in the meantime.
Thoughts?
--D
> Brian
>
> > libxfs_umount(mp);
> > if (x.ddev)
> > libxfs_device_close(x.ddev);
> >
>
^ permalink raw reply
* [PATCH] qdev-monitor: Forbid repeated device_del
From: Julia Suvorova @ 2020-02-20 16:55 UTC (permalink / raw)
To: qemu-devel
Cc: Paolo Bonzini, Daniel P. Berrangé, Eduardo Habkost,
Julia Suvorova, Michael S. Tsirkin
Device unplug can be done asynchronously. Thus, sending the second
device_del before the previous unplug is complete may lead to
unexpected results. On PCIe devices, this cancels the hot-unplug
process.
Signed-off-by: Julia Suvorova <jusual@redhat.com>
---
qdev-monitor.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/qdev-monitor.c b/qdev-monitor.c
index 8ce71a206b..8a2a9538cd 100644
--- a/qdev-monitor.c
+++ b/qdev-monitor.c
@@ -887,6 +887,12 @@ void qmp_device_del(const char *id, Error **errp)
{
DeviceState *dev = find_device_state(id, errp);
if (dev != NULL) {
+ if (dev->pending_deleted_event) {
+ error_setg(errp, "Device %s is already in the "
+ "process of unplug", id);
+ return;
+ }
+
qdev_unplug(dev, errp);
}
}
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v7 22/24] iomap: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 16:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xfs, linux-kernel, linux-f2fs-devel, cluster-devel,
linux-mm, ocfs2-devel, linux-fsdevel, linux-ext4, linux-erofs,
linux-btrfs
In-Reply-To: <20200220154912.GC19577@infradead.org>
On Thu, Feb 20, 2020 at 07:49:12AM -0800, Christoph Hellwig wrote:
> > +/**
> > + * iomap_readahead - Attempt to read pages from a file.
> > + * @rac: Describes the pages to be read.
> > + * @ops: The operations vector for the filesystem.
> > + *
> > + * This function is for filesystems to call to implement their readahead
> > + * address_space operation.
> > + *
> > + * Context: The file is pinned by the caller, and the pages to be read are
> > + * all locked and have an elevated refcount. This function will unlock
> > + * the pages (once I/O has completed on them, or I/O has been determined to
> > + * not be necessary). It will also decrease the refcount once the pages
> > + * have been submitted for I/O. After this point, the page may be removed
> > + * from the page cache, and should not be referenced.
> > + */
>
> Isn't the context documentation something that belongs into the aop
> documentation? I've never really seen the value of duplicating this
> information in method instances, as it is just bound to be out of date
> rather sooner than later.
I'm in two minds about it as well. There's definitely no value in
providing kernel-doc for implementations of a common interface ... so
rather than fixing the nilfs2 kernel-doc, I just deleted it. But this
isn't just the implementation, like nilfs2_readahead() is, it's a library
function for filesystems to call, so it deserves documentation. On the
other hand, there's no real thought to this on the part of the filesystem;
the implementation just calls this with the appropriate ops pointer.
Then again, I kind of feel like we need more documentation of iomap to
help filesystems convert to using it. But maybe kernel-doc isn't the
mechanism to provide that.
^ permalink raw reply
* [Intel-gfx] [PATCH i-g-t] sw_sync: Use fixed runtime for sync_expired_merge
From: Chris Wilson @ 2020-02-20 16:57 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Convert from using a fixed number of iterations (1 million), to using a
fixed runtime so that we have predictable (and shorter!) run times across
a wide variety of machines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Martin Peres <martin.peres@linux.intel.com>
---
tests/sw_sync.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 626b6d39f..6e439496d 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -747,30 +747,27 @@ static void test_sync_multi_producer_single_consumer(void)
static void test_sync_expired_merge(void)
{
- int iterations = 1 << 20;
int timeline;
- int i;
- int fence_expired, fence_merged;
+ int expired;
timeline = sw_sync_timeline_create();
sw_sync_timeline_inc(timeline, 100);
- fence_expired = sw_sync_timeline_create_fence(timeline, 1);
- igt_assert_f(sync_fence_wait(fence_expired, 0) == 0,
+ expired = sw_sync_timeline_create_fence(timeline, 1);
+ igt_assert_f(sync_fence_wait(expired, 0) == 0,
"Failure waiting for expired fence\n");
- fence_merged = sync_fence_merge(fence_expired, fence_expired);
- close(fence_merged);
+ close(sync_fence_merge(expired, expired));
- for (i = 0; i < iterations; i++) {
- int fence = sync_fence_merge(fence_expired, fence_expired);
+ igt_until_timeout(2) {
+ int fence = sync_fence_merge(expired, expired);
igt_assert_f(sync_fence_wait(fence, -1) == 0,
"Failure waiting on fence\n");
close(fence);
}
- close(fence_expired);
+ close(expired);
}
static void test_sync_random_merge(void)
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH v7 22/24] iomap: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 16:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200220154912.GC19577@infradead.org>
On Thu, Feb 20, 2020 at 07:49:12AM -0800, Christoph Hellwig wrote:
> > +/**
> > + * iomap_readahead - Attempt to read pages from a file.
> > + * @rac: Describes the pages to be read.
> > + * @ops: The operations vector for the filesystem.
> > + *
> > + * This function is for filesystems to call to implement their readahead
> > + * address_space operation.
> > + *
> > + * Context: The file is pinned by the caller, and the pages to be read are
> > + * all locked and have an elevated refcount. This function will unlock
> > + * the pages (once I/O has completed on them, or I/O has been determined to
> > + * not be necessary). It will also decrease the refcount once the pages
> > + * have been submitted for I/O. After this point, the page may be removed
> > + * from the page cache, and should not be referenced.
> > + */
>
> Isn't the context documentation something that belongs into the aop
> documentation? I've never really seen the value of duplicating this
> information in method instances, as it is just bound to be out of date
> rather sooner than later.
I'm in two minds about it as well. There's definitely no value in
providing kernel-doc for implementations of a common interface ... so
rather than fixing the nilfs2 kernel-doc, I just deleted it. But this
isn't just the implementation, like nilfs2_readahead() is, it's a library
function for filesystems to call, so it deserves documentation. On the
other hand, there's no real thought to this on the part of the filesystem;
the implementation just calls this with the appropriate ops pointer.
Then again, I kind of feel like we need more documentation of iomap to
help filesystems convert to using it. But maybe kernel-doc isn't the
mechanism to provide that.
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 22/24] iomap: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 16:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fsdevel, linux-mm, linux-kernel, linux-btrfs, linux-erofs,
linux-ext4, linux-f2fs-devel, cluster-devel, ocfs2-devel,
linux-xfs
In-Reply-To: <20200220154912.GC19577@infradead.org>
On Thu, Feb 20, 2020 at 07:49:12AM -0800, Christoph Hellwig wrote:
> > +/**
> > + * iomap_readahead - Attempt to read pages from a file.
> > + * @rac: Describes the pages to be read.
> > + * @ops: The operations vector for the filesystem.
> > + *
> > + * This function is for filesystems to call to implement their readahead
> > + * address_space operation.
> > + *
> > + * Context: The file is pinned by the caller, and the pages to be read are
> > + * all locked and have an elevated refcount. This function will unlock
> > + * the pages (once I/O has completed on them, or I/O has been determined to
> > + * not be necessary). It will also decrease the refcount once the pages
> > + * have been submitted for I/O. After this point, the page may be removed
> > + * from the page cache, and should not be referenced.
> > + */
>
> Isn't the context documentation something that belongs into the aop
> documentation? I've never really seen the value of duplicating this
> information in method instances, as it is just bound to be out of date
> rather sooner than later.
I'm in two minds about it as well. There's definitely no value in
providing kernel-doc for implementations of a common interface ... so
rather than fixing the nilfs2 kernel-doc, I just deleted it. But this
isn't just the implementation, like nilfs2_readahead() is, it's a library
function for filesystems to call, so it deserves documentation. On the
other hand, there's no real thought to this on the part of the filesystem;
the implementation just calls this with the appropriate ops pointer.
Then again, I kind of feel like we need more documentation of iomap to
help filesystems convert to using it. But maybe kernel-doc isn't the
mechanism to provide that.
^ permalink raw reply
* [Cluster-devel] [PATCH v7 22/24] iomap: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 16:57 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200220154912.GC19577@infradead.org>
On Thu, Feb 20, 2020 at 07:49:12AM -0800, Christoph Hellwig wrote:
> > +/**
> > + * iomap_readahead - Attempt to read pages from a file.
> > + * @rac: Describes the pages to be read.
> > + * @ops: The operations vector for the filesystem.
> > + *
> > + * This function is for filesystems to call to implement their readahead
> > + * address_space operation.
> > + *
> > + * Context: The file is pinned by the caller, and the pages to be read are
> > + * all locked and have an elevated refcount. This function will unlock
> > + * the pages (once I/O has completed on them, or I/O has been determined to
> > + * not be necessary). It will also decrease the refcount once the pages
> > + * have been submitted for I/O. After this point, the page may be removed
> > + * from the page cache, and should not be referenced.
> > + */
>
> Isn't the context documentation something that belongs into the aop
> documentation? I've never really seen the value of duplicating this
> information in method instances, as it is just bound to be out of date
> rather sooner than later.
I'm in two minds about it as well. There's definitely no value in
providing kernel-doc for implementations of a common interface ... so
rather than fixing the nilfs2 kernel-doc, I just deleted it. But this
isn't just the implementation, like nilfs2_readahead() is, it's a library
function for filesystems to call, so it deserves documentation. On the
other hand, there's no real thought to this on the part of the filesystem;
the implementation just calls this with the appropriate ops pointer.
Then again, I kind of feel like we need more documentation of iomap to
help filesystems convert to using it. But maybe kernel-doc isn't the
mechanism to provide that.
^ permalink raw reply
* [igt-dev] [PATCH i-g-t] sw_sync: Use fixed runtime for sync_expired_merge
From: Chris Wilson @ 2020-02-20 16:57 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
Convert from using a fixed number of iterations (1 million), to using a
fixed runtime so that we have predictable (and shorter!) run times across
a wide variety of machines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Martin Peres <martin.peres@linux.intel.com>
---
tests/sw_sync.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 626b6d39f..6e439496d 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -747,30 +747,27 @@ static void test_sync_multi_producer_single_consumer(void)
static void test_sync_expired_merge(void)
{
- int iterations = 1 << 20;
int timeline;
- int i;
- int fence_expired, fence_merged;
+ int expired;
timeline = sw_sync_timeline_create();
sw_sync_timeline_inc(timeline, 100);
- fence_expired = sw_sync_timeline_create_fence(timeline, 1);
- igt_assert_f(sync_fence_wait(fence_expired, 0) == 0,
+ expired = sw_sync_timeline_create_fence(timeline, 1);
+ igt_assert_f(sync_fence_wait(expired, 0) == 0,
"Failure waiting for expired fence\n");
- fence_merged = sync_fence_merge(fence_expired, fence_expired);
- close(fence_merged);
+ close(sync_fence_merge(expired, expired));
- for (i = 0; i < iterations; i++) {
- int fence = sync_fence_merge(fence_expired, fence_expired);
+ igt_until_timeout(2) {
+ int fence = sync_fence_merge(expired, expired);
igt_assert_f(sync_fence_wait(fence, -1) == 0,
"Failure waiting on fence\n");
close(fence);
}
- close(fence_expired);
+ close(expired);
}
static void test_sync_random_merge(void)
--
2.25.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* [meta-oe][PATCH] oprofile: Fix build with bfd 2.34+
From: Khem Raj @ 2020-02-20 16:57 UTC (permalink / raw)
To: openembedded-devel
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta-oe/recipes-kernel/oprofile/oprofile.inc | 1 +
.../0001-Use-new-bfd-APIs-from-2.34.patch | 79 +++++++++++++++++++
2 files changed, 80 insertions(+)
create mode 100644 meta-oe/recipes-kernel/oprofile/oprofile/0001-Use-new-bfd-APIs-from-2.34.patch
diff --git a/meta-oe/recipes-kernel/oprofile/oprofile.inc b/meta-oe/recipes-kernel/oprofile/oprofile.inc
index a9ee775d45..0e1e2ed8c9 100644
--- a/meta-oe/recipes-kernel/oprofile/oprofile.inc
+++ b/meta-oe/recipes-kernel/oprofile/oprofile.inc
@@ -25,6 +25,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz \
file://root-home-dir.patch \
file://0001-Add-rmb-definition-for-NIOS2-architecture.patch \
file://0001-replace-sym_iterator-0-with-sym_iterator.patch \
+ file://0001-Use-new-bfd-APIs-from-2.34.patch \
"
UPSTREAM_CHECK_REGEX = "oprofile-(?P<pver>\d+(\.\d+)+)/"
UPSTREAM_CHECK_URI = "https://sourceforge.net/projects/oprofile/files/oprofile/"
diff --git a/meta-oe/recipes-kernel/oprofile/oprofile/0001-Use-new-bfd-APIs-from-2.34.patch b/meta-oe/recipes-kernel/oprofile/oprofile/0001-Use-new-bfd-APIs-from-2.34.patch
new file mode 100644
index 0000000000..faf56d1168
--- /dev/null
+++ b/meta-oe/recipes-kernel/oprofile/oprofile/0001-Use-new-bfd-APIs-from-2.34.patch
@@ -0,0 +1,79 @@
+From 34745fb066a266ae6bbb15d08466d4d2cb6a2110 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Thu, 20 Feb 2020 08:11:04 -0800
+Subject: [PATCH] Use new bfd APIs from 2.34+
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ libutil++/bfd_support.cpp | 10 +++++-----
+ opjitconv/create_bfd.c | 6 +++---
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/libutil++/bfd_support.cpp b/libutil++/bfd_support.cpp
+index fa904839..e53a1530 100644
+--- a/libutil++/bfd_support.cpp
++++ b/libutil++/bfd_support.cpp
+@@ -137,7 +137,7 @@ static bool get_build_id(bfd * ibfd, unsigned char * build_id)
+ }
+ }
+
+- bfd_size_type buildid_sect_size = bfd_section_size(ibfd, sect);
++ bfd_size_type buildid_sect_size = bfd_section_size(sect);
+ char * contents = (char *) xmalloc(buildid_sect_size);
+ errno = 0;
+ if (!bfd_get_section_contents(ibfd, sect,
+@@ -188,7 +188,7 @@ bool get_debug_link_info(bfd * ibfd, string & filename, unsigned long & crc32)
+ if (sect == NULL)
+ return false;
+
+- bfd_size_type debuglink_size = bfd_section_size(ibfd, sect);
++ bfd_size_type debuglink_size = bfd_section_size(sect);
+ char * contents = (char *) xmalloc(debuglink_size);
+ cverb << vbfd
+ << ".gnu_debuglink section has size " << debuglink_size << endl;
+@@ -346,7 +346,7 @@ void fixup_linenr(bfd * abfd, asection * section, asymbol ** syms,
+ // first restrict the search on a sensible range of vma, 16 is
+ // an intuitive value based on epilog code look
+ size_t max_search = 16;
+- size_t section_size = bfd_section_size(abfd, section);
++ size_t section_size = bfd_section_size(section);
+ if (pc + max_search > section_size)
+ max_search = section_size - pc;
+
+@@ -819,10 +819,10 @@ find_nearest_line(bfd_info const & b, op_bfd_symbol const & sym,
+ else
+ pc = (sym.value() + offset) - sym.filepos();
+
+- if ((bfd_get_section_flags(abfd, section) & SEC_ALLOC) == 0)
++ if ((bfd_section_flags(section) & SEC_ALLOC) == 0)
+ goto fail;
+
+- if (pc >= bfd_section_size(abfd, section))
++ if (pc >= bfd_section_size(section))
+ goto fail;
+
+ ret = bfd_find_nearest_line(abfd, section, syms, pc, &cfilename,
+diff --git a/opjitconv/create_bfd.c b/opjitconv/create_bfd.c
+index 48db143b..5c0e9152 100644
+--- a/opjitconv/create_bfd.c
++++ b/opjitconv/create_bfd.c
+@@ -86,12 +86,12 @@ asection * create_section(bfd * abfd, char const * section_name,
+ bfd_perror("bfd_make_section");
+ goto error;
+ }
+- bfd_set_section_vma(abfd, section, vma);
+- if (bfd_set_section_size(abfd, section, size) == FALSE) {
++ bfd_set_section_vma(section, vma);
++ if (bfd_set_section_size(section, size) == FALSE) {
+ bfd_perror("bfd_set_section_size");
+ goto error;
+ }
+- if (bfd_set_section_flags(abfd, section, flags) == FALSE) {
++ if (bfd_set_section_flags(section, flags) == FALSE) {
+ bfd_perror("bfd_set_section_flags");
+ goto error;
+ }
+--
+2.25.1
+
--
2.25.1
^ permalink raw reply related
* Debugging unexpected latency on a new Xeon W C422 system
From: Kansky, Jan E. @ 2020-02-20 16:56 UTC (permalink / raw)
To: linux-rt-users
Here is my new system:
Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz
C422 chipset
Centos 8
I've compiled and built two versions of the realtime kernel to take
the place of the stock Centos kernel:
4.19.103-rt42
and
5.4.17-rt9
For both kernels, I run cyclictest:
./cyclictest -p 98 --smp -b 600 -f -m
The worst case latencies approach 2 milliseconds at times.
I have disabled SpeedStep in the BIOS.
I have also experimented with the following additional kernel boot
parameters for both kernels:
noibrs noibpb nospectre_v2 nospectre_v1 l1tf=off
nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off
nosoftlockup intel_idle.max_cstate=0 mce=ignore_ce
processor.max_cstate=0
These parameters didn't solve the problem.
The trace results show that the unexpected large latency seems to
occur in the following ways:
llvmpipe-9436 3d...... 4901974us!: switch_fpu_return
<-prepare_exit_to_usermode
llvmpipe-9436 3d...... 4902845us : smp_apic_timer_interrupt
<-apic_timer_interrupt
or
Xorg-8825 3....... 4905576us!: kfree <-__audit_syscall_exit
<idle>-0 2d...1.. 4905876us : smp_apic_timer_interrupt
<-apic_timer_interrupt
or
<idle>-0 2d...1.. 4905910us!: mwait_idle <-default_idle_call
<idle>-0 0d...1.. 4906049us : smp_apic_timer_interrupt
<-apic_timer_interrupt
or
llvmpipe-9435 1d...... 4917323us!: rcu_irq_exit <-irq_exit
llvmpipe-9438 3d...... 4917845us : smp_apic_timer_interrupt
<-apic_timer_interrupt
I do see NMIs occurring on the system, although not all latency events
seem to correlate with an increment in the NMI counter in
/proc/interrupts.
I would greatly appreciate any advice on what I should do to trace the
problem with this new system. I can send my .config files if needed.
CONFIG_PREEMPT_RT_FULL=y is set.
Thanks!
Jan
^ permalink raw reply
* Re: [PATCH 1/3] regulator: max14577: Add proper dt-compatible strings
From: Mark Brown @ 2020-02-20 16:56 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-pm, linux-kernel, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Chanwoo Choi, MyungJoo Ham,
Sebastian Reichel
In-Reply-To: <20200220145127.21273-1-m.szyprowski@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
On Thu, Feb 20, 2020 at 03:51:25PM +0100, Marek Szyprowski wrote:
> Add device tree compatible strings and create proper modalias structures
> to let this driver load automatically if compiled as module, because
> max14577 MFD driver creates MFD cells with such compatible strings.
> +static const struct of_device_id of_max14577_regulator_dt_match[] = {
> + { .compatible = "maxim,max77836-regulator",
> + .data = (void *)MAXIM_DEVICE_TYPE_MAX77836, },
> + { .compatible = "maxim,max14577-regulator",
> + .data = (void *)MAXIM_DEVICE_TYPE_MAX14577, },
Why would we want to encode the particular way Linux happens to
represent regulators on a MFD into the DT binding? It's not clear that
this is a generic thing (another OS might choose to have a separate
object for each regulator with no parent for example) and the compatible
isn't adding any information we didn't have already knowing about the
parent device.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] dnf, libdnf: Ignore if PACKAGE_CLASSES does not have rpm
From: Alexander Kanavin @ 2020-02-20 16:56 UTC (permalink / raw)
To: Khem Raj; +Cc: OE-core
In-Reply-To: <20200220165318.3677793-2-raj.khem@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
Can you add "...due to missing rpm support in libsolv" to the reasoning
string please?
Alex
On Thu, 20 Feb 2020 at 17:53, Khem Raj <raj.khem@gmail.com> wrote:
> dnf does not work with opkg or dpkg/apt anyway
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> meta/recipes-devtools/dnf/dnf_4.2.2.bb | 2 ++
> meta/recipes-devtools/libdnf/libdnf_0.28.1.bb | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> index f38167f1ad..220f1aabbd 100644
> --- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> +++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> @@ -84,3 +84,5 @@ SYSTEMD_SERVICE_${PN} = "dnf-makecache.service
> dnf-makecache.timer \
> dnf-automatic-notifyonly.service
> dnf-automatic-notifyonly.timer \
> "
> SYSTEMD_AUTO_ENABLE ?= "disable"
> +
> +PNBLACKLIST[dnf] ?= "${@bb.utils.contains('PACKAGE_CLASSES',
> 'package_rpm', '', 'does not build correctly without package_rpm in
> PACKAGE_CLASSES', d)}"
> diff --git a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> index 882c435b32..49afa04812 100644
> --- a/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> +++ b/meta/recipes-devtools/libdnf/libdnf_0.28.1.bb
> @@ -26,4 +26,5 @@ EXTRA_OECMAKE_append_class-native = " -DWITH_GIR=OFF"
> EXTRA_OECMAKE_append_class-nativesdk = " -DWITH_GIR=OFF"
>
> BBCLASSEXTEND = "native nativesdk"
> +PNBLACKLIST[libdnf] ?= "${@bb.utils.contains('PACKAGE_CLASSES',
> 'package_rpm', '', 'does not build correctly without package_rpm in
> PACKAGE_CLASSES', d)}"
>
> --
> 2.25.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 3397 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6 1/6] libxl: add infrastructure to track and query 'recent' domids
From: Durrant, Paul @ 2020-02-20 16:54 UTC (permalink / raw)
To: Ian Jackson; +Cc: Anthony Perard, xen-devel@lists.xenproject.org, Wei Liu
In-Reply-To: <24142.47029.435605.456811@mariner.uk.xensource.com>
> -----Original Message-----
> From: Ian Jackson <ian.jackson@citrix.com>
> Sent: 20 February 2020 16:46
> To: Durrant, Paul <pdurrant@amazon.co.uk>
> Cc: xen-devel@lists.xenproject.org; Wei Liu <wl@xen.org>; Anthony Perard
> <anthony.perard@citrix.com>
> Subject: RE: [PATCH v6 1/6] libxl: add infrastructure to track and query
> 'recent' domids
>
> Durrant, Paul writes ("RE: [PATCH v6 1/6] libxl: add infrastructure to
> track and query 'recent' domids"):
> > [Ian:]
> > > IMO the reuse timeout call and the clock_gettime call should be put in
> > > libxl__open_domid_history; and the time filtering check should be
> > > folded into libxl__read_recent.
> >
> > Ok. I was having a hard time guessing just exactly what you're looking
> for. I think that makes it a little clearer.
> ...
> > > In my review of v4 I wrote:
> > >
> > > Do you think this can be combined somehow ? Possibilities seem to
> > > include: explicit read_recent_{init,entry,finish} functions; a
> single
> > > function with a "per-entry" callback; same but with a macro. If you
> > > do that you can also have it have handle the "file does not exist"
> > > special case.
> > >
> > > You've provided the read_recent_entry function but the "init" function
> > > libxl__open_domid_history does too little. This series seems to be
> > > moving towards what I called read_recent_{init,entry,finish} (which
> > > should probably have the timestamp and FILE* in a struct together) but
> > > it seems to be doing so quite slowly.
> >
> > Now again I'm not sure *exactly* what you want me to do, but I'll have
> another guess.
>
> Maybe it would be better for us to try to come to a shared
> understanding before you do another respin...
>
Not being co-located makes this somewhat tricky; I think it will basically still come down to me writing some code and then you saying whether that's what you meant... unless you can write some (pseudo-)code to illustrate? I think, from what you say below, I might now have a better idea of what you want so let's have one more go-around of me writing the code first :-)
> > > - It encourages vacuous log messages whose content is mainly in the
> > > function and line number framing:
> > > + LOGE(ERROR, "failed");
> > > + return ERROR_FAIL;
> > > +}
> > > rather than
> > > if (!*f) {
> > > LOGE(ERROR, "failed to open recent domid file `%s'", path);
> > > rc = ERROR_FAIL;
> > > goto out;
> > > }
> > > (and the latter is to be preferred).
> >
> > But by asking me to put the error handling inside the sub-functions I
> lost context such as 'path' which was present in the previous structure. I
> could pass in an argument purely for the benefit of a log function but
> that seems excessive. I guess I will pull the error logging out again, but
> that seemed to be against your requirement to de-duplicate code.
>
> I think the path needs to be passed into these functions. This is why
> I think the functions need to take a struct* as an argument, for their
> shared state (including the path and the other stuff).
>
Ok, if that's the style you prefer I'll re-structure it that way.
Paul
> Thanks,
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.