* [PATCH][net-next] netns: restore ops before calling ops_exit_list
From: Li RongQing @ 2019-06-20 11:24 UTC (permalink / raw)
To: netdev, edumazet
ops has been iterated to first element when call pre_exit, and
it needs to restore from save_ops, not save ops to save_ops
Fixes: d7d99872c144 ("netns: add pre_exit method to struct pernet_operations")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/core/net_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 89dc99a28978..198ce503ae73 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -345,7 +345,7 @@ static __net_init int setup_net(struct net *net, struct user_namespace *user_ns)
synchronize_rcu();
- saved_ops = ops;
+ ops = saved_ops;
list_for_each_entry_continue_reverse(ops, &pernet_list, list)
ops_exit_list(ops, &net_exit_list);
--
2.16.2
^ permalink raw reply related
* [PATCH 4/4] KVM: arm/arm64: Fix emulated ptimer irq injection
From: Marc Zyngier @ 2019-06-20 11:23 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, kvm, Suzuki K Poulose, Viresh Kumar, Julien Thierry,
kvmarm, James Morse, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Andrew Jones <drjones@redhat.com>
The emulated ptimer needs to track the level changes, otherwise the
the interrupt will never get deasserted, resulting in the guest getting
stuck in an interrupt storm if it enables ptimer interrupts. This was
found with kvm-unit-tests; the ptimer tests hung as soon as interrupts
were enabled. Typical Linux guests don't have a problem as they prefer
using the virtual timer.
Fixes: bee038a674875 ("KVM: arm/arm64: Rework the timer code to use a timer_map")
Signed-off-by: Andrew Jones <drjones@redhat.com>
[Simplified the patch to res we only care about emulated timers here]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/arch_timer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 7fc272ecae16..1b1c449ceaf4 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -321,14 +321,15 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
}
}
+/* Only called for a fully emulated timer */
static void timer_emulate(struct arch_timer_context *ctx)
{
bool should_fire = kvm_timer_should_fire(ctx);
trace_kvm_timer_emulate(ctx, should_fire);
- if (should_fire) {
- kvm_timer_update_irq(ctx->vcpu, true, ctx);
+ if (should_fire != ctx->irq.level) {
+ kvm_timer_update_irq(ctx->vcpu, should_fire, ctx);
return;
}
--
2.20.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] x86/boot/64: Fix missed fixup_pointer() for next_early_pgt access
From: Kirill A. Shutemov @ 2019-06-20 11:24 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Dave Hansen, Andy Lutomirski, Peter Zijlstra
Cc: x86, linux-kernel, Kirill A. Shutemov, Alexander Potapenko
__startup_64() uses fixup_pointer() to access global variables in a
position-independent fashion. Access to next_early_pgt was wrapped into
the helper, but one of the instance in 5-level paging branch was missed.
GCC generates a R_X86_64_PC32 PC-relative relocation for the access
which doesn't trigger the issue, but Clang emmits a R_X86_64_32S which
leads to an invalid memory and system reboot.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Fixes: 187e91fe5e91 ("x86/boot/64/clang: Use fixup_pointer() to access 'next_early_pgt'")
Cc: Alexander Potapenko <glider@google.com>
---
arch/x86/kernel/head64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 16b1cbd3a61e..4d98ba8063d1 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -184,7 +184,7 @@ unsigned long __head __startup_64(unsigned long physaddr,
pgtable_flags = _KERNPG_TABLE_NOENC + sme_get_me_mask();
if (la57) {
- p4d = fixup_pointer(early_dynamic_pgts[next_early_pgt++], physaddr);
+ p4d = fixup_pointer(early_dynamic_pgts[(*next_pgt_ptr)++], physaddr);
i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
pgd[i + 0] = (pgdval_t)p4d + pgtable_flags;
--
2.21.0
^ permalink raw reply related
* [PATCH 3/4] KVM: arm/arm64: vgic: Fix kvm_device leak in vgic_its_destroy
From: Marc Zyngier @ 2019-06-20 11:23 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, kvm, Suzuki K Poulose, Viresh Kumar, Julien Thierry,
kvmarm, James Morse, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Dave Martin <Dave.Martin@arm.com>
kvm_device->destroy() seems to be supposed to free its kvm_device
struct, but vgic_its_destroy() is not currently doing this,
resulting in a memory leak, resulting in kmemleak reports such as
the following:
unreferenced object 0xffff800aeddfe280 (size 128):
comm "qemu-system-aar", pid 13799, jiffies 4299827317 (age 1569.844s)
[...]
backtrace:
[<00000000a08b80e2>] kmem_cache_alloc+0x178/0x208
[<00000000dcad2bd3>] kvm_vm_ioctl+0x350/0xbc0
Fix it.
Cc: Andre Przywara <andre.przywara@arm.com>
Fixes: 1085fdc68c60 ("KVM: arm64: vgic-its: Introduce new KVM ITS device")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-its.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 44ceaccb18cf..8c9fe831bce4 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -1734,6 +1734,7 @@ static void vgic_its_destroy(struct kvm_device *kvm_dev)
mutex_unlock(&its->its_lock);
kfree(its);
+ kfree(kvm_dev);/* alloc by kvm_ioctl_create_device, free by .destroy */
}
static int vgic_its_has_attr_regs(struct kvm_device *dev,
--
2.20.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 2/4] KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, kvm, Suzuki K Poulose, Viresh Kumar, Julien Thierry,
kvmarm, James Morse, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Dave Martin <Dave.Martin@arm.com>
Since commit d26c25a9d19b ("arm64: KVM: Tighten guest core register
access from userspace"), KVM_{GET,SET}_ONE_REG rejects register IDs
that do not correspond to a single underlying architectural register.
KVM_GET_REG_LIST was not changed to match however: instead, it
simply yields a list of 32-bit register IDs that together cover the
whole kvm_regs struct. This means that if userspace tries to use
the resulting list of IDs directly to drive calls to KVM_*_ONE_REG,
some of those calls will now fail.
This was not the intention. Instead, iterating KVM_*_ONE_REG over
the list of IDs returned by KVM_GET_REG_LIST should be guaranteed
to work.
This patch fixes the problem by splitting validate_core_offset()
into a backend core_reg_size_from_offset() which does all of the
work except for checking that the size field in the register ID
matches, and kvm_arm_copy_reg_indices() and num_core_regs() are
converted to use this to enumerate the valid offsets.
kvm_arm_copy_reg_indices() now also sets the register ID size field
appropriately based on the value returned, so the register ID
supplied to userspace is fully qualified for use with the register
access ioctls.
Cc: stable@vger.kernel.org
Fixes: d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/guest.c | 53 +++++++++++++++++++++++++++++++-----------
1 file changed, 40 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index ae734fcfd4ea..c8aa00179363 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -70,10 +70,8 @@ static u64 core_reg_offset_from_id(u64 id)
return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
}
-static int validate_core_offset(const struct kvm_vcpu *vcpu,
- const struct kvm_one_reg *reg)
+static int core_reg_size_from_offset(const struct kvm_vcpu *vcpu, u64 off)
{
- u64 off = core_reg_offset_from_id(reg->id);
int size;
switch (off) {
@@ -103,8 +101,7 @@ static int validate_core_offset(const struct kvm_vcpu *vcpu,
return -EINVAL;
}
- if (KVM_REG_SIZE(reg->id) != size ||
- !IS_ALIGNED(off, size / sizeof(__u32)))
+ if (!IS_ALIGNED(off, size / sizeof(__u32)))
return -EINVAL;
/*
@@ -115,6 +112,21 @@ static int validate_core_offset(const struct kvm_vcpu *vcpu,
if (vcpu_has_sve(vcpu) && core_reg_offset_is_vreg(off))
return -EINVAL;
+ return size;
+}
+
+static int validate_core_offset(const struct kvm_vcpu *vcpu,
+ const struct kvm_one_reg *reg)
+{
+ u64 off = core_reg_offset_from_id(reg->id);
+ int size = core_reg_size_from_offset(vcpu, off);
+
+ if (size < 0)
+ return -EINVAL;
+
+ if (KVM_REG_SIZE(reg->id) != size)
+ return -EINVAL;
+
return 0;
}
@@ -447,19 +459,34 @@ static int copy_core_reg_indices(const struct kvm_vcpu *vcpu,
{
unsigned int i;
int n = 0;
- const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;
for (i = 0; i < sizeof(struct kvm_regs) / sizeof(__u32); i++) {
- /*
- * The KVM_REG_ARM64_SVE regs must be used instead of
- * KVM_REG_ARM_CORE for accessing the FPSIMD V-registers on
- * SVE-enabled vcpus:
- */
- if (vcpu_has_sve(vcpu) && core_reg_offset_is_vreg(i))
+ u64 reg = KVM_REG_ARM64 | KVM_REG_ARM_CORE | i;
+ int size = core_reg_size_from_offset(vcpu, i);
+
+ if (size < 0)
+ continue;
+
+ switch (size) {
+ case sizeof(__u32):
+ reg |= KVM_REG_SIZE_U32;
+ break;
+
+ case sizeof(__u64):
+ reg |= KVM_REG_SIZE_U64;
+ break;
+
+ case sizeof(__uint128_t):
+ reg |= KVM_REG_SIZE_U128;
+ break;
+
+ default:
+ WARN_ON(1);
continue;
+ }
if (uindices) {
- if (put_user(core_reg | i, uindices))
+ if (put_user(reg, uindices))
return -EFAULT;
uindices++;
}
--
2.20.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: [Qemu-devel] [PATCH] memory: do not do out of bound notification
From: Yan Zhao @ 2019-06-20 10:57 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Auger Eric, qemu-devel@nongnu.org, Peter Xu
In-Reply-To: <6829b139-3eab-449e-04d6-07f1e381316d@redhat.com>
On Thu, Jun 20, 2019 at 04:35:29PM +0800, Paolo Bonzini wrote:
> On 20/06/19 06:02, Peter Xu wrote:
> > Seems workable, to be explicit - we can even cut it into chunks with
> > different size to be efficient.
>
> Yes, this is not hard (completely untested):
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 44b1231157..541538bc6c 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -3388,39 +3388,34 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
> }
>
> assert(start <= end);
> - size = end - start;
> + while (end > start) {
> + size = end - start;
> + /* Only keep the lowest bit of either size or start. */
> + size = MIN(size & -size, start & -start);
> + /* Should not happen, but limit to address width too just in case */
> + size = MIN(size, 1ULL << s->aw_bits);
>
> - if (ctpop64(size) != 1) {
> - /*
> - * This size cannot format a correct mask. Let's enlarge it to
> - * suite the minimum available mask.
> - */
> - int n = 64 - clz64(size);
> - if (n > s->aw_bits) {
> - /* should not happen, but in case it happens, limit it */
> - n = s->aw_bits;
> - }
> - size = 1ULL << n;
> - }
> + assert((start & (size - 1)) == 0);
>
> - entry.target_as = &address_space_memory;
> - /* Adjust iova for the size */
> - entry.iova = n->start & ~(size - 1);
> - /* This field is meaningless for unmap */
> - entry.translated_addr = 0;
> - entry.perm = IOMMU_NONE;
> - entry.addr_mask = size - 1;
> + entry.target_as = &address_space_memory;
> + entry.iova = start;
> + /* This field is meaningless for unmap */
> + entry.translated_addr = 0;
> + entry.perm = IOMMU_NONE;
> + entry.addr_mask = size - 1;
>
> - trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
> - VTD_PCI_SLOT(as->devfn),
> - VTD_PCI_FUNC(as->devfn),
> - entry.iova, size);
> + trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
> + VTD_PCI_SLOT(as->devfn),
> + VTD_PCI_FUNC(as->devfn),
> + entry.iova, size);
>
> - map.iova = entry.iova;
> - map.size = entry.addr_mask;
> - iova_tree_remove(as->iova_tree, &map);
> + map.iova = entry.iova;
> + map.size = entry.addr_mask;
> + iova_tree_remove(as->iova_tree, &map);
>
> - memory_region_notify_one(n, &entry);
> + memory_region_notify_one(n, &entry);
> + start += size;
> + }
> }
>
> static void vtd_address_space_unmap_all(IntelIOMMUState *s)
>
>
> Yan,
>
> if something like this works for you, let me know and I will submit it
> as a proper patch.
>
> Paolo
hi Paolo
Thanks and I'll try it tomorrow and let you know the result.
But may I know why it cannot simply be like below?
Thanks
Yan
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index b0d8a1c..2956db6 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3374,7 +3374,6 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
IntelIOMMUState *s = as->iommu_state;
DMAMap map;
/*
* Note: all the codes in this function has a assumption that IOVA
* bits are no more than VTD_MGAW bits (which is restricted by
@@ -3392,23 +3391,8 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
assert(start <= end);
size = end - start;
- if (ctpop64(size) != 1) {
- /*
- * This size cannot format a correct mask. Let's enlarge it to
- * suite the minimum available mask.
- */
- int n = 64 - clz64(size);
- if (n > s->aw_bits) {
- /* should not happen, but in case it happens, limit it */
- n = s->aw_bits;
- }
- size = 1ULL << n;
- }
-
-
entry.target_as = &address_space_memory;
- /* Adjust iova for the size */
- entry.iova = n->start & ~(size - 1);
+ entry.iova = n->start;
/* This field is meaningless for unmap */
entry.translated_addr = 0;
entry.perm = IOMMU_NONE;
^ permalink raw reply related
* [PATCH] x86/boot/64: Fix crash if kernel images crosses page table boundary
From: Kirill A. Shutemov @ 2019-06-20 11:23 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Dave Hansen, Andy Lutomirski, Peter Zijlstra
Cc: x86, linux-kernel, Kirill A. Shutemov
Kernel that boots in 5-level paging mode crashes in small percentage of
cases if KASLR is enabled.
This issue was tracked down to the case when the kernel image unpack in
the way it crosses 1G boundary. The crash was due to overrun of PMD page
table in __startup_64() and corruption of P4D page table allocated next
to it.
The issue is not visible with 4-level paging as we don't use the P4D
page table.
The root cause is that the handling of page table wraparound was lost
when part of startup_64() was rewritten in C.
Restore the handling. It also fixes the issue when the kernel image put
across 512G and, for 5-level paging, 64T boundary.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Fixes: c88d71508e36 ("x86/boot/64: Rewrite startup_64() in C")
---
arch/x86/kernel/head64.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 4d98ba8063d1..b502c28801fc 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -190,18 +190,18 @@ unsigned long __head __startup_64(unsigned long physaddr,
pgd[i + 0] = (pgdval_t)p4d + pgtable_flags;
pgd[i + 1] = (pgdval_t)p4d + pgtable_flags;
- i = (physaddr >> P4D_SHIFT) % PTRS_PER_P4D;
- p4d[i + 0] = (pgdval_t)pud + pgtable_flags;
- p4d[i + 1] = (pgdval_t)pud + pgtable_flags;
+ i = physaddr >> P4D_SHIFT;
+ p4d[(i + 0) % PTRS_PER_P4D] = (pgdval_t)pud + pgtable_flags;
+ p4d[(i + 1) % PTRS_PER_P4D] = (pgdval_t)pud + pgtable_flags;
} else {
i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
pgd[i + 0] = (pgdval_t)pud + pgtable_flags;
pgd[i + 1] = (pgdval_t)pud + pgtable_flags;
}
- i = (physaddr >> PUD_SHIFT) % PTRS_PER_PUD;
- pud[i + 0] = (pudval_t)pmd + pgtable_flags;
- pud[i + 1] = (pudval_t)pmd + pgtable_flags;
+ i = physaddr >> PUD_SHIFT;
+ pud[(i + 0) % PTRS_PER_PUD] = (pudval_t)pmd + pgtable_flags;
+ pud[(i + 1) % PTRS_PER_PUD] = (pudval_t)pmd + pgtable_flags;
pmd_entry = __PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL;
/* Filter out unsupported __PAGE_KERNEL_* bits: */
@@ -211,8 +211,8 @@ unsigned long __head __startup_64(unsigned long physaddr,
pmd_entry += physaddr;
for (i = 0; i < DIV_ROUND_UP(_end - _text, PMD_SIZE); i++) {
- int idx = i + (physaddr >> PMD_SHIFT) % PTRS_PER_PMD;
- pmd[idx] = pmd_entry + i * PMD_SIZE;
+ int idx = i + (physaddr >> PMD_SHIFT);;
+ pmd[idx % PTRS_PER_PMD] = pmd_entry + i * PMD_SIZE;
}
/*
--
2.21.0
^ permalink raw reply related
* [PATCH 1/4] KVM: arm64: Implement vq_present() as a macro
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, kvm, Suzuki K Poulose, Viresh Kumar, Julien Thierry,
kvmarm, James Morse, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Viresh Kumar <viresh.kumar@linaro.org>
This routine is a one-liner and doesn't really need to be function and
can be implemented as a macro.
Suggested-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/guest.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 3ae2f82fca46..ae734fcfd4ea 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,13 +207,7 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
#define vq_word(vq) (((vq) - SVE_VQ_MIN) / 64)
#define vq_mask(vq) ((u64)1 << ((vq) - SVE_VQ_MIN) % 64)
-
-static bool vq_present(
- const u64 (*const vqs)[KVM_ARM64_SVE_VLS_WORDS],
- unsigned int vq)
-{
- return (*vqs)[vq_word(vq)] & vq_mask(vq);
-}
+#define vq_present(vqs, vq) ((vqs)[vq_word(vq)] & vq_mask(vq))
static int get_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
@@ -258,7 +252,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
max_vq = 0;
for (vq = SVE_VQ_MIN; vq <= SVE_VQ_MAX; ++vq)
- if (vq_present(&vqs, vq))
+ if (vq_present(vqs, vq))
max_vq = vq;
if (max_vq > sve_vq_from_vl(kvm_sve_max_vl))
@@ -272,7 +266,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
* maximum:
*/
for (vq = SVE_VQ_MIN; vq <= max_vq; ++vq)
- if (vq_present(&vqs, vq) != sve_vq_available(vq))
+ if (vq_present(vqs, vq) != sve_vq_available(vq))
return -EINVAL;
/* Can't run with no vector lengths at all: */
--
2.20.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] x86/mm: Handle physical-virtual alignment mismatch in phys_p4d_init()
From: Kirill A. Shutemov @ 2019-06-20 11:22 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Dave Hansen, Andy Lutomirski, Peter Zijlstra
Cc: x86, linux-kernel, Kirill A. Shutemov, Kyle Pelton, Baoquan He
Kyle has reported that kernel crashes sometimes when it boots in
5-level paging mode with KASLR enabled:
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/mm/init_64.c:87 phys_p4d_init+0x1d4/0x1ea
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.0-rc5+ #27
[ 0.000000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.4
[ 0.000000] RIP: 0010:phys_p4d_init+0x1d4/0x1ea
[ 0.000000] Code: 20 be 43 94 ff 45 cc 4c 89 e6 e9 90 fe ff ff 48 89 d8 eb 1d 48 8b 4d d0 48 8b 7d c0 45 0f b6 3
[ 0.000000] RSP: 0000:ffffffff94403c70 EFLAGS: 00000046 ORIG_RAX: 0000000000000000
[ 0.000000] RAX: 0000000000000000 RBX: 0000000340000000 RCX: 0000000000000007
[ 0.000000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 0.000000] RBP: ffffffff94403cb8 R08: 0000000000000023 R09: ffffffff947fa680
[ 0.000000] R10: 0000000000000008 R11: 0000000000000031 R12: 0000010000000000
[ 0.000000] R13: 0000000340000000 R14: ffffffff94403d01 R15: ff484d01962014d0
[ 0.000000] FS: 0000000000000000(0000) GS:ffffffff9468a000(0000) knlGS:0000000000000000
[ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.000000] CR2: ff484d0196201000 CR3: 0000000315b3e000 CR4: 00000000000016b0
[ 0.000000] Call Trace:
[ 0.000000] __kernel_physical_mapping_init+0x10a/0x35c
[ 0.000000] kernel_physical_mapping_init+0xe/0x10
[ 0.000000] init_memory_mapping+0x1aa/0x3b0
[ 0.000000] init_range_memory_mapping+0xc8/0x116
[ 0.000000] init_mem_mapping+0x225/0x2eb
[ 0.000000] setup_arch+0x6ff/0xcf5
[ 0.000000] start_kernel+0x64/0x53b
[ 0.000000] ? copy_bootdata+0x1f/0xce
[ 0.000000] x86_64_start_reservations+0x24/0x26
[ 0.000000] x86_64_start_kernel+0x8a/0x8d
[ 0.000000] secondary_startup_64+0xb6/0xc0
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x3f/0x60 with crng_init=0
...
[ 0.000000] BUG: unable to handle page fault for address: ff484d019580eff8
[ 0.000000] #PF: supervisor read access in kernel mode
[ 0.000000] #PF: error_code(0x0000) - not-present page
[ 0.000000] BAD
[ 0.000000] Oops: 0000 [#1] SMP NOPTI
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W 5.2.0-rc5+ #27
[ 0.000000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.4
[ 0.000000] RIP: 0010:fill_pud+0x13/0x130
[ 0.000000] Code: 48 83 c4 08 b8 f4 ff ff ff 5b 41 5c 41 5d 41 5e 41 5f 5d c3 31 c0 c3 e8 2b ee d8 00 55 48 89 4
[ 0.000000] RSP: 0000:ffffffff94403dc0 EFLAGS: 00000006
[ 0.000000] RAX: 00000000000001ff RBX: ffffffffff5fd000 RCX: 0000000000000030
[ 0.000000] RDX: 00000000000001ff RSI: ffffffffff5fd000 RDI: ff484d019580eff8
[ 0.000000] RBP: ffffffff94403de0 R08: 0000000000000078 R09: 0000000000000002
[ 0.000000] R10: ffffffff94403cb0 R11: 000000000000005b R12: ff484d019580eff8
[ 0.000000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 0.000000] FS: 0000000000000000(0000) GS:ffffffff9468a000(0000) knlGS:0000000000000000
[ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.000000] CR2: ff484d019580aa40 CR3: 000000031580a000 CR4: 00000000000016b0
[ 0.000000] Call Trace:
[ 0.000000] set_pte_vaddr_p4d+0x2e/0x50
[ 0.000000] set_pte_vaddr+0x6f/0xb0
[ 0.000000] __native_set_fixmap+0x28/0x40
[ 0.000000] native_set_fixmap+0x39/0x70
[ 0.000000] register_lapic_address+0x49/0xb6
[ 0.000000] early_acpi_boot_init+0xa5/0xde
[ 0.000000] setup_arch+0x944/0xcf5
[ 0.000000] start_kernel+0x64/0x53b
[ 0.000000] ? copy_bootdata+0x1f/0xce
[ 0.000000] x86_64_start_reservations+0x24/0x26
[ 0.000000] x86_64_start_kernel+0x8a/0x8d
[ 0.000000] secondary_startup_64+0xb6/0xc0
[ 0.000000] Modules linked in:
[ 0.000000] CR2: ff484d019580eff8
Kyle bisected the issue to commmit b569c1843498 ("x86/mm/KASLR: Reduce
randomization granularity for 5-level paging to 1GB")
The commit relaxes KASLR alignment requirements and it can lead to
mismatch bentween 'i' and 'p4d_index(vaddr)' inside the loop in
phys_p4d_init(). The mismatch in its turn leads to clearing wrong p4d
entry and eventually to the oops.
The fix is to make phys_p4d_init() walk virtual address space, not
physical one.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-and-tested-by: Kyle Pelton <kyle.d.pelton@intel.com>
Fixes: b569c1843498 ("x86/mm/KASLR: Reduce randomization granularity for 5-level paging to 1GB")
Cc: Baoquan He <bhe@redhat.com>
---
arch/x86/mm/init_64.c | 39 ++++++++++++++++-----------------------
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 693aaf28d5fe..4628ac9105a2 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -671,41 +671,34 @@ static unsigned long __meminit
phys_p4d_init(p4d_t *p4d_page, unsigned long paddr, unsigned long paddr_end,
unsigned long page_size_mask, bool init)
{
- unsigned long paddr_next, paddr_last = paddr_end;
- unsigned long vaddr = (unsigned long)__va(paddr);
- int i = p4d_index(vaddr);
+ unsigned long vaddr, vaddr_start, vaddr_end, vaddr_next, paddr_last;
+
+ paddr_last = paddr_end;
+ vaddr = (unsigned long)__va(paddr);
+ vaddr_end = (unsigned long)__va(paddr_end);
+ vaddr_start = vaddr;
if (!pgtable_l5_enabled())
return phys_pud_init((pud_t *) p4d_page, paddr, paddr_end,
page_size_mask, init);
- for (; i < PTRS_PER_P4D; i++, paddr = paddr_next) {
- p4d_t *p4d;
+ for (; vaddr < vaddr_end; vaddr = vaddr_next) {
+ p4d_t *p4d = p4d_page + p4d_index(vaddr);
pud_t *pud;
- vaddr = (unsigned long)__va(paddr);
- p4d = p4d_page + p4d_index(vaddr);
- paddr_next = (paddr & P4D_MASK) + P4D_SIZE;
+ vaddr_next = (vaddr & P4D_MASK) + P4D_SIZE;
- if (paddr >= paddr_end) {
- if (!after_bootmem &&
- !e820__mapped_any(paddr & P4D_MASK, paddr_next,
- E820_TYPE_RAM) &&
- !e820__mapped_any(paddr & P4D_MASK, paddr_next,
- E820_TYPE_RESERVED_KERN))
- set_p4d_init(p4d, __p4d(0), init);
- continue;
- }
-
- if (!p4d_none(*p4d)) {
- pud = pud_offset(p4d, 0);
- paddr_last = phys_pud_init(pud, paddr, paddr_end,
- page_size_mask, init);
+ if (p4d_val(*p4d)) {
+ pud = (pud_t *)p4d_page_vaddr(*p4d);
+ paddr_last = phys_pud_init(pud, __pa(vaddr),
+ __pa(vaddr_end),
+ page_size_mask,
+ init);
continue;
}
pud = alloc_low_page();
- paddr_last = phys_pud_init(pud, paddr, paddr_end,
+ paddr_last = phys_pud_init(pud, __pa(vaddr), __pa(vaddr_end),
page_size_mask, init);
spin_lock(&init_mm.page_table_lock);
--
2.21.0
^ permalink raw reply related
* [PATCH 4/4] KVM: arm/arm64: Fix emulated ptimer irq injection
From: Marc Zyngier @ 2019-06-20 11:23 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: kvm, Viresh Kumar, kvmarm, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Andrew Jones <drjones@redhat.com>
The emulated ptimer needs to track the level changes, otherwise the
the interrupt will never get deasserted, resulting in the guest getting
stuck in an interrupt storm if it enables ptimer interrupts. This was
found with kvm-unit-tests; the ptimer tests hung as soon as interrupts
were enabled. Typical Linux guests don't have a problem as they prefer
using the virtual timer.
Fixes: bee038a674875 ("KVM: arm/arm64: Rework the timer code to use a timer_map")
Signed-off-by: Andrew Jones <drjones@redhat.com>
[Simplified the patch to res we only care about emulated timers here]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/arch_timer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 7fc272ecae16..1b1c449ceaf4 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -321,14 +321,15 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
}
}
+/* Only called for a fully emulated timer */
static void timer_emulate(struct arch_timer_context *ctx)
{
bool should_fire = kvm_timer_should_fire(ctx);
trace_kvm_timer_emulate(ctx, should_fire);
- if (should_fire) {
- kvm_timer_update_irq(ctx->vcpu, true, ctx);
+ if (should_fire != ctx->irq.level) {
+ kvm_timer_update_irq(ctx->vcpu, should_fire, ctx);
return;
}
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH 3/4] KVM: arm/arm64: vgic: Fix kvm_device leak in vgic_its_destroy
From: Marc Zyngier @ 2019-06-20 11:23 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: kvm, Viresh Kumar, kvmarm, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Dave Martin <Dave.Martin@arm.com>
kvm_device->destroy() seems to be supposed to free its kvm_device
struct, but vgic_its_destroy() is not currently doing this,
resulting in a memory leak, resulting in kmemleak reports such as
the following:
unreferenced object 0xffff800aeddfe280 (size 128):
comm "qemu-system-aar", pid 13799, jiffies 4299827317 (age 1569.844s)
[...]
backtrace:
[<00000000a08b80e2>] kmem_cache_alloc+0x178/0x208
[<00000000dcad2bd3>] kvm_vm_ioctl+0x350/0xbc0
Fix it.
Cc: Andre Przywara <andre.przywara@arm.com>
Fixes: 1085fdc68c60 ("KVM: arm64: vgic-its: Introduce new KVM ITS device")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-its.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 44ceaccb18cf..8c9fe831bce4 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -1734,6 +1734,7 @@ static void vgic_its_destroy(struct kvm_device *kvm_dev)
mutex_unlock(&its->its_lock);
kfree(its);
+ kfree(kvm_dev);/* alloc by kvm_ioctl_create_device, free by .destroy */
}
static int vgic_its_has_attr_regs(struct kvm_device *dev,
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH 2/4] KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: kvm, Viresh Kumar, kvmarm, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Dave Martin <Dave.Martin@arm.com>
Since commit d26c25a9d19b ("arm64: KVM: Tighten guest core register
access from userspace"), KVM_{GET,SET}_ONE_REG rejects register IDs
that do not correspond to a single underlying architectural register.
KVM_GET_REG_LIST was not changed to match however: instead, it
simply yields a list of 32-bit register IDs that together cover the
whole kvm_regs struct. This means that if userspace tries to use
the resulting list of IDs directly to drive calls to KVM_*_ONE_REG,
some of those calls will now fail.
This was not the intention. Instead, iterating KVM_*_ONE_REG over
the list of IDs returned by KVM_GET_REG_LIST should be guaranteed
to work.
This patch fixes the problem by splitting validate_core_offset()
into a backend core_reg_size_from_offset() which does all of the
work except for checking that the size field in the register ID
matches, and kvm_arm_copy_reg_indices() and num_core_regs() are
converted to use this to enumerate the valid offsets.
kvm_arm_copy_reg_indices() now also sets the register ID size field
appropriately based on the value returned, so the register ID
supplied to userspace is fully qualified for use with the register
access ioctls.
Cc: stable@vger.kernel.org
Fixes: d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/guest.c | 53 +++++++++++++++++++++++++++++++-----------
1 file changed, 40 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index ae734fcfd4ea..c8aa00179363 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -70,10 +70,8 @@ static u64 core_reg_offset_from_id(u64 id)
return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
}
-static int validate_core_offset(const struct kvm_vcpu *vcpu,
- const struct kvm_one_reg *reg)
+static int core_reg_size_from_offset(const struct kvm_vcpu *vcpu, u64 off)
{
- u64 off = core_reg_offset_from_id(reg->id);
int size;
switch (off) {
@@ -103,8 +101,7 @@ static int validate_core_offset(const struct kvm_vcpu *vcpu,
return -EINVAL;
}
- if (KVM_REG_SIZE(reg->id) != size ||
- !IS_ALIGNED(off, size / sizeof(__u32)))
+ if (!IS_ALIGNED(off, size / sizeof(__u32)))
return -EINVAL;
/*
@@ -115,6 +112,21 @@ static int validate_core_offset(const struct kvm_vcpu *vcpu,
if (vcpu_has_sve(vcpu) && core_reg_offset_is_vreg(off))
return -EINVAL;
+ return size;
+}
+
+static int validate_core_offset(const struct kvm_vcpu *vcpu,
+ const struct kvm_one_reg *reg)
+{
+ u64 off = core_reg_offset_from_id(reg->id);
+ int size = core_reg_size_from_offset(vcpu, off);
+
+ if (size < 0)
+ return -EINVAL;
+
+ if (KVM_REG_SIZE(reg->id) != size)
+ return -EINVAL;
+
return 0;
}
@@ -447,19 +459,34 @@ static int copy_core_reg_indices(const struct kvm_vcpu *vcpu,
{
unsigned int i;
int n = 0;
- const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;
for (i = 0; i < sizeof(struct kvm_regs) / sizeof(__u32); i++) {
- /*
- * The KVM_REG_ARM64_SVE regs must be used instead of
- * KVM_REG_ARM_CORE for accessing the FPSIMD V-registers on
- * SVE-enabled vcpus:
- */
- if (vcpu_has_sve(vcpu) && core_reg_offset_is_vreg(i))
+ u64 reg = KVM_REG_ARM64 | KVM_REG_ARM_CORE | i;
+ int size = core_reg_size_from_offset(vcpu, i);
+
+ if (size < 0)
+ continue;
+
+ switch (size) {
+ case sizeof(__u32):
+ reg |= KVM_REG_SIZE_U32;
+ break;
+
+ case sizeof(__u64):
+ reg |= KVM_REG_SIZE_U64;
+ break;
+
+ case sizeof(__uint128_t):
+ reg |= KVM_REG_SIZE_U128;
+ break;
+
+ default:
+ WARN_ON(1);
continue;
+ }
if (uindices) {
- if (put_user(core_reg | i, uindices))
+ if (put_user(reg, uindices))
return -EFAULT;
uindices++;
}
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH 4/4] KVM: arm/arm64: Fix emulated ptimer irq injection
From: Marc Zyngier @ 2019-06-20 11:23 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, Dave Martin, Viresh Kumar, Julien Thierry,
James Morse, Suzuki K Poulose, kvm, kvmarm, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Andrew Jones <drjones@redhat.com>
The emulated ptimer needs to track the level changes, otherwise the
the interrupt will never get deasserted, resulting in the guest getting
stuck in an interrupt storm if it enables ptimer interrupts. This was
found with kvm-unit-tests; the ptimer tests hung as soon as interrupts
were enabled. Typical Linux guests don't have a problem as they prefer
using the virtual timer.
Fixes: bee038a674875 ("KVM: arm/arm64: Rework the timer code to use a timer_map")
Signed-off-by: Andrew Jones <drjones@redhat.com>
[Simplified the patch to res we only care about emulated timers here]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/arch_timer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 7fc272ecae16..1b1c449ceaf4 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -321,14 +321,15 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
}
}
+/* Only called for a fully emulated timer */
static void timer_emulate(struct arch_timer_context *ctx)
{
bool should_fire = kvm_timer_should_fire(ctx);
trace_kvm_timer_emulate(ctx, should_fire);
- if (should_fire) {
- kvm_timer_update_irq(ctx->vcpu, true, ctx);
+ if (should_fire != ctx->irq.level) {
+ kvm_timer_update_irq(ctx->vcpu, should_fire, ctx);
return;
}
--
2.20.1
^ permalink raw reply related
* [GIT PULL] KVM/arm fixes for 5.2-rc6
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, kvm, Suzuki K Poulose, Viresh Kumar, Julien Thierry,
kvmarm, James Morse, Dave Martin, linux-arm-kernel
Paolo, Radim,
Here's the second (and hopefully last) set of fixes for v5.2. We have
our usual timer fix (we obviously will never get it right), a memory
leak plug, a sysreg reporting fix, and an small SVE cleanup.
Please pull.
M.
The following changes since commit 623e1528d4090bd1abaf93ec46f047dee9a6fb32:
KVM: arm/arm64: Move cc/it checks under hyp's Makefile to avoid instrumentation (2019-05-24 14:53:20 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.2-2
for you to fetch changes up to e4e5a865e9a9e8e47ac1959b629e9f3ae3b062f2:
KVM: arm/arm64: Fix emulated ptimer irq injection (2019-06-19 15:47:52 +0100)
----------------------------------------------------------------
KVM/arm fixes for 5.2, take #2
- SVE cleanup killing a warning with ancient GCC versions
- Don't report non-existent system registers to userspace
- Fix memory leak when freeing the vgic ITS
- Properly lower the interrupt on the emulated physical timer
----------------------------------------------------------------
Andrew Jones (1):
KVM: arm/arm64: Fix emulated ptimer irq injection
Dave Martin (2):
KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST
KVM: arm/arm64: vgic: Fix kvm_device leak in vgic_its_destroy
Viresh Kumar (1):
KVM: arm64: Implement vq_present() as a macro
arch/arm64/kvm/guest.c | 65 +++++++++++++++++++++++++++++---------------
virt/kvm/arm/arch_timer.c | 5 ++--
virt/kvm/arm/vgic/vgic-its.c | 1 +
3 files changed, 47 insertions(+), 24 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/4] KVM: arm/arm64: vgic: Fix kvm_device leak in vgic_its_destroy
From: Marc Zyngier @ 2019-06-20 11:23 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, Dave Martin, Viresh Kumar, Julien Thierry,
James Morse, Suzuki K Poulose, kvm, kvmarm, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Dave Martin <Dave.Martin@arm.com>
kvm_device->destroy() seems to be supposed to free its kvm_device
struct, but vgic_its_destroy() is not currently doing this,
resulting in a memory leak, resulting in kmemleak reports such as
the following:
unreferenced object 0xffff800aeddfe280 (size 128):
comm "qemu-system-aar", pid 13799, jiffies 4299827317 (age 1569.844s)
[...]
backtrace:
[<00000000a08b80e2>] kmem_cache_alloc+0x178/0x208
[<00000000dcad2bd3>] kvm_vm_ioctl+0x350/0xbc0
Fix it.
Cc: Andre Przywara <andre.przywara@arm.com>
Fixes: 1085fdc68c60 ("KVM: arm64: vgic-its: Introduce new KVM ITS device")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-its.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 44ceaccb18cf..8c9fe831bce4 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -1734,6 +1734,7 @@ static void vgic_its_destroy(struct kvm_device *kvm_dev)
mutex_unlock(&its->its_lock);
kfree(its);
+ kfree(kvm_dev);/* alloc by kvm_ioctl_create_device, free by .destroy */
}
static int vgic_its_has_attr_regs(struct kvm_device *dev,
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] KVM: arm64: Implement vq_present() as a macro
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: kvm, Viresh Kumar, kvmarm, Dave Martin, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Viresh Kumar <viresh.kumar@linaro.org>
This routine is a one-liner and doesn't really need to be function and
can be implemented as a macro.
Suggested-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/guest.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 3ae2f82fca46..ae734fcfd4ea 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,13 +207,7 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
#define vq_word(vq) (((vq) - SVE_VQ_MIN) / 64)
#define vq_mask(vq) ((u64)1 << ((vq) - SVE_VQ_MIN) % 64)
-
-static bool vq_present(
- const u64 (*const vqs)[KVM_ARM64_SVE_VLS_WORDS],
- unsigned int vq)
-{
- return (*vqs)[vq_word(vq)] & vq_mask(vq);
-}
+#define vq_present(vqs, vq) ((vqs)[vq_word(vq)] & vq_mask(vq))
static int get_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
@@ -258,7 +252,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
max_vq = 0;
for (vq = SVE_VQ_MIN; vq <= SVE_VQ_MAX; ++vq)
- if (vq_present(&vqs, vq))
+ if (vq_present(vqs, vq))
max_vq = vq;
if (max_vq > sve_vq_from_vl(kvm_sve_max_vl))
@@ -272,7 +266,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
* maximum:
*/
for (vq = SVE_VQ_MIN; vq <= max_vq; ++vq)
- if (vq_present(&vqs, vq) != sve_vq_available(vq))
+ if (vq_present(vqs, vq) != sve_vq_available(vq))
return -EINVAL;
/* Can't run with no vector lengths at all: */
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH 2/4] KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, Dave Martin, Viresh Kumar, Julien Thierry,
James Morse, Suzuki K Poulose, kvm, kvmarm, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Dave Martin <Dave.Martin@arm.com>
Since commit d26c25a9d19b ("arm64: KVM: Tighten guest core register
access from userspace"), KVM_{GET,SET}_ONE_REG rejects register IDs
that do not correspond to a single underlying architectural register.
KVM_GET_REG_LIST was not changed to match however: instead, it
simply yields a list of 32-bit register IDs that together cover the
whole kvm_regs struct. This means that if userspace tries to use
the resulting list of IDs directly to drive calls to KVM_*_ONE_REG,
some of those calls will now fail.
This was not the intention. Instead, iterating KVM_*_ONE_REG over
the list of IDs returned by KVM_GET_REG_LIST should be guaranteed
to work.
This patch fixes the problem by splitting validate_core_offset()
into a backend core_reg_size_from_offset() which does all of the
work except for checking that the size field in the register ID
matches, and kvm_arm_copy_reg_indices() and num_core_regs() are
converted to use this to enumerate the valid offsets.
kvm_arm_copy_reg_indices() now also sets the register ID size field
appropriately based on the value returned, so the register ID
supplied to userspace is fully qualified for use with the register
access ioctls.
Cc: stable@vger.kernel.org
Fixes: d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/guest.c | 53 +++++++++++++++++++++++++++++++-----------
1 file changed, 40 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index ae734fcfd4ea..c8aa00179363 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -70,10 +70,8 @@ static u64 core_reg_offset_from_id(u64 id)
return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
}
-static int validate_core_offset(const struct kvm_vcpu *vcpu,
- const struct kvm_one_reg *reg)
+static int core_reg_size_from_offset(const struct kvm_vcpu *vcpu, u64 off)
{
- u64 off = core_reg_offset_from_id(reg->id);
int size;
switch (off) {
@@ -103,8 +101,7 @@ static int validate_core_offset(const struct kvm_vcpu *vcpu,
return -EINVAL;
}
- if (KVM_REG_SIZE(reg->id) != size ||
- !IS_ALIGNED(off, size / sizeof(__u32)))
+ if (!IS_ALIGNED(off, size / sizeof(__u32)))
return -EINVAL;
/*
@@ -115,6 +112,21 @@ static int validate_core_offset(const struct kvm_vcpu *vcpu,
if (vcpu_has_sve(vcpu) && core_reg_offset_is_vreg(off))
return -EINVAL;
+ return size;
+}
+
+static int validate_core_offset(const struct kvm_vcpu *vcpu,
+ const struct kvm_one_reg *reg)
+{
+ u64 off = core_reg_offset_from_id(reg->id);
+ int size = core_reg_size_from_offset(vcpu, off);
+
+ if (size < 0)
+ return -EINVAL;
+
+ if (KVM_REG_SIZE(reg->id) != size)
+ return -EINVAL;
+
return 0;
}
@@ -447,19 +459,34 @@ static int copy_core_reg_indices(const struct kvm_vcpu *vcpu,
{
unsigned int i;
int n = 0;
- const u64 core_reg = KVM_REG_ARM64 | KVM_REG_SIZE_U64 | KVM_REG_ARM_CORE;
for (i = 0; i < sizeof(struct kvm_regs) / sizeof(__u32); i++) {
- /*
- * The KVM_REG_ARM64_SVE regs must be used instead of
- * KVM_REG_ARM_CORE for accessing the FPSIMD V-registers on
- * SVE-enabled vcpus:
- */
- if (vcpu_has_sve(vcpu) && core_reg_offset_is_vreg(i))
+ u64 reg = KVM_REG_ARM64 | KVM_REG_ARM_CORE | i;
+ int size = core_reg_size_from_offset(vcpu, i);
+
+ if (size < 0)
+ continue;
+
+ switch (size) {
+ case sizeof(__u32):
+ reg |= KVM_REG_SIZE_U32;
+ break;
+
+ case sizeof(__u64):
+ reg |= KVM_REG_SIZE_U64;
+ break;
+
+ case sizeof(__uint128_t):
+ reg |= KVM_REG_SIZE_U128;
+ break;
+
+ default:
+ WARN_ON(1);
continue;
+ }
if (uindices) {
- if (put_user(core_reg | i, uindices))
+ if (put_user(reg, uindices))
return -EFAULT;
uindices++;
}
--
2.20.1
^ permalink raw reply related
* [GIT PULL] KVM/arm fixes for 5.2-rc6
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: kvm, Viresh Kumar, kvmarm, Dave Martin, linux-arm-kernel
Paolo, Radim,
Here's the second (and hopefully last) set of fixes for v5.2. We have
our usual timer fix (we obviously will never get it right), a memory
leak plug, a sysreg reporting fix, and an small SVE cleanup.
Please pull.
M.
The following changes since commit 623e1528d4090bd1abaf93ec46f047dee9a6fb32:
KVM: arm/arm64: Move cc/it checks under hyp's Makefile to avoid instrumentation (2019-05-24 14:53:20 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.2-2
for you to fetch changes up to e4e5a865e9a9e8e47ac1959b629e9f3ae3b062f2:
KVM: arm/arm64: Fix emulated ptimer irq injection (2019-06-19 15:47:52 +0100)
----------------------------------------------------------------
KVM/arm fixes for 5.2, take #2
- SVE cleanup killing a warning with ancient GCC versions
- Don't report non-existent system registers to userspace
- Fix memory leak when freeing the vgic ITS
- Properly lower the interrupt on the emulated physical timer
----------------------------------------------------------------
Andrew Jones (1):
KVM: arm/arm64: Fix emulated ptimer irq injection
Dave Martin (2):
KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST
KVM: arm/arm64: vgic: Fix kvm_device leak in vgic_its_destroy
Viresh Kumar (1):
KVM: arm64: Implement vq_present() as a macro
arch/arm64/kvm/guest.c | 65 +++++++++++++++++++++++++++++---------------
virt/kvm/arm/arch_timer.c | 5 ++--
virt/kvm/arm/vgic/vgic-its.c | 1 +
3 files changed, 47 insertions(+), 24 deletions(-)
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* [PATCH 1/4] KVM: arm64: Implement vq_present() as a macro
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, Dave Martin, Viresh Kumar, Julien Thierry,
James Morse, Suzuki K Poulose, kvm, kvmarm, linux-arm-kernel
In-Reply-To: <20190620112301.138137-1-marc.zyngier@arm.com>
From: Viresh Kumar <viresh.kumar@linaro.org>
This routine is a one-liner and doesn't really need to be function and
can be implemented as a macro.
Suggested-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/guest.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 3ae2f82fca46..ae734fcfd4ea 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -207,13 +207,7 @@ static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
#define vq_word(vq) (((vq) - SVE_VQ_MIN) / 64)
#define vq_mask(vq) ((u64)1 << ((vq) - SVE_VQ_MIN) % 64)
-
-static bool vq_present(
- const u64 (*const vqs)[KVM_ARM64_SVE_VLS_WORDS],
- unsigned int vq)
-{
- return (*vqs)[vq_word(vq)] & vq_mask(vq);
-}
+#define vq_present(vqs, vq) ((vqs)[vq_word(vq)] & vq_mask(vq))
static int get_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
{
@@ -258,7 +252,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
max_vq = 0;
for (vq = SVE_VQ_MIN; vq <= SVE_VQ_MAX; ++vq)
- if (vq_present(&vqs, vq))
+ if (vq_present(vqs, vq))
max_vq = vq;
if (max_vq > sve_vq_from_vl(kvm_sve_max_vl))
@@ -272,7 +266,7 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
* maximum:
*/
for (vq = SVE_VQ_MIN; vq <= max_vq; ++vq)
- if (vq_present(&vqs, vq) != sve_vq_available(vq))
+ if (vq_present(vqs, vq) != sve_vq_available(vq))
return -EINVAL;
/* Can't run with no vector lengths at all: */
--
2.20.1
^ permalink raw reply related
* [GIT PULL] KVM/arm fixes for 5.2-rc6
From: Marc Zyngier @ 2019-06-20 11:22 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Andrew Jones, Dave Martin, Viresh Kumar, Julien Thierry,
James Morse, Suzuki K Poulose, kvm, kvmarm, linux-arm-kernel
Paolo, Radim,
Here's the second (and hopefully last) set of fixes for v5.2. We have
our usual timer fix (we obviously will never get it right), a memory
leak plug, a sysreg reporting fix, and an small SVE cleanup.
Please pull.
M.
The following changes since commit 623e1528d4090bd1abaf93ec46f047dee9a6fb32:
KVM: arm/arm64: Move cc/it checks under hyp's Makefile to avoid instrumentation (2019-05-24 14:53:20 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-for-5.2-2
for you to fetch changes up to e4e5a865e9a9e8e47ac1959b629e9f3ae3b062f2:
KVM: arm/arm64: Fix emulated ptimer irq injection (2019-06-19 15:47:52 +0100)
----------------------------------------------------------------
KVM/arm fixes for 5.2, take #2
- SVE cleanup killing a warning with ancient GCC versions
- Don't report non-existent system registers to userspace
- Fix memory leak when freeing the vgic ITS
- Properly lower the interrupt on the emulated physical timer
----------------------------------------------------------------
Andrew Jones (1):
KVM: arm/arm64: Fix emulated ptimer irq injection
Dave Martin (2):
KVM: arm64: Filter out invalid core register IDs in KVM_GET_REG_LIST
KVM: arm/arm64: vgic: Fix kvm_device leak in vgic_its_destroy
Viresh Kumar (1):
KVM: arm64: Implement vq_present() as a macro
arch/arm64/kvm/guest.c | 65 +++++++++++++++++++++++++++++---------------
virt/kvm/arm/arch_timer.c | 5 ++--
virt/kvm/arm/vgic/vgic-its.c | 1 +
3 files changed, 47 insertions(+), 24 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation
From: Milan Broz @ 2019-06-20 11:22 UTC (permalink / raw)
To: Ard Biesheuvel, linux-crypto
Cc: Herbert Xu, Eric Biggers, dm-devel, linux-fscrypt,
Gilad Ben-Yossef
In-Reply-To: <20190619162921.12509-1-ard.biesheuvel@linaro.org>
On 19/06/2019 18:29, Ard Biesheuvel wrote:
> This series creates an ESSIV template that produces a skcipher or AEAD
> transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
> (or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
> encapsulated sync or async skcipher/aead by passing through all operations,
> while using the cipher/shash pair to transform the input IV into an ESSIV
> output IV.
>
> This matches what both users of ESSIV in the kernel do, and so it is proposed
> as a replacement for those, in patches #2 and #4.
>
> This code has been tested using the fscrypt test suggested by Eric
> (generic/549), as well as the mode-test script suggested by Milan for
> the dm-crypt case. I also tested the aead case in a virtual machine,
> but it definitely needs some wider testing from the dm-crypt experts.
>
> Changes since v2:
> - fixed a couple of bugs that snuck in after I'd done the bulk of my
> testing
> - some cosmetic tweaks to the ESSIV template skcipher setkey function
> to align it with the aead one
> - add a test case for essiv(cbc(aes),aes,sha256)
> - add an accelerated implementation for arm64 that combines the IV
> derivation and the actual en/decryption in a single asm routine
I run tests for the whole patchset, including some older scripts and seems
it works for dm-crypt now.
For the new CRYPTO_ESSIV option - dm-crypt must unconditionally
select it (we rely on all IV generators availability in userspace),
but that's already done in patch 4.
Thanks,
Milan
^ permalink raw reply
* Re: [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation
From: Milan Broz @ 2019-06-20 11:22 UTC (permalink / raw)
To: Ard Biesheuvel, linux-crypto
Cc: Gilad Ben-Yossef, dm-devel, linux-fscrypt, Herbert Xu,
Eric Biggers
In-Reply-To: <20190619162921.12509-1-ard.biesheuvel@linaro.org>
On 19/06/2019 18:29, Ard Biesheuvel wrote:
> This series creates an ESSIV template that produces a skcipher or AEAD
> transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
> (or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
> encapsulated sync or async skcipher/aead by passing through all operations,
> while using the cipher/shash pair to transform the input IV into an ESSIV
> output IV.
>
> This matches what both users of ESSIV in the kernel do, and so it is proposed
> as a replacement for those, in patches #2 and #4.
>
> This code has been tested using the fscrypt test suggested by Eric
> (generic/549), as well as the mode-test script suggested by Milan for
> the dm-crypt case. I also tested the aead case in a virtual machine,
> but it definitely needs some wider testing from the dm-crypt experts.
>
> Changes since v2:
> - fixed a couple of bugs that snuck in after I'd done the bulk of my
> testing
> - some cosmetic tweaks to the ESSIV template skcipher setkey function
> to align it with the aead one
> - add a test case for essiv(cbc(aes),aes,sha256)
> - add an accelerated implementation for arm64 that combines the IV
> derivation and the actual en/decryption in a single asm routine
I run tests for the whole patchset, including some older scripts and seems
it works for dm-crypt now.
For the new CRYPTO_ESSIV option - dm-crypt must unconditionally
select it (we rely on all IV generators availability in userspace),
but that's already done in patch 4.
Thanks,
Milan
^ permalink raw reply
* [PATCH RESEND] mfd: cs5535-mfd: remove ifdef OLPC noise
From: Lubomir Rintel @ 2019-06-20 11:19 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-kernel, Lubomir Rintel
<asm/olpc.h> provides machine_is_olpc() stub for CONFIG_OLPC=n,
compiler should just optimize the unneeded bits away.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
drivers/mfd/cs5535-mfd.c | 24 +++++++-----------------
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/cs5535-mfd.c b/drivers/mfd/cs5535-mfd.c
index 0b49940c490e..f1825c0ccbd0 100644
--- a/drivers/mfd/cs5535-mfd.c
+++ b/drivers/mfd/cs5535-mfd.c
@@ -100,22 +100,10 @@ static struct mfd_cell cs5535_mfd_cells[] = {
},
};
-#ifdef CONFIG_OLPC
-static void cs5535_clone_olpc_cells(void)
-{
- static const char *acpi_clones[] = {
- "olpc-xo1-pm-acpi",
- "olpc-xo1-sci-acpi"
- };
-
- if (!machine_is_olpc())
- return;
-
- mfd_clone_cell("cs5535-acpi", acpi_clones, ARRAY_SIZE(acpi_clones));
-}
-#else
-static void cs5535_clone_olpc_cells(void) { }
-#endif
+static const char *olpc_acpi_clones[] = {
+ "olpc-xo1-pm-acpi",
+ "olpc-xo1-sci-acpi"
+};
static int cs5535_mfd_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
@@ -145,7 +133,9 @@ static int cs5535_mfd_probe(struct pci_dev *pdev,
dev_err(&pdev->dev, "MFD add devices failed: %d\n", err);
goto err_disable;
}
- cs5535_clone_olpc_cells();
+
+ if (machine_is_olpc())
+ mfd_clone_cell("cs5535-acpi", olpc_acpi_clones, ARRAY_SIZE(olpc_acpi_clones));
dev_info(&pdev->dev, "%zu devices registered.\n",
ARRAY_SIZE(cs5535_mfd_cells));
--
2.21.0
^ permalink raw reply related
* [PATCH v3 9/9] conf/machine: add support for rk1808
From: ayaka @ 2019-06-20 11:19 UTC (permalink / raw)
To: yocto; +Cc: Randy Li
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
From: Randy Li <randy.li@rock-chips.com>
RK1808 is an ARM processor with a neural network process unit,
which can acceleration the inference of deep learning.
Signed-off-by: Randy Li <randy.li@rock-chips.com>
---
conf/machine/include/rk1808.inc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 conf/machine/include/rk1808.inc
diff --git a/conf/machine/include/rk1808.inc b/conf/machine/include/rk1808.inc
new file mode 100644
index 0000000..6edd67c
--- /dev/null
+++ b/conf/machine/include/rk1808.inc
@@ -0,0 +1,17 @@
+# Copyright (C) SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk1808"
+
+require conf/machine/include/tune-cortexa35.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
--
2.21.0
^ permalink raw reply related
* [PATCH v3 8/9] conf/machine: add support for rk3308
From: ayaka @ 2019-06-20 11:19 UTC (permalink / raw)
To: yocto; +Cc: Randy 'ayaka' Li
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
From: Randy 'ayaka' Li <ayaka@soulik.info>
RK3308 is a high-performance quad-core application processor
designed for intelligent voice interaction.
Signed-off-by: Randy 'ayaka' Li <ayaka@soulik.info>
---
conf/machine/include/rk3308.inc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 conf/machine/include/rk3308.inc
diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc
new file mode 100644
index 0000000..81e4def
--- /dev/null
+++ b/conf/machine/include/rk3308.inc
@@ -0,0 +1,17 @@
+# Copyright (C) SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3308"
+
+require conf/machine/include/tune-cortexa35.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
--
2.21.0
^ permalink raw reply related
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.