* Re: [CRASH] crypto: virtio: crash when modprobing tcrypt on 5.5-rc7 / next-20200122
From: LABBE Corentin @ 2020-02-20 19:15 UTC (permalink / raw)
To: arei.gonglei
Cc: jasowang, herbert, davem, virtualization, linux-crypto,
linux-kernel, mst
In-Reply-To: <20200204041419-mutt-send-email-mst@kernel.org>
On Tue, Feb 04, 2020 at 04:15:22AM -0500, Michael S. Tsirkin wrote:
> On Thu, Jan 23, 2020 at 11:10:00AM +0100, LABBE Corentin wrote:
> > Hello
> >
> > When modprobing tcrypt on qemu 4.1.0 I get a kernel panic on 5.5-rc7 and next-20200122
> > qemu is started by:
> > /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic -net nic,model=e1000,macaddr=52:54:00:12:34:58 -net tap -m 512 -monitor none -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-pci,id=crypto0,cryptodev=cryptodev0 -append 'console=ttyS0 root=/dev/ram0 ip=dhcp' -kernel /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/kernel/bzImage -initrd /var/lib/lava/dispatcher/tmp/41332/deployimages-td18675m/ramdisk/rootfs.cpio.gz -drive format=qcow2,file=/var/lib/lava/dispatcher/tmp/41332/apply-overlay-guest-icy4k1ol/lava-guest.qcow2,media=disk,if=ide,id=lavatest
> >
> > [ 112.771925] general protection fault: 0000 [#1] SMP PTI
> > [ 112.772686] CPU: 0 PID: 126 Comm: virtio0-engine Not tainted 5.5.0-rc7+ #1
> > [ 112.773576] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31 04/01/2014
> > [ 112.775319] RIP: 0010:sg_next+0x0/0x20
> > [ 112.775821] Code: cc cc cc cc cc cc cc cc cc cc c7 47 10 00 00 00 00 89 57 0c 48 89 37 89 4f 08 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 <f6> 07 02 75 17 48 8b 57 20 48 8d 47 20 48 89 d1 48 83 e1 fc 83 e2
> > [ 112.778330] RSP: 0018:ffffa92440237d90 EFLAGS: 00010006
> > [ 112.779071] RAX: fefefefe00000000 RBX: 000000000000000a RCX: fefefefe00000000
> > [ 112.780081] RDX: 0000000000000001 RSI: ffff9b19da1a2180 RDI: fefefefe00000000
> > [ 112.781081] RBP: ffff9b19da1a2198 R08: ffff9b19dfb24ee8 R09: 0000000000000a20
> > [ 112.782079] R10: ffff9b19da125010 R11: 0000000000000000 R12: ffff9b19da1a21b8
> > [ 112.783079] R13: 0000000000000003 R14: ffff9b19da1a2180 R15: 0000000000000004
> > [ 112.784077] FS: 0000000000000000(0000) GS:ffff9b19de400000(0000) knlGS:0000000000000000
> > [ 112.785202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 112.786030] CR2: 00007f18a157b050 CR3: 000000001040a004 CR4: 0000000000060ef0
> > [ 112.787034] Call Trace:
> > [ 112.787393] virtqueue_add_sgs+0x4c/0x90
> > [ 112.787998] virtio_crypto_skcipher_crypt_req+0x310/0x3e0
> > [ 112.788817] crypto_pump_work+0x10c/0x240
> > [ 112.789420] ? __kthread_init_worker+0x50/0x50
> > [ 112.790082] kthread_worker_fn+0x89/0x180
> > [ 112.790690] kthread+0x10e/0x130
> > [ 112.791182] ? kthread_park+0x80/0x80
> > [ 112.791736] ret_from_fork+0x35/0x40
> > [ 112.792282] Modules linked in: cts lzo salsa20_generic camellia_x86_64 camellia_generic fcrypt pcbc tgr192 anubis wp512 khazad tea michael_mic arc4 cast6_generic cast5_generic cast_common deflate sha512_ssse3 sha512_generic cfb ofb serpent_sse2_x86_64 serpent_generic lrw twofish_x86_64_3way twofish_x86_64 crypto_simd cryptd glue_helper twofish_generic twofish_common blowfish_x86_64 blowfish_generic blowfish_common md4 tcrypt(+)
> > [ 112.797652] ---[ end trace 4a8142d4a08c2518 ]---
> > [ 112.798320] RIP: 0010:sg_next+0x0/0x20
> > [ 112.798865] Code: cc cc cc cc cc cc cc cc cc cc c7 47 10 00 00 00 00 89 57 0c 48 89 37 89 4f 08 c3 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 <f6> 07 02 75 17 48 8b 57 20 48 8d 47 20 48 89 d1 48 83 e1 fc 83 e2
> > [ 112.801452] RSP: 0018:ffffa92440237d90 EFLAGS: 00010006
> > [ 112.802189] RAX: fefefefe00000000 RBX: 000000000000000a RCX: fefefefe00000000
> > [ 112.803190] RDX: 0000000000000001 RSI: ffff9b19da1a2180 RDI: fefefefe00000000
> > [ 112.804192] RBP: ffff9b19da1a2198 R08: ffff9b19dfb24ee8 R09: 0000000000000a20
> > [ 112.805201] R10: ffff9b19da125010 R11: 0000000000000000 R12: ffff9b19da1a21b8
> > [ 112.806195] R13: 0000000000000003 R14: ffff9b19da1a2180 R15: 0000000000000004
> > [ 112.807222] FS: 0000000000000000(0000) GS:ffff9b19de400000(0000) knlGS:0000000000000000
> > [ 112.808352] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 112.809169] CR2: 00007f18a157b050 CR3: 000000001040a004 CR4: 0000000000060ef0
> >
> > I have tested also 5.4.14
> > and I got random freeze with:
> > qemu-system-x86_64: virtio: zero sized buffers are not allowed
> >
> > Regards
>
> Cc: Gonglei <arei.gonglei@huawei.com>
>
Hello Gonglei
Any plan to fix the driver ? It is broken since its introduction.
Regards
^ permalink raw reply
* Re: [PATCH v2] KVM: x86: enable dirty log gradually in small chunks
From: Peter Xu @ 2020-02-20 19:17 UTC (permalink / raw)
To: Jay Zhou
Cc: kvm, pbonzini, wangxinxin.wang, weidong.huang,
sean.j.christopherson, liu.jinsong
In-Reply-To: <20200220042828.27464-1-jianjay.zhou@huawei.com>
On Thu, Feb 20, 2020 at 12:28:28PM +0800, Jay Zhou wrote:
> It could take kvm->mmu_lock for an extended period of time when
> enabling dirty log for the first time. The main cost is to clear
> all the D-bits of last level SPTEs. This situation can benefit from
> manual dirty log protect as well, which can reduce the mmu_lock
> time taken. The sequence is like this:
>
> 1. Initialize all the bits of the dirty bitmap to 1 when enabling
> dirty log for the first time
> 2. Only write protect the huge pages
> 3. KVM_GET_DIRTY_LOG returns the dirty bitmap info
> 4. KVM_CLEAR_DIRTY_LOG will clear D-bit for each of the leaf level
> SPTEs gradually in small chunks
>
> Under the Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz environment,
> I did some tests with a 128G windows VM and counted the time taken
> of memory_global_dirty_log_start, here is the numbers:
>
> VM Size Before After optimization
> 128G 460ms 10ms
>
> Signed-off-by: Jay Zhou <jianjay.zhou@huawei.com>
> ---
> v2:
> * add new bit to KVM_ENABLE_CAP for KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 [Paolo]
> * support non-PML path [Peter]
> * delete the unnecessary ifdef and make the initialization of bitmap
> more clear [Sean]
> * document the new bits and tweak the testcase
>
> Documentation/virt/kvm/api.rst | 23 +++++++++++++++++------
> arch/x86/kvm/mmu/mmu.c | 8 ++++++--
> arch/x86/kvm/vmx/vmx.c | 3 ++-
> include/linux/kvm_host.h | 7 ++++++-
> tools/testing/selftests/kvm/dirty_log_test.c | 3 ++-
> virt/kvm/kvm_main.c | 25 ++++++++++++++++++-------
> 6 files changed, 51 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 97a72a5..1afd310 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -1267,9 +1267,11 @@ pages in the host.
> The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and
> KVM_MEM_READONLY. The former can be set to instruct KVM to keep track of
> writes to memory within the slot. See KVM_GET_DIRTY_LOG ioctl to know how to
> -use it. The latter can be set, if KVM_CAP_READONLY_MEM capability allows it,
> -to make a new slot read-only. In this case, writes to this memory will be
> -posted to userspace as KVM_EXIT_MMIO exits.
> +use it. It will be different if the KVM_DIRTY_LOG_INITIALLY_SET flag of
> +KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is set. For more information, see the
> +description of the capability. The latter can be set, if KVM_CAP_READONLY_MEM
> +capability allows it, to make a new slot read-only. In this case, writes to
> +this memory will be posted to userspace as KVM_EXIT_MMIO exits.
Not sure about others, but my own preference is that we keep this part
untouched... The changed document could be even more confusing to me...
>
> When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of
> the memory region are automatically reflected into the guest. For example, an
> @@ -5704,10 +5706,19 @@ and injected exceptions.
> :Architectures: x86, arm, arm64, mips
> :Parameters: args[0] whether feature should be enabled or not
>
> -With this capability enabled, KVM_GET_DIRTY_LOG will not automatically
> +Valid flags are::
> +
> + #define KVM_DIRTY_LOG_MANUAL_PROTECT (1 << 0)
> + #define KVM_DIRTY_LOG_INITIALLY_SET (1 << 1)
> +
> +With KVM_DIRTY_LOG_MANUAL_PROTECT set, KVM_GET_DIRTY_LOG will not automatically
> clear and write-protect all pages that are returned as dirty.
> Rather, userspace will have to do this operation separately using
> -KVM_CLEAR_DIRTY_LOG.
> +KVM_CLEAR_DIRTY_LOG. With KVM_DIRTY_LOG_INITIALLY_SET set, all the bits of
> +the dirty bitmap will be initialized to 1 when created, dirty logging will be
> +enabled gradually in small chunks using KVM_CLEAR_DIRTY_LOG ioctl. However,
> +the KVM_DIRTY_LOG_INITIALLY_SET depends on KVM_DIRTY_LOG_MANUAL_PROTECT, it
> +can not be set individually and supports x86 only for now.
Need s/KVM_DIRTY_LOG_MANUAL_PROTECT/KVM_DIRTY_LOG_MANUAL_PROTECT2/?
>
> At the cost of a slightly more complicated operation, this provides better
> scalability and responsiveness for two reasons. First,
> @@ -5716,7 +5727,7 @@ than requiring to sync a full memslot; this ensures that KVM does not
> take spinlocks for an extended period of time. Second, in some cases a
> large amount of time can pass between a call to KVM_GET_DIRTY_LOG and
> userspace actually using the data in the page. Pages can be modified
> -during this time, which is inefficint for both the guest and userspace:
> +during this time, which is inefficient for both the guest and userspace:
> the guest will incur a higher penalty due to write protection faults,
> while userspace can see false reports of dirty pages. Manual reprotection
> helps reducing this time, improving guest performance and reducing the
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 87e9ba2..f9c120e 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -5865,8 +5865,12 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
> bool flush;
>
> spin_lock(&kvm->mmu_lock);
> - flush = slot_handle_all_level(kvm, memslot, slot_rmap_write_protect,
> - false);
> + if (kvm->manual_dirty_log_protect & KVM_DIRTY_LOG_INITIALLY_SET)
> + flush = slot_handle_large_level(kvm, memslot,
> + slot_rmap_write_protect, false);
> + else
> + flush = slot_handle_all_level(kvm, memslot,
> + slot_rmap_write_protect, false);
> spin_unlock(&kvm->mmu_lock);
>
> /*
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 3be25ec..fcc585a 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -7201,7 +7201,8 @@ static void vmx_sched_in(struct kvm_vcpu *vcpu, int cpu)
> static void vmx_slot_enable_log_dirty(struct kvm *kvm,
> struct kvm_memory_slot *slot)
> {
> - kvm_mmu_slot_leaf_clear_dirty(kvm, slot);
> + if (!(kvm->manual_dirty_log_protect & KVM_DIRTY_LOG_INITIALLY_SET))
> + kvm_mmu_slot_leaf_clear_dirty(kvm, slot);
> kvm_mmu_slot_largepage_remove_write_access(kvm, slot);
> }
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index e89eb67..a555b52 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -39,6 +39,11 @@
> #define KVM_MAX_VCPU_ID KVM_MAX_VCPUS
> #endif
>
> +#define KVM_DIRTY_LOG_MANUAL_PROTECT (1 << 0)
> +#define KVM_DIRTY_LOG_INITIALLY_SET (1 << 1)
> +#define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT | \
> + KVM_DIRTY_LOG_INITIALLY_SET)
> +
> /*
> * The bit 16 ~ bit 31 of kvm_memory_region::flags are internally used
> * in kvm, other bits are visible for userspace which are defined in
> @@ -493,7 +498,7 @@ struct kvm {
> #endif
> long tlbs_dirty;
> struct list_head devices;
> - bool manual_dirty_log_protect;
> + u64 manual_dirty_log_protect;
> struct dentry *debugfs_dentry;
> struct kvm_stat_data **debugfs_stat_data;
> struct srcu_struct srcu;
> diff --git a/tools/testing/selftests/kvm/dirty_log_test.c b/tools/testing/selftests/kvm/dirty_log_test.c
> index 5614222..2a493c1 100644
> --- a/tools/testing/selftests/kvm/dirty_log_test.c
> +++ b/tools/testing/selftests/kvm/dirty_log_test.c
> @@ -317,10 +317,11 @@ static void run_test(enum vm_guest_mode mode, unsigned long iterations,
> host_bmap_track = bitmap_alloc(host_num_pages);
>
> #ifdef USE_CLEAR_DIRTY_LOG
> + int ret = kvm_check_cap(KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2);
> struct kvm_enable_cap cap = {};
>
> cap.cap = KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2;
> - cap.args[0] = 1;
> + cap.args[0] = ret;
You enabled the initial-all-set but didn't really check it, so it
didn't help much from the testcase pov... I'd suggest you drop this
change, and you can work on top after this patch can be accepted.
(Not to mention the original test actually verified that we don't
break, which seems good..)
> vm_enable_cap(vm, &cap);
> #endif
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 70f03ce..f2631d0 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -862,7 +862,7 @@ static int kvm_vm_release(struct inode *inode, struct file *filp)
> * Allocation size is twice as large as the actual dirty bitmap size.
> * See x86's kvm_vm_ioctl_get_dirty_log() why this is needed.
> */
> -static int kvm_create_dirty_bitmap(struct kvm_memory_slot *memslot)
> +static int kvm_alloc_dirty_bitmap(struct kvm_memory_slot *memslot)
This change seems irrelevant..
> {
> unsigned long dirty_bytes = 2 * kvm_dirty_bitmap_bytes(memslot);
>
> @@ -1094,8 +1094,11 @@ int __kvm_set_memory_region(struct kvm *kvm,
>
> /* Allocate page dirty bitmap if needed */
> if ((new.flags & KVM_MEM_LOG_DIRTY_PAGES) && !new.dirty_bitmap) {
> - if (kvm_create_dirty_bitmap(&new) < 0)
> + if (kvm_alloc_dirty_bitmap(&new))
Same here.
> goto out_free;
> +
> + if (kvm->manual_dirty_log_protect & KVM_DIRTY_LOG_INITIALLY_SET)
(Maybe time to introduce a helper to shorten this check. :)
> + bitmap_set(new.dirty_bitmap, 0, new.npages);
> }
>
> slots = kvzalloc(sizeof(struct kvm_memslots), GFP_KERNEL_ACCOUNT);
> @@ -1255,7 +1258,7 @@ int kvm_get_dirty_log_protect(struct kvm *kvm,
>
> n = kvm_dirty_bitmap_bytes(memslot);
> *flush = false;
> - if (kvm->manual_dirty_log_protect) {
> + if (kvm->manual_dirty_log_protect & KVM_DIRTY_LOG_MANUAL_PROTECT) {
Can also introduce a helper for this too.
Side note: logically this line doesn't need a change, because bit 1
depends on bit 0 so if (kvm->manual_dirty_log_protect) it means bit 0
must be set.
> /*
> * Unlike kvm_get_dirty_log, we always return false in *flush,
> * because no flush is needed until KVM_CLEAR_DIRTY_LOG. There
> @@ -3310,9 +3313,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> case KVM_CAP_IOEVENTFD_ANY_LENGTH:
> case KVM_CAP_CHECK_EXTENSION_VM:
> case KVM_CAP_ENABLE_CAP_VM:
> -#ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT
> - case KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2:
> -#endif
> return 1;
> #ifdef CONFIG_KVM_MMIO
> case KVM_CAP_COALESCED_MMIO:
> @@ -3320,6 +3320,10 @@ static long kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> case KVM_CAP_COALESCED_PIO:
> return 1;
> #endif
> +#ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT
> + case KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2:
> + return KVM_DIRTY_LOG_MANUAL_CAPS;
> +#endif
> #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
> case KVM_CAP_IRQ_ROUTING:
> return KVM_MAX_IRQ_ROUTES;
> @@ -3348,7 +3352,14 @@ static int kvm_vm_ioctl_enable_cap_generic(struct kvm *kvm,
> switch (cap->cap) {
> #ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT
> case KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2:
> - if (cap->flags || (cap->args[0] & ~1))
> + if (cap->flags ||
> + (cap->args[0] & ~KVM_DIRTY_LOG_MANUAL_CAPS) ||
> + /* The capability of KVM_DIRTY_LOG_INITIALLY_SET depends
> + * on KVM_DIRTY_LOG_MANUAL_PROTECT, it should not be
> + * set individually
> + */
> + ((cap->args[0] & KVM_DIRTY_LOG_MANUAL_CAPS) ==
> + KVM_DIRTY_LOG_INITIALLY_SET))
How about something easier to read? :)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 70f03ce0e5c1..9dfbab2a9929 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3348,7 +3348,10 @@ static int kvm_vm_ioctl_enable_cap_generic(struct kvm *kvm,
switch (cap->cap) {
#ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT
case KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2:
- if (cap->flags || (cap->args[0] & ~1))
+ if (cap->flags || (cap->args[0] & ~3))
+ return -EINVAL;
+ /* Allow 00, 01, and 11. */
+ if (cap->args[0] == KVM_DIRTY_LOG_INITIALLY_SET)
return -EINVAL;
kvm->manual_dirty_log_protect = cap->args[0];
return 0;
Otherwise it looks good to me!
Thanks,
--
Peter Xu
^ permalink raw reply related
* [zeus/master][PATCH 1/9] packagegroup-arago-cross-canadian: deprecate in favor of upstream packagegroup-cross-canadian
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
Upstream meta-environment already provides standard site-config and version
files, keep our own environment-setup for now.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
...d => packagegroup-cross-canadian.bbappend} | 0
.../recipes-core/meta/meta-toolchain-arago.bb | 8 +-------
.../packagegroup-arago-cross-canadian.bb | 20 -------------------
3 files changed, 1 insertion(+), 27 deletions(-)
rename meta-arago-distro/recipes-core/packagegroups/{packagegroup-arago-cross-canadian.bbappend => packagegroup-cross-canadian.bbappend} (100%)
delete mode 100644 meta-arago-extras/recipes-core/packagegroups/packagegroup-arago-cross-canadian.bb
diff --git a/meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-cross-canadian.bbappend b/meta-arago-distro/recipes-core/packagegroups/packagegroup-cross-canadian.bbappend
similarity index 100%
rename from meta-arago-distro/recipes-core/packagegroups/packagegroup-arago-cross-canadian.bbappend
rename to meta-arago-distro/recipes-core/packagegroups/packagegroup-cross-canadian.bbappend
diff --git a/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb b/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb
index 09678348..5a48d3e0 100644
--- a/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb
+++ b/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb
@@ -1,6 +1,6 @@
TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-arago-sdk-host"
TOOLCHAIN_HOST_TASK += "nativesdk-buildtools-perl-dummy"
-TOOLCHAIN_HOST_TASK += "packagegroup-arago-cross-canadian-${MACHINE}"
+TOOLCHAIN_HOST_TASK += "packagegroup-cross-canadian-${MACHINE}"
TOOLCHAIN_TARGET_TASK ?= "packagegroup-arago-standalone-sdk-target"
TOOLCHAIN_SUFFIX ?= "-sdk"
TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-${ARMPKGARCH}-${TARGET_OS}${TOOLCHAIN_SUFFIX}"
@@ -113,14 +113,8 @@ arago_sdk_fixup () {
}
fakeroot create_sdk_files() {
- # Setup site file for external use
- toolchain_create_sdk_siteconfig ${SDK_OUTPUT}/${SDKPATH}/site-config-${REAL_MULTIMACH_TARGET_SYS}
-
toolchain_create_sdk_env_script ${SDK_OUTPUT}/${SDKPATH}/environment-setup
- # Add version information
- toolchain_create_sdk_version ${SDK_OUTPUT}/${SDKPATH}/version-${REAL_MULTIMACH_TARGET_SYS}
-
cp ${COREBASE}/scripts/relocate_sdk.py ${SDK_OUTPUT}/${SDKPATH}/
# Replace the ##DEFAULT_INSTALL_DIR## with the correct pattern.
diff --git a/meta-arago-extras/recipes-core/packagegroups/packagegroup-arago-cross-canadian.bb b/meta-arago-extras/recipes-core/packagegroups/packagegroup-arago-cross-canadian.bb
deleted file mode 100644
index b89c5d01..00000000
--- a/meta-arago-extras/recipes-core/packagegroups/packagegroup-arago-cross-canadian.bb
+++ /dev/null
@@ -1,20 +0,0 @@
-SUMMARY = "Host Arago SDK package for cross canadian toolchain"
-PN = "packagegroup-arago-cross-canadian-${MACHINE}"
-PR = "r7"
-
-inherit cross-canadian packagegroup
-
-PACKAGEGROUP_DISABLE_COMPLEMENTARY = "1"
-
-# Use indirection to stop these being expanded prematurely
-BINUTILS = "binutils-cross-canadian-${TRANSLATED_TARGET_ARCH}"
-GCC = "gcc-cross-canadian-${TRANSLATED_TARGET_ARCH}"
-GDB = "gdb-cross-canadian-${TRANSLATED_TARGET_ARCH}"
-
-RDEPENDS_${PN} = "\
- ${@all_multilib_tune_values(d, 'BINUTILS')} \
- ${@all_multilib_tune_values(d, 'GCC')} \
- ${@all_multilib_tune_values(d, 'GDB')} \
- "
-
-# meta-environment-${MACHINE}
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 2/9] nativesdk-packagegroup-arago-sdk-host: deprecate in favor of upstream nativesdk-packagegroup-sdk-host
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
Upstream nativesdk-packagegroup-sdk-host installs most host tools, but few more
that we require should be added in nativesdk-packagegroup-arago-tisdk-host
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
.../recipes-core/meta/meta-toolchain-arago.bb | 2 +-
.../nativesdk-packagegroup-arago-sdk-host.bb | 21 -------------------
...nativesdk-packagegroup-arago-tisdk-host.bb | 5 ++++-
3 files changed, 5 insertions(+), 23 deletions(-)
delete mode 100644 meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bb
diff --git a/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb b/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb
index 5a48d3e0..6f55cca6 100644
--- a/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb
+++ b/meta-arago-extras/recipes-core/meta/meta-toolchain-arago.bb
@@ -1,4 +1,4 @@
-TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-arago-sdk-host"
+TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host"
TOOLCHAIN_HOST_TASK += "nativesdk-buildtools-perl-dummy"
TOOLCHAIN_HOST_TASK += "packagegroup-cross-canadian-${MACHINE}"
TOOLCHAIN_TARGET_TASK ?= "packagegroup-arago-standalone-sdk-target"
diff --git a/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bb b/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bb
deleted file mode 100644
index 4199c2eb..00000000
--- a/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-sdk-host.bb
+++ /dev/null
@@ -1,21 +0,0 @@
-SUMMARY = "Host packages for a standalone Arago SDK or external toolchain"
-PR = "r18"
-LICENSE = "MIT"
-
-inherit packagegroup nativesdk
-
-PACKAGEGROUP_DISABLE_COMPLEMENTARY = "1"
-
-RDEPENDS_${PN} = "\
- nativesdk-pkgconfig \
- nativesdk-opkg \
- nativesdk-libtool \
- nativesdk-autoconf \
- nativesdk-automake \
- nativesdk-shadow \
- nativesdk-makedevs \
- nativesdk-python-distutils \
- nativesdk-git \
- nativesdk-cmake \
- nativesdk-mtd-utils-ubifs \
-"
diff --git a/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb b/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb
index ef54253d..c24652b9 100644
--- a/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb
+++ b/meta-arago-extras/recipes-core/packagegroups/nativesdk-packagegroup-arago-tisdk-host.bb
@@ -20,6 +20,9 @@ EXTRA_TI_TOOLS = " \
"
RDEPENDS_${PN} = "\
- nativesdk-packagegroup-arago-sdk-host \
+ nativesdk-packagegroup-sdk-host \
+ nativesdk-python-distutils \
+ nativesdk-git \
+ nativesdk-mtd-utils-ubifs \
${EXTRA_TI_TOOLS} \
"
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 3/9] arago-base-image: drop unused image recipe
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
meta-arago-distro/recipes-core/images/arago-base-image.bb | 8 --------
1 file changed, 8 deletions(-)
delete mode 100644 meta-arago-distro/recipes-core/images/arago-base-image.bb
diff --git a/meta-arago-distro/recipes-core/images/arago-base-image.bb b/meta-arago-distro/recipes-core/images/arago-base-image.bb
deleted file mode 100644
index 57ca93a5..00000000
--- a/meta-arago-distro/recipes-core/images/arago-base-image.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-# Arago base image
-# gives you a small image with package manager
-
-require arago-image.inc
-
-IMAGE_INSTALL += "packagegroup-arago-base"
-
-export IMAGE_BASENAME = "arago-base-image"
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 4/9] arago-console-image: drop unused image recipe
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
.../recipes-core/images/arago-console-image.bb | 13 -------------
1 file changed, 13 deletions(-)
delete mode 100644 meta-arago-distro/recipes-core/images/arago-console-image.bb
diff --git a/meta-arago-distro/recipes-core/images/arago-console-image.bb b/meta-arago-distro/recipes-core/images/arago-console-image.bb
deleted file mode 100644
index b455b2e1..00000000
--- a/meta-arago-distro/recipes-core/images/arago-console-image.bb
+++ /dev/null
@@ -1,13 +0,0 @@
-# Arago console image
-# gives you an image with basic media libraries
-
-require arago-image.inc
-
-COMPATIBLE_MACHINE = "(?!arago)"
-
-IMAGE_INSTALL += "\
- packagegroup-arago-base \
- packagegroup-arago-console \
- "
-
-export IMAGE_BASENAME = "arago-console-image"
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 5/9] arago-test-image: drop unused image recipe
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
.../recipes-core/images/arago-test-image.bb | 19 -------------------
1 file changed, 19 deletions(-)
delete mode 100644 meta-arago-distro/recipes-core/images/arago-test-image.bb
diff --git a/meta-arago-distro/recipes-core/images/arago-test-image.bb b/meta-arago-distro/recipes-core/images/arago-test-image.bb
deleted file mode 100644
index 11421126..00000000
--- a/meta-arago-distro/recipes-core/images/arago-test-image.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-# Arago System Test image
-# gives you test applications
-LICENSE = "MIT"
-
-require arago-image.inc
-
-IMAGE_FSTYPES = "tar.xz"
-
-IMAGE_INSTALL += "\
- packagegroup-arago-base \
- packagegroup-arago-console \
- packagegroup-arago-base-tisdk \
- packagegroup-arago-tisdk-crypto \
- packagegroup-arago-tisdk-addons \
- packagegroup-arago-test \
- packagegroup-arago-test-addons \
- "
-
-export IMAGE_BASENAME = "arago-test-image"
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 6/9] tisdk-recovery-rootfs-image: drop unused image recipe
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
.../recipes-core/images/tisdk-recovery-rootfs-image.bb | 10 ----------
1 file changed, 10 deletions(-)
delete mode 100644 meta-arago-distro/recipes-core/images/tisdk-recovery-rootfs-image.bb
diff --git a/meta-arago-distro/recipes-core/images/tisdk-recovery-rootfs-image.bb b/meta-arago-distro/recipes-core/images/tisdk-recovery-rootfs-image.bb
deleted file mode 100644
index 5a1ea0fd..00000000
--- a/meta-arago-distro/recipes-core/images/tisdk-recovery-rootfs-image.bb
+++ /dev/null
@@ -1,10 +0,0 @@
-# TI SDK recovery filesystem image
-COMPATIBLE_MACHINE = "keystone"
-
-require arago-image.inc
-
-IMAGE_INSTALL += "\
- packagegroup-arago-tisdk-recoveryfs \
-"
-
-export IMAGE_BASENAME = "tisdk-recoveryfs"
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 7/9] arago-core-tisdk-bundle: add missing deployment of J7 SYSFW binary
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
.../recipes-core/images/arago-core-tisdk-bundle.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta-arago-distro/recipes-core/images/arago-core-tisdk-bundle.bb b/meta-arago-distro/recipes-core/images/arago-core-tisdk-bundle.bb
index 8b8740b9..2fffe1ac 100644
--- a/meta-arago-distro/recipes-core/images/arago-core-tisdk-bundle.bb
+++ b/meta-arago-distro/recipes-core/images/arago-core-tisdk-bundle.bb
@@ -10,6 +10,7 @@ DEPLOY_SPL_NAME_k3 = "tispl.bin tiboot3.bin"
DEPLOY_IMAGES_NAME_k3 = "bl31.bin bl32.bin sysfw.itb"
DEPLOY_IMAGES_NAME_append_am65xx-evm = " ti-sci-firmware-am65x-gp.bin"
+DEPLOY_IMAGES_NAME_append_j7-evm = " ti-sci-firmware-j721e-gp.bin"
-ARAGO_TISDK_IMAGE ?= "arago-core-tisdk-image"
+ARAGO_TISDK_IMAGE ?= "arago-core-tisdk-bundle"
export IMAGE_BASENAME = "${ARAGO_TISDK_IMAGE}"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] ASoC: tas2562: Add support for digital volume control
From: Mark Brown @ 2020-02-20 19:18 UTC (permalink / raw)
To: Dan Murphy; +Cc: lgirdwood, perex, tiwai, alsa-devel, linux-kernel
In-Reply-To: <de0e8a5b-8c2a-ee04-856f-f0d678a3c66b@ti.com>
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]
On Thu, Feb 20, 2020 at 12:46:57PM -0600, Dan Murphy wrote:
> On 2/20/20 12:45 PM, Mark Brown wrote:
> > Is there a reason not to use the chip default here? Otherwise this
> > looks good.
> Chip default is set to 0dB full blast+ 0x40400000. This sets the volume to
> -110dB.
OK... that's a policy decision the same as all other volume changes and
so shouldn't be done by the driver - as ever we don't know how the
system is set up and what values make sense and keeping things out of
the driver means we don't end up with competing system integration
decisions causing changes in the driver. The system may have an
external amplifier they prefer to use for hardware volume control, may
prefer to do entirely soft volume control in their sound server or
something like that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [zeus/master][PATCH 8/9] arago-tiny-image: simplify by re-using arago-image.inc
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
.../recipes-core/images/arago-tiny-image.bb | 35 ++-----------------
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/meta-arago-distro/recipes-core/images/arago-tiny-image.bb b/meta-arago-distro/recipes-core/images/arago-tiny-image.bb
index 465d322b..5d1733e2 100644
--- a/meta-arago-distro/recipes-core/images/arago-tiny-image.bb
+++ b/meta-arago-distro/recipes-core/images/arago-tiny-image.bb
@@ -1,16 +1,9 @@
-# Common pieces for Arago images
+ARAGO_SYSVINIT = "1"
-LICENSE = "MIT"
-
-COMPATIBLE_MACHINE = "ti-soc"
-
-IMAGE_FEATURES += "package-management splash"
+require arago-image.inc
IMAGE_FSTYPES += "cpio"
-# 4KB per 1 inode should be enough
-EXTRA_IMAGECMD_ext2.gz += "-i 4096"
-
# Install a small set of utils which can be used for diagnostics
ARAGO_TINY_IMAGE_EXTRA_INSTALL ?= " \
parted \
@@ -21,31 +14,9 @@ ARAGO_TINY_IMAGE_EXTRA_INSTALL ?= " \
arago-feed-config \
"
-IMAGE_INSTALL += " \
+IMAGE_INSTALL = " \
packagegroup-arago-sysvinit-boot \
${ARAGO_TINY_IMAGE_EXTRA_INSTALL} \
"
export IMAGE_BASENAME = "arago-tiny-image"
-
-IMAGE_LINGUAS = ""
-
-make_bootfiles_symlinks_relative() {
- for f in "${IMAGE_ROOTFS}/boot"/*
- do
- [ -L "$f" ] || continue
-
- l=$(readlink "$f")
- if [ "${l:0:6}" == "/boot/" ]
- then
- ln -sf "${l##/boot/}" "$f"
- elif ["${l:0:1}" == "/" ]
- then
- ln -sf "..$l" "$f"
- fi
- done
-}
-
-ROOTFS_POSTPROCESS_COMMAND += "make_bootfiles_symlinks_relative;"
-
-inherit core-image
--
2.17.1
^ permalink raw reply related
* [zeus/master][PATCH 9/9] arago-image.inc: unbreak populate_sdk task
From: Denys Dmytriyenko @ 2020-02-20 18:54 UTC (permalink / raw)
To: meta-arago
In-Reply-To: <20200220185458.26926-1-denys@ti.com>
We chose not to install nativesdk-perl and its modules, hence ensure
dummy dependencies and archs are configured properly.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
meta-arago-distro/recipes-core/images/arago-image.inc | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/meta-arago-distro/recipes-core/images/arago-image.inc b/meta-arago-distro/recipes-core/images/arago-image.inc
index 179c81d1..b197dc27 100644
--- a/meta-arago-distro/recipes-core/images/arago-image.inc
+++ b/meta-arago-distro/recipes-core/images/arago-image.inc
@@ -9,17 +9,18 @@ IMAGE_FEATURES += "package-management splash"
# 4KB per 1 inode should be enough
EXTRA_IMAGECMD_ext2.gz += "-i 4096"
-ARAGO_IMAGE_EXTRA_INSTALL ?= ""
-
-IMAGE_INSTALL += " \
+IMAGE_INSTALL = " \
packagegroup-core-boot \
- ${ARAGO_IMAGE_EXTRA_INSTALL} \
+ ${CORE_IMAGE_EXTRA_INSTALL} \
"
export IMAGE_BASENAME = "arago-image"
IMAGE_LINGUAS = ""
+TOOLCHAIN_HOST_TASK += "nativesdk-buildtools-perl-dummy"
+SDK_PACKAGE_ARCHS += "buildtools-dummy-${SDKPKGSUFFIX}"
+
make_bootfiles_symlinks_relative() {
for f in "${IMAGE_ROOTFS}/boot"/*
do
--
2.17.1
^ permalink raw reply related
* Re: Kernel 5.5.4 build fail for BPF-selftests with latest LLVM
From: Alexei Starovoitov @ 2020-02-20 19:18 UTC (permalink / raw)
To: Bird, Tim
Cc: Jesper Dangaard Brouer, shuah, Daniel Díaz, Andrii Nakryiko,
Andrii Nakryiko, netdev@vger.kernel.org, BPF-dev-list,
Daniel Borkmann, David Miller, LKML, Greg Kroah-Hartman,
Anders Roxell, Toke Høiland-Jørgensen,
open list:KERNEL SELFTEST FRAMEWORK
In-Reply-To: <MWHPR13MB0895B185BC36759121D6F26AFD130@MWHPR13MB0895.namprd13.prod.outlook.com>
On Thu, Feb 20, 2020 at 05:41:51PM +0000, Bird, Tim wrote:
>
> So - do the BPF developers add new instructions to the virtual machine, that then
> have to be added to both the compiler and the executor (VM implementation)?
Right. New instructions are added to the kernel and llvm at the same time. The
kernel and llvm release cadence and process are different which complicates it
for us.
> It sounds like the compiler support and executor support is done in concert, and
> that patches are at least accepted upstream (but possibly are not yet available in
> a compiler release) for the compiler side. What about the Linux kernel side? Is the
> support for a new instruction only in non-released kernels (say, in the BPF development
> tree), or could it potentially be included in a released kernel, before the compiler
> with matching support is released? What would happen if a bug was found, and
> compiler support for the instruction was delayed?
As with all chicken-and-egg problems the feature has to land in one of the
repos first. That was one of the reasons llvm community switched to mono repo
to avoid clang vs llvm conflicts. The kernel and llvm are not going to be in a
single repo, so we have to orchestrate the landing. Most of the time it's easy,
because we maintain both kernel and llvm components. But in some cases it's
very difficult. For example we've delayed landing kernel and libbpf patches by
about six month, since we couldn't get an agreement on how the feature has to
be implemented in clang.
> I suppose that this would only
> mean that the executor supported an instruction that never appeared in a compiled
> BPF program? Is that right?
The answer is yes. It is the case that the kernel supports certain bpf
instructions, but llvm doesn't know how to emit them. But it has nothing to do
with landing of features and release cadence.
^ permalink raw reply
* Re: [PATCH] ASoC: tas2562: Add support for digital volume control
From: Mark Brown @ 2020-02-20 19:18 UTC (permalink / raw)
To: Dan Murphy; +Cc: linux-kernel, alsa-devel, tiwai, lgirdwood
In-Reply-To: <de0e8a5b-8c2a-ee04-856f-f0d678a3c66b@ti.com>
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]
On Thu, Feb 20, 2020 at 12:46:57PM -0600, Dan Murphy wrote:
> On 2/20/20 12:45 PM, Mark Brown wrote:
> > Is there a reason not to use the chip default here? Otherwise this
> > looks good.
> Chip default is set to 0dB full blast+ 0x40400000. This sets the volume to
> -110dB.
OK... that's a policy decision the same as all other volume changes and
so shouldn't be done by the driver - as ever we don't know how the
system is set up and what values make sense and keeping things out of
the driver means we don't end up with competing system integration
decisions causing changes in the driver. The system may have an
external amplifier they prefer to use for hardware volume control, may
prefer to do entirely soft volume control in their sound server or
something like that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: crash on connect
From: Glauber Costa @ 2020-02-20 19:19 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, Avi Kivity
In-Reply-To: <2be9d30f-bbca-7aa6-3d8c-34e3fcf71067@kernel.dk>
On Thu, Feb 20, 2020 at 2:12 PM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 2/20/20 11:45 AM, Glauber Costa wrote:
> > On Thu, Feb 20, 2020 at 12:28 PM Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> On 2/20/20 9:52 AM, Glauber Costa wrote:
> >>> On Thu, Feb 20, 2020 at 11:39 AM Jens Axboe <axboe@kernel.dk> wrote:
> >>>>
> >>>> On 2/20/20 9:34 AM, Glauber Costa wrote:
> >>>>> On Thu, Feb 20, 2020 at 11:29 AM Jens Axboe <axboe@kernel.dk> wrote:
> >>>>>>
> >>>>>> On 2/20/20 9:17 AM, Jens Axboe wrote:
> >>>>>>> On 2/20/20 7:19 AM, Glauber Costa wrote:
> >>>>>>>> Hi there, me again
> >>>>>>>>
> >>>>>>>> Kernel is at 043f0b67f2ab8d1af418056bc0cc6f0623d31347
> >>>>>>>>
> >>>>>>>> This test is easier to explain: it essentially issues a connect and a
> >>>>>>>> shutdown right away.
> >>>>>>>>
> >>>>>>>> It currently fails due to no fault of io_uring. But every now and then
> >>>>>>>> it crashes (you may have to run more than once to get it to crash)
> >>>>>>>>
> >>>>>>>> Instructions are similar to my last test.
> >>>>>>>> Except the test to build is now "tests/unit/connect_test"
> >>>>>>>> Code is at git@github.com:glommer/seastar.git branch io-uring-connect-crash
> >>>>>>>>
> >>>>>>>> Run it with ./build/release/tests/unit/connect_test -- -c1
> >>>>>>>> --reactor-backend=uring
> >>>>>>>>
> >>>>>>>> Backtrace attached
> >>>>>>>
> >>>>>>> Perfect thanks, I'll take a look!
> >>>>>>
> >>>>>> Haven't managed to crash it yet, but every run complains:
> >>>>>>
> >>>>>> got to shutdown of 10 with refcnt: 2
> >>>>>> Refs being all dropped, calling forget for 10
> >>>>>> terminate called after throwing an instance of 'fmt::v6::format_error'
> >>>>>> what(): argument index out of range
> >>>>>> unknown location(0): fatal error: in "unixdomain_server": signal: SIGABRT (application abort requested)
> >>>>>>
> >>>>>> Not sure if that's causing it not to fail here.
> >>>>>
> >>>>> Ok, that means it "passed". (I was in the process of figuring out
> >>>>> where I got this wrong when I started seeing the crashes)
> >>>>
> >>>> Can you do, in your kernel dir:
> >>>>
> >>>> $ gdb vmlinux
> >>>> [...]
> >>>> (gdb) l *__io_queue_sqe+0x4a
> >>>>
> >>>> and see what it says?
> >>>
> >>> 0xffffffff81375ada is in __io_queue_sqe (fs/io_uring.c:4814).
> >>> 4809 struct io_kiocb *linked_timeout;
> >>> 4810 struct io_kiocb *nxt = NULL;
> >>> 4811 int ret;
> >>> 4812
> >>> 4813 again:
> >>> 4814 linked_timeout = io_prep_linked_timeout(req);
> >>> 4815
> >>> 4816 ret = io_issue_sqe(req, sqe, &nxt, true);
> >>> 4817
> >>> 4818 /*
> >>>
> >>> (I am not using timeouts, just async_cancel)
> >>
> >> Can't seem to hit it here, went through thousands of iterations...
> >> I'll keep trying.
> >>
> >> If you have time, you can try and enable CONFIG_KASAN=y and see if
> >> you can hit it with that.
> >
> > I can
> >
> > Attaching full dmesg
>
> Can you try the latest? It's sha d8154e605f84. Before you do, can you
> do the lookup on __io_queue_sqe+0x639 with gdb?
Moving to that hash now. In the meantime, so I don't delay your fun:
) l *__io_queue_sqe+0x639
0xffffffff81566c19 is in __io_queue_sqe (./include/linux/compiler.h:226).
221 {
222 switch (size) {
223 case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
224 case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
225 case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
226 case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
227 default:
228 barrier();
229 __builtin_memcpy((void *)p, (const void *)res, size);
230 barrier();
>
> --
> Jens Axboe
>
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: mfd: motmdm: Add binding for motorola-mdm
From: Tony Lindgren @ 2020-02-20 19:20 UTC (permalink / raw)
To: Rob Herring
Cc: Lee Jones, Greg Kroah-Hartman, Alan Cox, Jiri Slaby, Johan Hovold,
Merlijn Wajer, Pavel Machek, Peter Hurley, Sebastian Reichel,
linux-serial, devicetree, linux-omap, linux-kernel
In-Reply-To: <20200219221310.GA26624@bogus>
* Rob Herring <robh@kernel.org> [200219 14:14]:
> On Sun, Feb 09, 2020 at 08:01:05PM -0800, Tony Lindgren wrote:
> > Add a binding document for Motorola modems controllable by
> > TS 27.010 UART line discipline using serdev drivers.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > .../mfd/motorola,mapphone-mdm6600.yaml | 37 +++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mfd/motorola,mapphone-mdm6600.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/motorola,mapphone-mdm6600.yaml b/Documentation/devicetree/bindings/mfd/motorola,mapphone-mdm6600.yaml
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/motorola,mapphone-mdm6600.yaml
> > @@ -0,0 +1,37 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Dual license new bindings please:
>
> (GPL-2.0-only OR BSD-2-Clause)
OK
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mfd/motorola,mapphone-mdm6600.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Motorola Mapphone MDM6600 Modem
> > +
> > +maintainers:
> > + - Tony Lindgren <tony@atomide.com>
> > +
> > +allOf:
> > + - $ref: "motorola,mapphone-mdm6600.yaml#"
>
> Huh? A recursive include? I'm not sure how that didn't blow up.
Oops sorry about that, I'll just drop that one.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/3] efi/arm: rewrite FDT param discovery routines
From: Ard Biesheuvel @ 2020-02-20 19:20 UTC (permalink / raw)
To: Leif Lindholm; +Cc: linux-efi, linux-arm-kernel, Atish Patra
In-Reply-To: <20200220183001.GE23627@bivouac.eciton.net>
On Thu, 20 Feb 2020 at 19:30, Leif Lindholm <leif@nuviainc.com> wrote:
>
> On Wed, Feb 19, 2020 at 16:24:40 +0100, Ard Biesheuvel wrote:
> > The efi_get_fdt_params() routine uses the early OF device tree
> > traversal helpers, that iterate over each node in the DT and invoke
> > a caller provided callback that can inspect the node's contents and
> > look for the required data. This requires a special param struct to
> > be passed around, with pointers into param enumeration structs that
> > contain (and duplicate) property names and offsets into yet another
> > struct that carries the collected data.
> >
> > Since we know the data we look for is either under /hypervisor/uefi
> > or under /chosen, it is much simpler to use the libfdt routines
> > directly, and try to grab a reference to either node directly, and
> > read each property in sequence.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > drivers/firmware/efi/fdtparams.c | 203 ++++++++------------
> > 1 file changed, 85 insertions(+), 118 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/fdtparams.c b/drivers/firmware/efi/fdtparams.c
> > index 7a384b307c56..23af4062e913 100644
> > --- a/drivers/firmware/efi/fdtparams.c
> > +++ b/drivers/firmware/efi/fdtparams.c
> > @@ -5,154 +5,121 @@
> > #include <linux/module.h>
> > #include <linux/init.h>
> > #include <linux/efi.h>
> > -#include <linux/of.h>
> > +#include <linux/libfdt.h>
> > #include <linux/of_fdt.h>
> >
> > -#include <asm/early_ioremap.h>
> > +#include <asm/unaligned.h>
> >
> > -#define UEFI_PARAM(name, prop, field) \
> > - { \
> > - { name }, \
> > - { prop }, \
> > - offsetof(struct efi_fdt_params, field), \
> > - sizeof_field(struct efi_fdt_params, field) \
> > - }
> > -
> > -struct efi_fdt_params {
> > - u64 system_table;
> > - u64 mmap;
> > - u32 mmap_size;
> > - u32 desc_size;
> > - u32 desc_ver;
> > -};
> > -
> > -struct params {
> > - const char name[32];
> > - const char propname[32];
> > - int offset;
> > - int size;
> > +enum {
> > + SYSTAB,
> > + MMBASE,
> > + MMSIZE,
> > + DCSIZE,
> > + DCVERS,
> > };
> >
> > -static __initdata struct params fdt_params[] = {
> > - UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
> > - UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
> > - UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
> > - UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
> > - UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
> > +static __initconst const char name[][22] = {
>
> I was going to complain about that 22, and I still think it looks a
> bit iffy, but I can't find a compiler that doesn't throw a warning if
> the value changes, so I guess I'm being over sensitive.
>
Yeah, 32 is just as arbitrary, and wastes more space :-)
> > + [SYSTAB] = "System Table ",
> > + [MMBASE] = "MemMap Address ",
> > + [MMSIZE] = "MemMap Size ",
> > + [DCSIZE] = "MemMap Desc. Size ",
> > + [DCVERS] = "MemMap Desc. Version ",
> > };
> >
> > -static __initdata struct params xen_fdt_params[] = {
> > - UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
> > - UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
> > - UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
> > - UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
> > - UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
> > -};
> > -
> > -#define EFI_FDT_PARAMS_SIZE ARRAY_SIZE(fdt_params)
> > -
> > -static __initdata struct {
> > - const char *uname;
> > - const char *subnode;
> > - struct params *params;
> > +static __initconst const struct {
> > + const char path[17];
> > + const char params[5][26];
>
> And I guess the same is true here, but the 5 *could* theoretically be
> replaced by a compile-time calculation of DCVERS - SYSTAB + 1. That
> may not be less error prone however. Finishing the enum on a
> somethingMAX entry might make it slightly better?
>
Yeah that make sense - I'll change that.
> But the error checking isn't really what I'm after, but getting rid of
> the opaqueness. Could we have comments about which specific string
> lengths we're matching against here for us bears of very little brain?
>
Sure.
> > } dt_params[] = {
> > - { "hypervisor", "uefi", xen_fdt_params },
> > - { "chosen", NULL, fdt_params },
> > -};
> > -
> > -struct param_info {
> > - int found;
> > - void *params;
> > - const char *missing;
> > +#ifdef CONFIG_XEN
> > + {
> > + "/hypervisor/uefi",
> > + {
> > + [SYSTAB] = "xen,uefi-system-table",
> > + [MMBASE] = "xen,uefi-mmap-start",
> > + [MMSIZE] = "xen,uefi-mmap-size",
> > + [DCSIZE] = "xen,uefi-mmap-desc-size",
> > + [DCVERS] = "xen,uefi-mmap-desc-ver",
> > + }
> > + },
> > +#endif
> > + {
> > + "/chosen",
> > + {
> > + [SYSTAB] = "linux,uefi-system-table",
> > + [MMBASE] = "linux,uefi-mmap-start",
> > + [MMSIZE] = "linux,uefi-mmap-size",
> > + [DCSIZE] = "linux,uefi-mmap-desc-size",
> > + [DCVERS] = "linux,uefi-mmap-desc-ver",
> > + }
> > + }
> > };
> >
> > -static int __init __find_uefi_params(unsigned long node,
> > - struct param_info *info,
> > - struct params *params)
> > +static int __init efi_get_fdt_prop(const void *fdt, int node, int dtp, int pp,
> > + void *var, int size)
> > {
> > const void *prop;
> > - void *dest;
> > + int len;
> > u64 val;
> > - int i, len;
> >
> > - for (i = 0; i < EFI_FDT_PARAMS_SIZE; i++) {
> > - prop = of_get_flat_dt_prop(node, params[i].propname, &len);
> > - if (!prop) {
> > - info->missing = params[i].name;
> > - return 0;
> > - }
> > -
> > - dest = info->params + params[i].offset;
> > - info->found++;
> > + prop = fdt_getprop(fdt, node, dt_params[dtp].params[pp], &len);
> > + if (!prop) {
> > + pr_err("Can't find property '%s' in device tree!\n",
> > + dt_params[dtp].params[pp]);
> > + return 1;
> > + }
> >
> > - val = of_read_number(prop, len / sizeof(u32));
> > + val = (len == 4) ? (u64)be32_to_cpup(prop) : get_unaligned_be64(prop);
> >
> > - if (params[i].size == sizeof(u32))
> > - *(u32 *)dest = val;
> > - else
> > - *(u64 *)dest = val;
> > + if (size == 8)
> > + *(u64 *)var = val;
> > + else
> > + *(u32 *)var = (val <= U32_MAX) ? val : U32_MAX; // saturate
> >
> > - if (efi_enabled(EFI_DBG))
> > - pr_info(" %s: 0x%0*llx\n", params[i].name,
> > - params[i].size * 2, val);
> > - }
> > + if (efi_enabled(EFI_DBG))
> > + pr_info(" %s: 0x%0*llx\n", name[pp], size * 2, val);
> >
> > - return 1;
> > + return 0;
> > }
> >
> > -static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
> > - int depth, void *data)
> > +u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm)
> > {
> > - struct param_info *info = data;
> > + const void *fdt = initial_boot_params;
> > + unsigned long systab;
> > + struct {
> > + void *var;
> > + int size;
> > + } target[] = {
> > + [SYSTAB] = { &systab, sizeof(systab) },
> > + [MMBASE] = { &mm->phys_map, sizeof(mm->phys_map) },
> > + [MMSIZE] = { &mm->size, sizeof(mm->size) },
> > + [DCSIZE] = { &mm->desc_size, sizeof(mm->desc_size) },
> > + [DCVERS] = { &mm->desc_version, sizeof(mm->desc_version) },
> > + };
> > int i;
> >
> > + BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(name));
> > + BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(dt_params[0].params));
> > +
> > for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
> > - const char *subnode = dt_params[i].subnode;
> > + int node;
> > + int j;
> >
> > - if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
> > - info->missing = dt_params[i].params[0].name;
> > + node = fdt_path_offset(fdt, dt_params[i].path);
> > + if (node < 0)
> > continue;
> > - }
> >
> > - if (subnode) {
> > - int err = of_get_flat_dt_subnode_by_name(node, subnode);
> > + if (efi_enabled(EFI_DBG))
> > + pr_info("Getting UEFI parameters from %s in DT:\n",
> > + dt_params[i].path);
> >
> > - if (err < 0)
> > + for (j = 0; j < ARRAY_SIZE(target); j++) {
> > + if (efi_get_fdt_prop(fdt, node, i, j, target[j].var,
> > + target[j].size)) {
> > return 0;
> > -
> > - node = err;
> > + }
> > }
> > -
> > - return __find_uefi_params(node, info, dt_params[i].params);
> > + return systab;
> > }
> > -
> > + pr_info("UEFI not found.\n");
> > return 0;
> > }
> > -
> > -u64 __init efi_get_fdt_params(struct efi_memory_map_data *memmap)
> > -{
> > - struct efi_fdt_params params;
> > - struct param_info info;
> > - int ret;
> > -
> > - pr_info("Getting EFI parameters from FDT:\n");
> > -
> > - info.found = 0;
> > - info.params = ¶ms;
> > -
> > - ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
> > - if (!info.found) {
> > - pr_info("UEFI not found.\n");
> > - return 0;
> > - } else if (!ret) {
> > - pr_err("Can't find '%s' in device tree!\n", info.missing);
> > - return 0;
> > - }
> > -
> > - memmap->desc_version = params.desc_ver;
> > - memmap->desc_size = params.desc_size;
> > - memmap->size = params.mmap_size;
> > - memmap->phys_map = params.mmap;
> > -
> > - return params.system_table;
> > -}
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2] rwlock: allow recursive read locking when already locked in write mode
From: Julien Grall @ 2020-02-20 19:20 UTC (permalink / raw)
To: Roger Pau Monne, xen-devel
Cc: Jürgen Groß, Stefano Stabellini, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
Jan Beulich
In-Reply-To: <20200220173116.88915-1-roger.pau@citrix.com>
Hi,
On 20/02/2020 17:31, Roger Pau Monne wrote:
> Allow a CPU already holding the lock in write mode to also lock it in
> read mode. There's no harm in allowing read locking a rwlock that's
> already owned by the caller (ie: CPU) in write mode. Allowing such
> accesses is required at least for the CPU maps use-case.
>
> In order to do this reserve 14bits of the lock, this allows to support
> up to 16384 CPUs. Also reduce the write lock mask to 2 bits: one to
> signal there are pending writers waiting on the lock and the other to
> signal the lock is owned in write mode. Note the write related data
> is using 16bits, this is done in order to be able to clear it (and
> thus release the lock) using a 16bit atomic write.
>
> This reduces the maximum number of concurrent readers from 16777216 to
> 65536, I think this should still be enough, or else the lock field
> can be expanded from 32 to 64bits if all architectures support atomic
> operations on 64bit integers.
FWIW, arm32 is able to support atomic operations on 64-bit integers.
> static inline void _write_unlock(rwlock_t *lock)
> {
> - /*
> - * If the writer field is atomic, it can be cleared directly.
> - * Otherwise, an atomic subtraction will be used to clear it.
> - */
> - atomic_sub(_QW_LOCKED, &lock->cnts);
> + /* Since the writer field is atomic, it can be cleared directly. */
> + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
> + BUILD_BUG_ON(_QR_SHIFT != 16);
> + write_atomic((uint16_t *)&lock->cnts, 0);
I think this is an abuse to cast an atomic_t() directly into a uint16_t.
You would at least want to use &lock->cnts.counter here.
The rest of the code looks good to me.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 3/3] efi/arm: rewrite FDT param discovery routines
From: Ard Biesheuvel @ 2020-02-20 19:20 UTC (permalink / raw)
To: Leif Lindholm; +Cc: Atish Patra, linux-efi, linux-arm-kernel
In-Reply-To: <20200220183001.GE23627@bivouac.eciton.net>
On Thu, 20 Feb 2020 at 19:30, Leif Lindholm <leif@nuviainc.com> wrote:
>
> On Wed, Feb 19, 2020 at 16:24:40 +0100, Ard Biesheuvel wrote:
> > The efi_get_fdt_params() routine uses the early OF device tree
> > traversal helpers, that iterate over each node in the DT and invoke
> > a caller provided callback that can inspect the node's contents and
> > look for the required data. This requires a special param struct to
> > be passed around, with pointers into param enumeration structs that
> > contain (and duplicate) property names and offsets into yet another
> > struct that carries the collected data.
> >
> > Since we know the data we look for is either under /hypervisor/uefi
> > or under /chosen, it is much simpler to use the libfdt routines
> > directly, and try to grab a reference to either node directly, and
> > read each property in sequence.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > drivers/firmware/efi/fdtparams.c | 203 ++++++++------------
> > 1 file changed, 85 insertions(+), 118 deletions(-)
> >
> > diff --git a/drivers/firmware/efi/fdtparams.c b/drivers/firmware/efi/fdtparams.c
> > index 7a384b307c56..23af4062e913 100644
> > --- a/drivers/firmware/efi/fdtparams.c
> > +++ b/drivers/firmware/efi/fdtparams.c
> > @@ -5,154 +5,121 @@
> > #include <linux/module.h>
> > #include <linux/init.h>
> > #include <linux/efi.h>
> > -#include <linux/of.h>
> > +#include <linux/libfdt.h>
> > #include <linux/of_fdt.h>
> >
> > -#include <asm/early_ioremap.h>
> > +#include <asm/unaligned.h>
> >
> > -#define UEFI_PARAM(name, prop, field) \
> > - { \
> > - { name }, \
> > - { prop }, \
> > - offsetof(struct efi_fdt_params, field), \
> > - sizeof_field(struct efi_fdt_params, field) \
> > - }
> > -
> > -struct efi_fdt_params {
> > - u64 system_table;
> > - u64 mmap;
> > - u32 mmap_size;
> > - u32 desc_size;
> > - u32 desc_ver;
> > -};
> > -
> > -struct params {
> > - const char name[32];
> > - const char propname[32];
> > - int offset;
> > - int size;
> > +enum {
> > + SYSTAB,
> > + MMBASE,
> > + MMSIZE,
> > + DCSIZE,
> > + DCVERS,
> > };
> >
> > -static __initdata struct params fdt_params[] = {
> > - UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
> > - UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
> > - UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
> > - UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
> > - UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
> > +static __initconst const char name[][22] = {
>
> I was going to complain about that 22, and I still think it looks a
> bit iffy, but I can't find a compiler that doesn't throw a warning if
> the value changes, so I guess I'm being over sensitive.
>
Yeah, 32 is just as arbitrary, and wastes more space :-)
> > + [SYSTAB] = "System Table ",
> > + [MMBASE] = "MemMap Address ",
> > + [MMSIZE] = "MemMap Size ",
> > + [DCSIZE] = "MemMap Desc. Size ",
> > + [DCVERS] = "MemMap Desc. Version ",
> > };
> >
> > -static __initdata struct params xen_fdt_params[] = {
> > - UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
> > - UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
> > - UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
> > - UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
> > - UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
> > -};
> > -
> > -#define EFI_FDT_PARAMS_SIZE ARRAY_SIZE(fdt_params)
> > -
> > -static __initdata struct {
> > - const char *uname;
> > - const char *subnode;
> > - struct params *params;
> > +static __initconst const struct {
> > + const char path[17];
> > + const char params[5][26];
>
> And I guess the same is true here, but the 5 *could* theoretically be
> replaced by a compile-time calculation of DCVERS - SYSTAB + 1. That
> may not be less error prone however. Finishing the enum on a
> somethingMAX entry might make it slightly better?
>
Yeah that make sense - I'll change that.
> But the error checking isn't really what I'm after, but getting rid of
> the opaqueness. Could we have comments about which specific string
> lengths we're matching against here for us bears of very little brain?
>
Sure.
> > } dt_params[] = {
> > - { "hypervisor", "uefi", xen_fdt_params },
> > - { "chosen", NULL, fdt_params },
> > -};
> > -
> > -struct param_info {
> > - int found;
> > - void *params;
> > - const char *missing;
> > +#ifdef CONFIG_XEN
> > + {
> > + "/hypervisor/uefi",
> > + {
> > + [SYSTAB] = "xen,uefi-system-table",
> > + [MMBASE] = "xen,uefi-mmap-start",
> > + [MMSIZE] = "xen,uefi-mmap-size",
> > + [DCSIZE] = "xen,uefi-mmap-desc-size",
> > + [DCVERS] = "xen,uefi-mmap-desc-ver",
> > + }
> > + },
> > +#endif
> > + {
> > + "/chosen",
> > + {
> > + [SYSTAB] = "linux,uefi-system-table",
> > + [MMBASE] = "linux,uefi-mmap-start",
> > + [MMSIZE] = "linux,uefi-mmap-size",
> > + [DCSIZE] = "linux,uefi-mmap-desc-size",
> > + [DCVERS] = "linux,uefi-mmap-desc-ver",
> > + }
> > + }
> > };
> >
> > -static int __init __find_uefi_params(unsigned long node,
> > - struct param_info *info,
> > - struct params *params)
> > +static int __init efi_get_fdt_prop(const void *fdt, int node, int dtp, int pp,
> > + void *var, int size)
> > {
> > const void *prop;
> > - void *dest;
> > + int len;
> > u64 val;
> > - int i, len;
> >
> > - for (i = 0; i < EFI_FDT_PARAMS_SIZE; i++) {
> > - prop = of_get_flat_dt_prop(node, params[i].propname, &len);
> > - if (!prop) {
> > - info->missing = params[i].name;
> > - return 0;
> > - }
> > -
> > - dest = info->params + params[i].offset;
> > - info->found++;
> > + prop = fdt_getprop(fdt, node, dt_params[dtp].params[pp], &len);
> > + if (!prop) {
> > + pr_err("Can't find property '%s' in device tree!\n",
> > + dt_params[dtp].params[pp]);
> > + return 1;
> > + }
> >
> > - val = of_read_number(prop, len / sizeof(u32));
> > + val = (len == 4) ? (u64)be32_to_cpup(prop) : get_unaligned_be64(prop);
> >
> > - if (params[i].size == sizeof(u32))
> > - *(u32 *)dest = val;
> > - else
> > - *(u64 *)dest = val;
> > + if (size == 8)
> > + *(u64 *)var = val;
> > + else
> > + *(u32 *)var = (val <= U32_MAX) ? val : U32_MAX; // saturate
> >
> > - if (efi_enabled(EFI_DBG))
> > - pr_info(" %s: 0x%0*llx\n", params[i].name,
> > - params[i].size * 2, val);
> > - }
> > + if (efi_enabled(EFI_DBG))
> > + pr_info(" %s: 0x%0*llx\n", name[pp], size * 2, val);
> >
> > - return 1;
> > + return 0;
> > }
> >
> > -static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
> > - int depth, void *data)
> > +u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm)
> > {
> > - struct param_info *info = data;
> > + const void *fdt = initial_boot_params;
> > + unsigned long systab;
> > + struct {
> > + void *var;
> > + int size;
> > + } target[] = {
> > + [SYSTAB] = { &systab, sizeof(systab) },
> > + [MMBASE] = { &mm->phys_map, sizeof(mm->phys_map) },
> > + [MMSIZE] = { &mm->size, sizeof(mm->size) },
> > + [DCSIZE] = { &mm->desc_size, sizeof(mm->desc_size) },
> > + [DCVERS] = { &mm->desc_version, sizeof(mm->desc_version) },
> > + };
> > int i;
> >
> > + BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(name));
> > + BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(dt_params[0].params));
> > +
> > for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
> > - const char *subnode = dt_params[i].subnode;
> > + int node;
> > + int j;
> >
> > - if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
> > - info->missing = dt_params[i].params[0].name;
> > + node = fdt_path_offset(fdt, dt_params[i].path);
> > + if (node < 0)
> > continue;
> > - }
> >
> > - if (subnode) {
> > - int err = of_get_flat_dt_subnode_by_name(node, subnode);
> > + if (efi_enabled(EFI_DBG))
> > + pr_info("Getting UEFI parameters from %s in DT:\n",
> > + dt_params[i].path);
> >
> > - if (err < 0)
> > + for (j = 0; j < ARRAY_SIZE(target); j++) {
> > + if (efi_get_fdt_prop(fdt, node, i, j, target[j].var,
> > + target[j].size)) {
> > return 0;
> > -
> > - node = err;
> > + }
> > }
> > -
> > - return __find_uefi_params(node, info, dt_params[i].params);
> > + return systab;
> > }
> > -
> > + pr_info("UEFI not found.\n");
> > return 0;
> > }
> > -
> > -u64 __init efi_get_fdt_params(struct efi_memory_map_data *memmap)
> > -{
> > - struct efi_fdt_params params;
> > - struct param_info info;
> > - int ret;
> > -
> > - pr_info("Getting EFI parameters from FDT:\n");
> > -
> > - info.found = 0;
> > - info.params = ¶ms;
> > -
> > - ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
> > - if (!info.found) {
> > - pr_info("UEFI not found.\n");
> > - return 0;
> > - } else if (!ret) {
> > - pr_err("Can't find '%s' in device tree!\n", info.missing);
> > - return 0;
> > - }
> > -
> > - memmap->desc_version = params.desc_ver;
> > - memmap->desc_size = params.desc_size;
> > - memmap->size = params.mmap_size;
> > - memmap->phys_map = params.mmap;
> > -
> > - return params.system_table;
> > -}
> > --
> > 2.17.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Xen-devel] [linux-next test] 147291: regressions - FAIL
From: osstest service owner @ 2020-02-20 19:21 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147291 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 8 reboot fail REGR. vs. 147157
test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 147157
test-armhf-armhf-xl-multivcpu 7 xen-boot fail REGR. vs. 147157
test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 147157
test-armhf-armhf-xl-cubietruck 7 xen-boot fail REGR. vs. 147157
test-armhf-armhf-xl-credit1 7 xen-boot fail REGR. vs. 147157
test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 147157
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 12 guest-start fail like 147157
test-amd64-amd64-xl-credit1 12 guest-start fail like 147157
test-amd64-amd64-xl-multivcpu 12 guest-start fail like 147157
test-amd64-amd64-xl-credit2 12 guest-start fail like 147157
test-amd64-i386-xl-shadow 12 guest-start fail like 147157
test-amd64-amd64-xl-shadow 12 guest-start fail like 147157
test-arm64-arm64-xl-credit2 12 guest-start fail like 147157
test-arm64-arm64-xl-seattle 16 guest-start/debian.repeat fail like 147157
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 147157
test-armhf-armhf-xl-rtds 12 guest-start fail like 147157
test-armhf-armhf-xl-credit2 12 guest-start fail like 147157
test-arm64-arm64-xl-credit1 12 guest-start fail like 147157
test-arm64-arm64-xl 16 guest-start/debian.repeat fail like 147157
test-arm64-arm64-xl-thunderx 16 guest-start/debian.repeat fail like 147157
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 147157
test-arm64-arm64-xl-xsm 16 guest-start/debian.repeat fail like 147157
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail like 147157
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 147157
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 147157
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 147157
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 147157
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 147157
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 147157
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass
test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux 1d7f85df0f9c0456520ae86dc597bca87980d253
baseline version:
linux 11a48a5a18c63fd7621bb050228cebf13566e4d8
Last test of basis (not found)
Failing since (not found)
Testing same since 147291 2020-02-19 09:19:10 Z 1 days 1 attempts
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl fail
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm fail
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 fail
test-arm64-arm64-xl-credit1 fail
test-armhf-armhf-xl-credit1 fail
test-amd64-amd64-xl-credit2 fail
test-arm64-arm64-xl-credit2 fail
test-armhf-armhf-xl-credit2 fail
test-armhf-armhf-xl-cubietruck fail
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-amd64-examine pass
test-arm64-arm64-examine pass
test-armhf-armhf-examine fail
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu fail
test-armhf-armhf-xl-multivcpu fail
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-arm64-arm64-xl-seattle fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow fail
test-amd64-i386-xl-shadow fail
test-arm64-arm64-xl-thunderx fail
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Push not applicable.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: functionfs gadget with multiple endpoints
From: Belisko Marek @ 2020-02-20 19:21 UTC (permalink / raw)
To: Alan Stern; +Cc: Linux USB Mailing List
In-Reply-To: <Pine.LNX.4.44L0.2002201024190.1453-100000@iolanthe.rowland.org>
hi Alan,
On Thu, Feb 20, 2020 at 4:26 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Thu, 20 Feb 2020, Belisko Marek wrote:
>
> > Hi,
> >
> > I'm playing with functionfs and use configfs + functionfs + ffs-test
> > from kernel to test connection between my device and host. ffs-test
> > example provide 1 configuration with 1 interface and with 2 bulk
> > endpoints.
> >
> > I'm writing application which will write/read data to usb device but
> > can be accessed from other multiple application. I'm planning to write
> > kind of gatekeeper which will serialize data to endpoint and notify
> > reader about received data.
> >
> > I was thinking about other possibility to extend gadget to provide
> > more endpoints (like 2). I was able to extend ffs-test and also I can
> > send/receive data (using libusb) over original endpoints but not over
> > new created one (I've run 2 instances of same application which
> > basically create transfers for 2 different endpoints) but when running
> > second application I got this error:
> >
> > libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=16
> > libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=16
>
> Only one program at a time can claim an interface, and submitting an
> URB to an endpoint automatically claims the endpoint's interface.
>
> > I'm not USB expert but multiple endpoint should be possible (maybe I
> > need to put them to other interface?-> tried that also but got same
> > error as above with errno=2). Thanks for any pointers and advice.
>
> errno=16 and errno=2 are different errors, not the same error.
> Putting the endpoints in different interfaces should work; you probably
> have a bug somewhere in your code.
To clarify it a bit. I have test program which basically
asynchronously sends buffer to bulk endpoint.
Then as said if start second program I got errno=16 which means busy
as other program already occupy endpoint so this is clear.
But when extend ffs-test in this way https://pastebin.com/xymtDuJj
using lsusb I can see:
Bus 001 Device 010: ID 1d6b:0104 Linux Foundation Multifunction
Composite Gadget
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0104 Multifunction Composite Gadget
bcdDevice 4.12
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4
bmAttributes 0x80
(Bus Powered)
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
When use same program as before but writing to EP 2 OUT I got error 2.
Also one thing I noticed is that bNumInterfaces still shows 1 (even I
have 2 interface descriptors) and not 2 as I would expect.
Is there something I'm doing wrong or maybe it can be bug in ffs code?
Is there any drawback of using multiple endpoints in overall transfer speed?
Thanks and BR,
>
> Alan Stern
>
marek
^ permalink raw reply
* Re: [PATCH v12 1/9] hugetlb_cgroup: Add hugetlb_cgroup reservation counter
From: Mina Almasry @ 2020-02-20 19:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Mike Kravetz, shuah, David Rientjes, Shakeel Butt, Greg Thelen,
open list, Linux-MM, linux-kselftest, cgroups
In-Reply-To: <20200219130648.83e6810848774c6fd649c445@linux-foundation.org>
On Wed, Feb 19, 2020 at 1:06 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 19 Feb 2020 11:05:41 -0800 Mina Almasry <almasrymina@google.com> wrote:
>
> > On Tue, Feb 11, 2020 at 3:19 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > On Tue, 11 Feb 2020 13:31:20 -0800 Mina Almasry <almasrymina@google.com> wrote:
> > >
> > > > These counters will track hugetlb reservations rather than hugetlb
> > > > memory faulted in. This patch only adds the counter, following patches
> > > > add the charging and uncharging of the counter.
> > >
> > > We're still pretty thin on review here, but as it's v12 and Mike
> > > appears to be signed up to look at this work, I'll add them to -next to
> > > help move things forward.
> > >
> >
> > Hi Andrew,
> >
> > Since the patches were merged into -next there have been build fixes
> > and test fixes and some review comments. Would you like me to submit
> > *new* patches to address these, or would you like me to squash the
> > fixes into my existing patch series and submit another iteration of
> > the patch series?
>
> What you did worked OK ;)
>
> Please check the end result next time I release a kernel.
Thanks Andrew! Things definitely moved along after the patchseries got
into -next :D
By my count I think all my patches outside of the tests patch have
been acked or reviewed. When you have a chance I have a couple of
questions:
1. For the non-tests patch, anything pending on those preventing
eventual submission to linus's tree?
2. For the tests patch, I only have a Tested-by from Sandipan. Is that
good enough? If the worst comes to worst and I don't get a review on
that patch I would rather (if possible) that 'tests' patch can be
dropped while I nag folks for a review, rather than block submission
of the entire patch series. I ask because it's been out for review for
some time and it's the one I got least discussion on so I'm not sure
I'll have a review by the time it's needed.
Thanks again!
^ permalink raw reply
* Re: [PATCH v2] KVM: x86: enable dirty log gradually in small chunks
From: Sean Christopherson @ 2020-02-20 19:23 UTC (permalink / raw)
To: Peter Xu
Cc: Jay Zhou, kvm, pbonzini, wangxinxin.wang, weidong.huang,
liu.jinsong
In-Reply-To: <20200220191706.GF2905@xz-x1>
On Thu, Feb 20, 2020 at 02:17:06PM -0500, Peter Xu wrote:
> On Thu, Feb 20, 2020 at 12:28:28PM +0800, Jay Zhou wrote:
> > @@ -3348,7 +3352,14 @@ static int kvm_vm_ioctl_enable_cap_generic(struct kvm *kvm,
> > switch (cap->cap) {
> > #ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT
> > case KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2:
> > - if (cap->flags || (cap->args[0] & ~1))
> > + if (cap->flags ||
> > + (cap->args[0] & ~KVM_DIRTY_LOG_MANUAL_CAPS) ||
> > + /* The capability of KVM_DIRTY_LOG_INITIALLY_SET depends
> > + * on KVM_DIRTY_LOG_MANUAL_PROTECT, it should not be
> > + * set individually
> > + */
> > + ((cap->args[0] & KVM_DIRTY_LOG_MANUAL_CAPS) ==
> > + KVM_DIRTY_LOG_INITIALLY_SET))
>
> How about something easier to read? :)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 70f03ce0e5c1..9dfbab2a9929 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -3348,7 +3348,10 @@ static int kvm_vm_ioctl_enable_cap_generic(struct kvm *kvm,
> switch (cap->cap) {
> #ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT
> case KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2:
> - if (cap->flags || (cap->args[0] & ~1))
> + if (cap->flags || (cap->args[0] & ~3))
> + return -EINVAL;
> + /* Allow 00, 01, and 11. */
> + if (cap->args[0] == KVM_DIRTY_LOG_INITIALLY_SET)
> return -EINVAL;
Oof, "easier" is subjective :-) How about this?
case KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2: {
u64 allowed_options = KVM_DIRTY_LOG_MANUAL_PROTECT;
if (cap->args[0] & KVM_DIRTY_LOG_MANUAL_PROTECT)
allowed_options = KVM_DIRTY_LOG_INITIALLY_SET;
if (cap->flags || (cap->args[0] & ~allowed_options))
return -EINVAL;
kvm->manual_dirty_log_protect = cap->args[0];
return 0;
}
> kvm->manual_dirty_log_protect = cap->args[0];
> return 0;
>
> Otherwise it looks good to me!
>
> Thanks,
>
> --
> Peter Xu
>
^ permalink raw reply
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: mark gross @ 2020-02-20 19:24 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220182646.GC30404@zn.tnic>
On Thu, Feb 20, 2020 at 07:26:46PM +0100, speck for Borislav Petkov wrote:
> On Thu, Feb 20, 2020 at 09:53:40AM -0800, speck for mark gross wrote:
> > Because its only needed in the context of the WIP mitigation patch that I'm
> > having issues sending propperly.
> >
> > Sigh, I guess I'll just put it in a reply.
>
> Actually, your 2/2 was being held by the ML because you've sent,
> reportedly, not from the mail address you're subscribed with, to speck@.
> It should be fixed now because Thomas added an alias for your other mail
> address.
I have moved my work to a different workstation recently.... I'll look into
this.
Thanks,
--mark
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
> --
^ permalink raw reply
* [dpdk-dev] Permissions Required to Run DPDK/MLX5 as Non-Root User?
From: David Christensen @ 2020-02-20 19:24 UTC (permalink / raw)
To: dev@dpdk.org
Running DPDK 20.02-rc3 and attempting to use the MLX5 PMD as a non-root
user. When starting testpmd I'm receiving the following error on both
Power and x86_64 platforms (full output further down):
net_mlx5: probe of PCI device 0000:01:00.0 aborted after encountering
an error: Operation not supported
Walking through the code (mlx5_pci_probe, mlx5_dev_spawn,
mlx5_hrxq_drop_new, mlx5_glue_create_qp_ex) I see the call to
ibv_create_qp_ex() is failing. Why might this be a problem for a
non-root user? I verified that RDMA works correctly on the RHEL 8.1
platform with rping/udaddy as a non-root user.
Dave
$ ~/src/dpdk/build/app/dpdk-testpmd --log-level='pmd.net.mlx5:8' -w
0000:01:00.0 -w 0000:01:00.1 -l 4,8-63 -n 4 -- --rxq=16 --rxd=4096
--txq=16 --txd=1024 --nb-cores=32 -i -a --numa --forward-mode=macswap
EAL: Detected 128 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Multi-process socket /run/user/1003/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: 2048 hugepages of size 2097152 reserved, but no mounted
hugetlbfs found for that size
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device 0000:01:00.0 on NUMA socket 0
EAL: probe driver: 15b3:1019 net_mlx5
net_mlx5: checking device "mlx5_1"
net_mlx5: checking device "mlx5_3"
net_mlx5: checking device "mlx5_0"
net_mlx5: PCI information matches for device "mlx5_0"
net_mlx5: checking device "mlx5_2"
net_mlx5: no E-Switch support detected
net_mlx5: naming Ethernet device "0000:01:00.0"
net_mlx5: DevX is NOT supported
net_mlx5: enhanced MPW is supported
net_mlx5: SWP support: 7
net_mlx5: min_single_stride_log_num_of_bytes: 6
net_mlx5: max_single_stride_log_num_of_bytes: 13
net_mlx5: min_single_wqe_log_num_of_strides: 9
net_mlx5: max_single_wqe_log_num_of_strides: 16
net_mlx5: supported_qpts: 256
net_mlx5: device supports Multi-Packet RQ
net_mlx5: tunnel offloading is supported
net_mlx5: MPLS over GRE/UDP tunnel offloading is not supported
net_mlx5: checksum offloading is supported
net_mlx5: DV flow is not supported
net_mlx5: maximum Rx indirection table size is 512
net_mlx5: VLAN stripping is supported
net_mlx5: FCS stripping configuration is supported
net_mlx5: enhanced MPS is enabled
net_mlx5: port 0 MAC address is ec:0d:9a:ca:b2:b4
net_mlx5: port 0 MTU is 9238
net_mlx5: port 0 forcing Ethernet interface up
net_mlx5: min tx inline configured: 0
net_mlx5: probe of PCI device 0000:01:00.0 aborted after encountering
an error: Operation not supported
EAL: Requested device 0000:01:00.0 cannot be used
^ 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.