* [PATCH v4 0/6] *** Add support for wifi QMI client handshakes ***
From: Govind Singh @ 2018-07-23 12:34 UTC (permalink / raw)
To: niklas.cassel, bjorn.andersson, david.brown, andy.gross, robh,
devicetree, ath10k
Cc: linux-wireless, Govind Singh
Add QMI client handshakes for Q6 integrated WLAN connectivity subsystem.
This module is responsible for communicating WLAN control messages to FW
over QMI interface. This patch series enables the qmi handshakes required for
WCN3990 chipset.
QUALCOMM MSM Interface(QMI) provides the control interface between
components running b/w remote processors with underlying transport layer
based on integrated chipset(shared memory) or discrete chipset(PCI/USB/SDIO/UART).
QMI client driver implementation is based on qmi framework https://lwn.net/Articles/729924/.
Below is the sequence of qmi handshake.
QMI CLIENT(APPS) QMI SERVER(FW in Q6)
<------wlan service discoverd----
-----connect to wlam qmi service----->
------------wlan info request----->
<------------wlan info resp------------
------------msa info req-------->
<------------msa info resp------------
------------msa ready req-------->
<------------msa ready resp------------
<------------msa ready indication-------
------------capability req------->
<------------capability resp------------
------------qmi bdf req--------->
<------------qmi bdf resp------------
------------qmi cal trigger------->
<------------ QMI FW ready indication-------
WLAN fw is running in modem Q6 dsp as user PD(protection domain).
Sequence of user PD loading is as following.
1) Remote proc PIL driver loads the modem fw/ROOT PD.
2) As part of ROOT pd boot-up it queries to a daemon(pd_mapper) running in apps
processor to determine how many usre pd's to be loaded by the remote processor(Q6).
3) Once user pd info is known to remote processor it loads the user pd via tftp
protocol.
https://github.com/andersson/pd-mapper
https://github.com/andersson/tqftpserv
Changes since V3:
Removed msa memory child node and used only memory-region property.
Fixed sparse warning reported in v3 change.
Changed qmi board id data type to u32 to align with fw defined value.
Changes since V2:
Addressed review comments from v2 version.
Removed msa-size from dt binding and added reference to reserved-memory/reserved-memory.txt.
Changes since V1:
Removed qmi client driver and integrated qmi client handshakes in snoc platform driver.
Addressed comments on v1 version.
Switched to ath10k bdf download infra(board-2.bin)
Added MSA fixed region support to support unload use-case.
Unified logging.
Testing:
Tested all qmi handshakes, driver load/unload and STA/SAP sanity testing.
Tested HW: SDM845(WCN3990)
Tested FW: WLAN.HL.2.0-01192-QCAHLSWMTPLZ-1
Govind Singh (5):
ath10k: Add qmi service helpers for wcn3990 qmi client
dt: bindings: add bindings for msa memory region
firmware: qcom: scm: Add WLAN VMID for Qualcomm SCM interface
ath10k: Add debug mask for QMI layer
ath10k: Add QMI message handshake for wcn3990 client
Rakesh Pillai (1):
ath10k: Add support to create boardname for non-bmi target
.../bindings/net/wireless/qcom,ath10k.txt | 6 +
drivers/net/wireless/ath/ath10k/Kconfig | 1 +
drivers/net/wireless/ath/ath10k/Makefile | 4 +-
drivers/net/wireless/ath/ath10k/core.c | 14 +-
drivers/net/wireless/ath/ath10k/core.h | 4 +
drivers/net/wireless/ath/ath10k/debug.h | 1 +
drivers/net/wireless/ath/ath10k/qmi.c | 1019 ++++++++
drivers/net/wireless/ath/ath10k/qmi.h | 129 +
.../net/wireless/ath/ath10k/qmi_wlfw_v01.c | 2072 +++++++++++++++++
.../net/wireless/ath/ath10k/qmi_wlfw_v01.h | 677 ++++++
drivers/net/wireless/ath/ath10k/snoc.c | 262 ++-
drivers/net/wireless/ath/ath10k/snoc.h | 4 +
include/linux/qcom_scm.h | 4 +-
13 files changed, 4186 insertions(+), 11 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath10k/qmi.c
create mode 100644 drivers/net/wireless/ath/ath10k/qmi.h
create mode 100644 drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.c
create mode 100644 drivers/net/wireless/ath/ath10k/qmi_wlfw_v01.h
--
2.17.0
^ permalink raw reply
* Re: [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system
From: Will Deacon @ 2018-07-23 13:35 UTC (permalink / raw)
To: AKASHI Takahiro, Ard Biesheuvel, Catalin Marinas, Baicar, Tyler,
Bhupesh Sharma, Dave Young, James Morse, Mark Rutland, Al Stone,
Graeme Gregory, Hanjun Guo, Lorenzo Pieralisi, Sudeep Holla,
linux-arm-kernel, Linux Kernel Mailing List, Kexec Mailing List
In-Reply-To: <20180717051222.GA11258@linaro.org>
On Tue, Jul 17, 2018 at 02:12:23PM +0900, AKASHI Takahiro wrote:
> On Fri, Jul 13, 2018 at 07:49:45AM +0200, Ard Biesheuvel wrote:
> > On 13 July 2018 at 02:34, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > On Thu, Jul 12, 2018 at 05:49:19PM +0100, Will Deacon wrote:
> > >> Hi Akashi,
> > >>
> > >> On Tue, Jul 10, 2018 at 08:42:25AM +0900, AKASHI Takahiro wrote:
> > >> > This patch series is a set of bug fixes to address kexec/kdump
> > >> > failures which are sometimes observed on ACPI-only system and reported
> > >> > in LAK-ML before.
> > >>
> > >> I tried picking this up, along with Ard's fixup, but I'm seeing a build
> > >> failure for allmodconfig:
> > >>
> > >> arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
> > >> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'
> > >>
> > >> I didn't investigate further. Please can you fix this?
> > >
> > > Because CONFIG_ACPI is on and CONFIG_EFI is off.
> > >
> > > This can happen in allmodconfig as CONFIG_EFI depends on
> > > !CONFIG_CPU_BIG_ENDIAN, which is actually on in this case.
> > >
> >
> > Allowing both CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN to be configured
> > makes no sense at all. Things will surely break if you start using BE
> > memory accesses while parsing ACPI tables.
> >
> > Allowing CONFIG_ACPI without CONFIG_EFI makes no sense either, since
> > on arm64, the only way to find the ACPI tables is through a UEFI
> > configuration table.
>
>
> Do you agree to this?
Yes; please post a new series which resolves these dependencies and includes
Ard's fixup from before.
Thanks,
Will
^ permalink raw reply
* [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system
From: Will Deacon @ 2018-07-23 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180717051222.GA11258@linaro.org>
On Tue, Jul 17, 2018 at 02:12:23PM +0900, AKASHI Takahiro wrote:
> On Fri, Jul 13, 2018 at 07:49:45AM +0200, Ard Biesheuvel wrote:
> > On 13 July 2018 at 02:34, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > On Thu, Jul 12, 2018 at 05:49:19PM +0100, Will Deacon wrote:
> > >> Hi Akashi,
> > >>
> > >> On Tue, Jul 10, 2018 at 08:42:25AM +0900, AKASHI Takahiro wrote:
> > >> > This patch series is a set of bug fixes to address kexec/kdump
> > >> > failures which are sometimes observed on ACPI-only system and reported
> > >> > in LAK-ML before.
> > >>
> > >> I tried picking this up, along with Ard's fixup, but I'm seeing a build
> > >> failure for allmodconfig:
> > >>
> > >> arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
> > >> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'
> > >>
> > >> I didn't investigate further. Please can you fix this?
> > >
> > > Because CONFIG_ACPI is on and CONFIG_EFI is off.
> > >
> > > This can happen in allmodconfig as CONFIG_EFI depends on
> > > !CONFIG_CPU_BIG_ENDIAN, which is actually on in this case.
> > >
> >
> > Allowing both CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN to be configured
> > makes no sense at all. Things will surely break if you start using BE
> > memory accesses while parsing ACPI tables.
> >
> > Allowing CONFIG_ACPI without CONFIG_EFI makes no sense either, since
> > on arm64, the only way to find the ACPI tables is through a UEFI
> > configuration table.
>
>
> Do you agree to this?
Yes; please post a new series which resolves these dependencies and includes
Ard's fixup from before.
Thanks,
Will
^ permalink raw reply
* Re: [PATCH v3.1 0/4] arm64: kexec,kdump: fix boot failures on acpi-only system
From: Will Deacon @ 2018-07-23 13:35 UTC (permalink / raw)
To: AKASHI Takahiro, Ard Biesheuvel, Catalin Marinas, Baicar, Tyler,
Bhupesh Sharma, Dave Young, James Morse, Mark Rutland, Al Stone,
Graeme Gregory, Hanjun Guo, Lorenzo Pieralisi, Sudeep Holla,
linux-arm-kernel, Linux Kernel Mailing List, Kexec Mailing List
In-Reply-To: <20180717051222.GA11258@linaro.org>
On Tue, Jul 17, 2018 at 02:12:23PM +0900, AKASHI Takahiro wrote:
> On Fri, Jul 13, 2018 at 07:49:45AM +0200, Ard Biesheuvel wrote:
> > On 13 July 2018 at 02:34, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > > On Thu, Jul 12, 2018 at 05:49:19PM +0100, Will Deacon wrote:
> > >> Hi Akashi,
> > >>
> > >> On Tue, Jul 10, 2018 at 08:42:25AM +0900, AKASHI Takahiro wrote:
> > >> > This patch series is a set of bug fixes to address kexec/kdump
> > >> > failures which are sometimes observed on ACPI-only system and reported
> > >> > in LAK-ML before.
> > >>
> > >> I tried picking this up, along with Ard's fixup, but I'm seeing a build
> > >> failure for allmodconfig:
> > >>
> > >> arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
> > >> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'
> > >>
> > >> I didn't investigate further. Please can you fix this?
> > >
> > > Because CONFIG_ACPI is on and CONFIG_EFI is off.
> > >
> > > This can happen in allmodconfig as CONFIG_EFI depends on
> > > !CONFIG_CPU_BIG_ENDIAN, which is actually on in this case.
> > >
> >
> > Allowing both CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN to be configured
> > makes no sense at all. Things will surely break if you start using BE
> > memory accesses while parsing ACPI tables.
> >
> > Allowing CONFIG_ACPI without CONFIG_EFI makes no sense either, since
> > on arm64, the only way to find the ACPI tables is through a UEFI
> > configuration table.
>
>
> Do you agree to this?
Yes; please post a new series which resolves these dependencies and includes
Ard's fixup from before.
Thanks,
Will
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v3 12/13] x86: add iommu_ops to modify and flush IOMMU mappings
From: Wei Liu @ 2018-07-23 13:35 UTC (permalink / raw)
To: Paul Durrant
Cc: Stefano Stabellini, Wei Liu, George Dunlap, Andrew Cooper,
Ian Jackson, Tim Deegan, Julien Grall, Jan Beulich, xen-devel
In-Reply-To: <20180717133816.37958-13-paul.durrant@citrix.com>
On Tue, Jul 17, 2018 at 02:38:15PM +0100, Paul Durrant wrote:
>
[...]
> +static int iommuop_map(struct xen_iommu_op_map *op)
> +{
> + struct domain *d, *currd = current->domain;
> + struct domain_iommu *iommu = dom_iommu(currd);
> + bool readonly = op->flags & XEN_IOMMUOP_map_readonly;
> + bfn_t bfn = _bfn(op->bfn);
> + struct page_info *page;
> + unsigned int prot;
> + int rc, ignore;
> +
> + if ( op->pad || (op->flags & ~XEN_IOMMUOP_map_readonly) )
> + return -EINVAL;
> +
> + if ( !iommu->iommu_op_ranges )
> + return -EOPNOTSUPP;
> +
> + /* Check whether the specified BFN falls in a reserved region */
> + if ( rangeset_contains_singleton(iommu->reserved_ranges, bfn_x(bfn)) )
> + return -EINVAL;
> +
> + d = rcu_lock_domain_by_any_id(op->domid);
I think this needs to be moved earlier before dereferencing assigning
iommu -- it depends on d being valid.
Same applies to the unmap function.
> +
> +static int iommuop_flush(void)
> +{
> + return !iommu_iotlb_flush_all(current->domain) ? 0 : -EIO;
I don't follow: why does this only flush current->domain? But
map/unmap use explicit argument to specify a domain?
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: wireguardnl: Go package for interacting with WireGuard via generic netlink
From: Matt Layher @ 2018-07-23 13:43 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
In-Reply-To: <CAHmME9pcN_SyZ5_bYU2H=NjoZ67ETaRaYxbRR673zrk_k36_AQ@mail.gmail.com>
Hey Jason,
Thanks very much for WireGuard and for the information.
> Something to consider with this is the chunking.
Certainly! This was a first pass but these changes should be reasonable
to port to Go as well. I suppose I'll have to introduce some more
complicated test devices to this logic. I've filed a couple issues to
track this and hope that I can at least implement the chunking get logic
this week.
> The other thing that might be sort of neat to try to implement is
falling back to the userspace API:
This is super interesting and I actually did not discover it until after
I pushed the first few commits to my package. I could see it making
sense to refactor my current package layout to something like three
packages:
- wireguardnl: netlink-based communication
- wireguardcfg: text-based userspace configuration protocol communication
- wireguard: wrapper for both that detects the module in use and
seamlessly presents a unified interface
> The thing you're dumping from a single device is all the peers. If
you want a list of all interfaces, then the place to NLM_F_DUMP is
RTM_GETLINK, where you can then inspect
ifinfomsg->IFLA_LINKINFO->IFLA_INFO_KIND and make sure that it's
"wireguard".
Ahhh, that makes more sense to me. Perhaps I glossed over the
uapi/wireguard.h documentation. For the time being, I'm doing a call to
Go's "net.Interfaces" which is a bit easier (though less efficient) than
doing rtnetlink calls directly. Perhaps this is something I can iterate
on in the future as well.
> If you're on IRC, come on into #wireguard on Freenode and poke me, and
we can chat about it further; I'm zx2c4.
Certainly! I don't have any further inquiries at this time, but I'll
join up!
Thank you again for WireGuard, and thank you very much for your time,
feedback, and answers to my questions.
- Matt Layher
On 07/23/2018 07:59 AM, Jason A. Donenfeld wrote:
> Hey Matt,
>
> That's terrific! Thanks for making that. I look forward to seeing
> utilities develop around your library.
>
> Something to consider with this is the chunking. Since a device has
> many peers and a peer has many allowedips, it's possible that these
> might span multiple messages, larger than the maximum netlink packet
> size. For that reason, wg(8) will properly split things into several
> calls. Here's the set call:
>
> https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n558
>
> It accounts for toobig_allowedips and toobig_peers with some goto
> jumps that are sure to make your eyes bleed (read: you can do better
> than that :-). Similar in the get call, we coalesce peers that span
> multiple messages:
>
> https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n899
> https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n877
>
> The other thing that might be sort of neat to try to implement is
> falling back to the userspace API:
>
> https://www.wireguard.com/xplatform/
>
> This is a simple unix socket-based approach that mimics the same
> semantics as the netlink API, but is portable to different platforms.
> This is what wireguard-go and wireguard-rs and friends use for
> configuration. wg(8) implements both and provides an identical
> frontend for the two. However, I imagine you starting with netlink
> will be much more useful and is a good decision, since serious
> wireguard users are expected to continue using the serious kernel
> implementation.
>
>> While I'm here, I did have one inquiry about "WG_CMD_GET_DEVICE": after
>> working with a handful of generic netlink families, I was slightly
>> surprised to see that a request paired with "NLM_F_DUMP" doesn't return
>> a list of all WireGuard devices from the kernel.
> The thing you're dumping from a single device is all the peers. If you
> want a list of all interfaces, then the place to NLM_F_DUMP is
> RTM_GETLINK, where you can then inspect
> ifinfomsg->IFLA_LINKINFO->IFLA_INFO_KIND and make sure that it's
> "wireguard". WireGuard itself doesn't [necessarily need to] know all
> of the instances of itself, since it's instantiated by the rtnl
> subsystem. Check out kernel_get_wireguard_interfaces here:
>
> https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n458
>
> If you're on IRC, come on into #wireguard on Freenode and poke me, and
> we can chat about it further; I'm zx2c4.
>
> Talk soon,
> Jason
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] block/file-posix: add bdrv_attach_aio_context callback for host dev and cdrom
From: Farhan Ali @ 2018-07-23 13:34 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Eric Blake, Kevin Wolf, John Snow, Max Reitz, Stefan Hajnoczi,
Fam Zheng, Paolo Bonzini, qemu-block, qemu-devel
In-Reply-To: <a1269390-a798-9165-aaf5-a2aa6270bd54@linux.ibm.com>
On 07/20/2018 03:11 PM, Farhan Ali wrote:
> I am seeing another issue pop up, in a different test. Even though it's
> a different assertion, it might be related based on the call trace.
>
> Stack trace of thread 276199:
> #0 0x000003ff8473e274 raise (libc.so.6)
> #1 0x000003ff847239a8 abort (libc.so.6)
> #2 0x000003ff847362ce __assert_fail_base (libc.so.6)
> #3 0x000003ff8473634c __assert_fail (libc.so.6)
> #4 0x000002aa30aba0c4 iov_memset (qemu-system-s390x)
> #5 0x000002aa30aba9a6 qemu_iovec_memset (qemu-system-s390x)
> #6 0x000002aa30a23e88 qemu_laio_process_completion (qemu-system-s390x)
> #7 0x000002aa30a23f68 qemu_laio_process_completions (qemu-system-s390x)
> #8 0x000002aa30a2418e qemu_laio_process_completions_and_submit
> (qemu-system-s390x)
> #9 0x000002aa30a24220 qemu_laio_poll_cb (qemu-system-s390x)
> #10 0x000002aa30ab22c4 run_poll_handlers_once (qemu-system-s390x)
> #11 0x000002aa30ab2e78 aio_poll (qemu-system-s390x)
> #12 0x000002aa30a29f4e bdrv_do_drained_begin (qemu-system-s390x)
> #13 0x000002aa30a2a276 bdrv_drain (qemu-system-s390x)
> #14 0x000002aa309d45aa bdrv_set_aio_context (qemu-system-s390x)
> #15 0x000002aa3085acfe virtio_blk_data_plane_stop (qemu-system-s390x)
> #16 0x000002aa3096994c virtio_bus_stop_ioeventfd.part.1 (qemu-system-s390x)
> #17 0x000002aa3087d1d6 virtio_vmstate_change (qemu-system-s390x)
> #18 0x000002aa308e8a12 vm_state_notify (qemu-system-s390x)
> #19 0x000002aa3080ed54 do_vm_stop (qemu-system-s390x)
> #20 0x000002aa307bea04 main (qemu-system-s390x)
> #21 0x000003ff84723dd2 __libc_start_main (libc.so.6)
> #22 0x000002aa307c0414 _start (qemu-system-s390x)
>
>
> The failing assertion is:
>
> qemu-kvm: util/iov.c:78: iov_memset: Assertion `offset == 0' failed.
>
Just to give some context, this a guest with 2 disks with each assigned
an iothread. The guest was running a memory intensive workload.
From the coredump of the qemu process, I see there were 2 threads that
were trying to call aio_poll with the same AioContext on the same
BlockDeviceDriver
Thread 1:
#0 0x000003ff8473e274 in raise () from /lib64/libc.so.6
#1 0x000003ff847239a8 in abort () from /lib64/libc.so.6
#2 0x000003ff847362ce in __assert_fail_base () from /lib64/libc.so.6
#3 0x000003ff8473634c in __assert_fail () from /lib64/libc.so.6
#4 0x000002aa30aba0c4 in iov_memset (iov=<optimized out>,
iov_cnt=<optimized out>, offset=<optimized out>, fillc=<optimized out>,
bytes=18446744073709547520) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/iov.c:78
#5 0x000002aa30aba9a6 in qemu_iovec_memset (qiov=<optimized out>,
offset=offset@entry=8192, fillc=fillc@entry=0,
bytes=18446744073709547520) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/iov.c:410
#6 0x000002aa30a23e88 in qemu_laio_process_completion
(laiocb=0x3fe36a6a3f0) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/linux-aio.c:88
#7 0x000002aa30a23f68 in qemu_laio_process_completions
(s=s@entry=0x3fe60001910) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/linux-aio.c:222
#8 0x000002aa30a2418e in qemu_laio_process_completions_and_submit
(s=0x3fe60001910) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/linux-aio.c:237
#9 0x000002aa30a24220 in qemu_laio_poll_cb (opaque=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/linux-aio.c:272
#10 0x000002aa30ab22c4 in run_poll_handlers_once
(ctx=ctx@entry=0x2aa4f35df50) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/aio-posix.c:494
#11 0x000002aa30ab2e78 in try_poll_mode (blocking=<optimized out>,
ctx=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/aio-posix.c:573
====> #12 aio_poll (ctx=0x2aa4f35df50, blocking=blocking@entry=false)
at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/aio-posix.c:602
#13 0x000002aa30a29f4e in bdrv_drain_poll_top_level
(ignore_parent=<optimized out>, recursive=<optimized out>, bs=<optimized
out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/io.c:390
#14 bdrv_do_drained_begin (bs=0x2aa4f392510, recursive=<optimized out>,
parent=0x0, ignore_bds_parents=<optimized out>, poll=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/io.c:390
#15 0x000002aa30a2a276 in bdrv_drained_begin (bs=0x2aa4f392510) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/io.c:396
#16 bdrv_drain (bs=bs@entry=0x2aa4f392510) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/io.c:478
#17 0x000002aa309d45aa in bdrv_set_aio_context (bs=0x2aa4f392510,
new_context=0x2aa4f3594f0) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block.c:4954
#18 0x000002aa30a1c228 in blk_set_aio_context
(blk=blk@entry=0x2aa4f38ed90, new_context=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/block-backend.c:1894
#19 0x000002aa3085acfe in virtio_blk_data_plane_stop (vdev=<optimized
out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/hw/block/dataplane/virtio-blk.c:285
#20 0x000002aa3096994c in virtio_bus_stop_ioeventfd (bus=0x2aa4f4f61f0)
at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/hw/virtio/virtio-bus.c:246
#21 0x000002aa3087d1d6 in virtio_vmstate_change (opaque=0x2aa4f4f72b8,
running=<optimized out>, state=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/hw/virtio/virtio.c:2222
#22 0x000002aa308e8a12 in vm_state_notify (running=<optimized out>,
state=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/vl.c:1532
#23 0x000002aa3080ed54 in do_vm_stop (state=<optimized out>,
send_stop=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/cpus.c:1012
#24 0x000002aa307bea04 in main (argc=<optimized out>, argv=<optimized
out>, envp=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/vl.c:4649
Thread 2 which is an IOThread:
#0 0x000003ff84910f9e in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x000003ff8490a1a2 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2 0x000002aa30ab4cea in qemu_mutex_lock_impl (mutex=0x2aa4f35dfb0,
file=file@entry=0x2aa30b963f4
"/builddir/build/BUILD/qemu-2.12.91/util/async.c", line=line@entry=511)
at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/qemu-thread-posix.c:66
#3 0x000002aa30aafff4 in aio_context_acquire (ctx=<optimized out>) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/async.c:511
#4 0x000002aa30a2419a in qemu_laio_process_completions_and_submit
(s=0x3fe60001910) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/block/linux-aio.c:239
#5 0x000002aa30ab23ee in aio_dispatch_handlers
(ctx=ctx@entry=0x2aa4f35df50) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/aio-posix.c:406
=====> #6 0x000002aa30ab30b4 in aio_poll (ctx=0x2aa4f35df50,
blocking=blocking@entry=true) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/util/aio-posix.c:692
#7 0x000002aa308e2322 in iothread_run (opaque=0x2aa4f35d5c0) at
/usr/src/debug/qemu-2.12.91-20180720.0.677af45304.fc28.s390x/iothread.c:63
#8 0x000003ff849079a8 in start_thread () from /lib64/libpthread.so.0
#9 0x000003ff847f97ee in thread_start () from /lib64/libc.so.6
This looked a little suspicious to me, I don't if this the expected
behavior or there is a race condition here. Any help debugging this
would be greatly appreciated.
Thanks
Farhan
^ permalink raw reply
* Re: [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU
From: Waiman Long @ 2018-07-23 13:33 UTC (permalink / raw)
To: Wanpeng Li, Paolo Bonzini, Radim Krcmar
Cc: Davidlohr Bueso, Boris Ostrovsky, Juergen Gross, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, the arch/x86 maintainers, xen-devel,
LKML, Konrad Rzeszutek Wilk
In-Reply-To: <CANRm+CyHfvBKVKNk+pKF+s6+1seZ8c+NyjHuepT2Mf+4Cdd-2w@mail.gmail.com>
On 07/22/2018 11:31 PM, Wanpeng Li wrote:
> On Fri, 20 Jul 2018 at 06:03, Waiman Long <longman@redhat.com> wrote:
>> On 07/19/2018 05:54 PM, Davidlohr Bueso wrote:
>>> On Thu, 19 Jul 2018, Waiman Long wrote:
>>>
>>>> On a VM with only 1 vCPU, the locking fast paths will always be
>>>> successful. In this case, there is no need to use the the PV qspinlock
>>>> code which has higher overhead on the unlock side than the native
>>>> qspinlock code.
>>>>
>>>> The xen_pvspin veriable is also turned off in this 1 vCPU case to
>>>> eliminate unneeded pvqspinlock initialization in xen_init_lock_cpu()
>>>> which is run after xen_init_spinlocks().
>>> Wouldn't kvm also want this?
>>>
>>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>>> index a37bda38d205..95aceb692010 100644
>>> --- a/arch/x86/kernel/kvm.c
>>> +++ b/arch/x86/kernel/kvm.c
>>> @@ -457,7 +457,8 @@ static void __init sev_map_percpu_data(void)
>>> static void __init kvm_smp_prepare_cpus(unsigned int max_cpus)
>>> {
>>> native_smp_prepare_cpus(max_cpus);
>>> - if (kvm_para_has_hint(KVM_HINTS_REALTIME))
>>> + if (num_possible_cpus() == 1 ||
>>> + kvm_para_has_hint(KVM_HINTS_REALTIME))
>>> static_branch_disable(&virt_spin_lock_key);
>>> }
>> That doesn't really matter as the slowpath will never get executed in
>> the 1 vCPU case.
> So this is not needed in kvm tree?
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=queue&id=3a792199004ec335346cc607d62600a399a7ee02
>
> Regards,
> Wanpeng Li
With only 1 vCPU, the slowpath will not be executed. It will be a
deadlock if it happens. So we don't need to explicitly disable the
static key here.
-Longman
^ permalink raw reply
* Re: [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU
From: Waiman Long @ 2018-07-23 13:33 UTC (permalink / raw)
To: Wanpeng Li, Paolo Bonzini, Radim Krcmar
Cc: Juergen Gross, Davidlohr Bueso, the arch/x86 maintainers, LKML,
Ingo Molnar, H. Peter Anvin, xen-devel, Boris Ostrovsky,
Thomas Gleixner
In-Reply-To: <CANRm+CyHfvBKVKNk+pKF+s6+1seZ8c+NyjHuepT2Mf+4Cdd-2w@mail.gmail.com>
On 07/22/2018 11:31 PM, Wanpeng Li wrote:
> On Fri, 20 Jul 2018 at 06:03, Waiman Long <longman@redhat.com> wrote:
>> On 07/19/2018 05:54 PM, Davidlohr Bueso wrote:
>>> On Thu, 19 Jul 2018, Waiman Long wrote:
>>>
>>>> On a VM with only 1 vCPU, the locking fast paths will always be
>>>> successful. In this case, there is no need to use the the PV qspinlock
>>>> code which has higher overhead on the unlock side than the native
>>>> qspinlock code.
>>>>
>>>> The xen_pvspin veriable is also turned off in this 1 vCPU case to
>>>> eliminate unneeded pvqspinlock initialization in xen_init_lock_cpu()
>>>> which is run after xen_init_spinlocks().
>>> Wouldn't kvm also want this?
>>>
>>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>>> index a37bda38d205..95aceb692010 100644
>>> --- a/arch/x86/kernel/kvm.c
>>> +++ b/arch/x86/kernel/kvm.c
>>> @@ -457,7 +457,8 @@ static void __init sev_map_percpu_data(void)
>>> static void __init kvm_smp_prepare_cpus(unsigned int max_cpus)
>>> {
>>> native_smp_prepare_cpus(max_cpus);
>>> - if (kvm_para_has_hint(KVM_HINTS_REALTIME))
>>> + if (num_possible_cpus() == 1 ||
>>> + kvm_para_has_hint(KVM_HINTS_REALTIME))
>>> static_branch_disable(&virt_spin_lock_key);
>>> }
>> That doesn't really matter as the slowpath will never get executed in
>> the 1 vCPU case.
> So this is not needed in kvm tree?
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=queue&id=3a792199004ec335346cc607d62600a399a7ee02
>
> Regards,
> Wanpeng Li
With only 1 vCPU, the slowpath will not be executed. It will be a
deadlock if it happens. So we don't need to explicitly disable the
static key here.
-Longman
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: Query about the handling of a bug reported before
From: Brian Foster @ 2018-07-23 12:32 UTC (permalink / raw)
To: Xu, Wen; +Cc: linux-xfs@vger.kernel.org, Dave Chinner, Darrick J. Wong
In-Reply-To: <21AA8603-85D9-429A-A713-8B86F341FFC4@gatech.edu>
On Sun, Jul 22, 2018 at 06:30:03AM +0000, Xu, Wen wrote:
> Hi XFS developers,
>
> I wonder if this bug
>
> https://bugzilla.kernel.org/show_bug.cgi?id=200127
>
> has already been resolved by any patch.
>
It looks like you're on a kernel that already has the agfl reset
mechanism. I'm not aware of anything else in that area off the top of my
head, but FWIW, I don't see the KASAN error with a quick check on a
KASAN-enabled latest for-next (4.18.0-rc4) kernel. Have you given that a
try?
Brian
> Thanks,
> Wen
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 0/2] firmware: ti_sci: Add host-id as an optional parameter
From: Nishanth Menon @ 2018-07-23 13:33 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Santosh Shilimkar, Tero Kristo
Cc: linux-kernel, devicetree, linux-arm-kernel, geert
In-Reply-To: <20180716171328.11674-1-nm@ti.com>
On 17:13-20180716, Nishanth Menon wrote:
> Please find attached series to enable host-id as an optional dt property.
>
> This is a minor update to V1 -> Mostly to pick up Greet's feedback and Rob's Ack.
>
> V1: https://patchwork.ozlabs.org/cover/931822/
>
> The series is based on v4.18-rc1 and is available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-tisci
>
> Consolidated all patches (including all series) are available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>
> Full Boot log (integrated of all series for AM654) is available here:
> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>
> Nishanth Menon (2):
> Documentation: dt: keystone: ti-sci: Add optional host-id parameter
> firmware: ti_sci: Provide host-id as an optional dt parameter
>
> .../devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
> drivers/firmware/ti_sci.c | 24 ++++++++++++++++++----
> 2 files changed, 24 insertions(+), 4 deletions(-)
Santosh,
Apologies, I see you have already send your PR for v4.19. Was
just wondering if this is something we can consider for rc
cycle OR if you'd consider a followup PR for the same.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH V2 0/2] firmware: ti_sci: Add host-id as an optional parameter
From: Nishanth Menon @ 2018-07-23 13:33 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Santosh Shilimkar, Tero Kristo
Cc: linux-kernel, devicetree, linux-arm-kernel, geert
In-Reply-To: <20180716171328.11674-1-nm@ti.com>
On 17:13-20180716, Nishanth Menon wrote:
> Please find attached series to enable host-id as an optional dt property.
>
> This is a minor update to V1 -> Mostly to pick up Greet's feedback and Rob's Ack.
>
> V1: https://patchwork.ozlabs.org/cover/931822/
>
> The series is based on v4.18-rc1 and is available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-tisci
>
> Consolidated all patches (including all series) are available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>
> Full Boot log (integrated of all series for AM654) is available here:
> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>
> Nishanth Menon (2):
> Documentation: dt: keystone: ti-sci: Add optional host-id parameter
> firmware: ti_sci: Provide host-id as an optional dt parameter
>
> .../devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
> drivers/firmware/ti_sci.c | 24 ++++++++++++++++++----
> 2 files changed, 24 insertions(+), 4 deletions(-)
Santosh,
Apologies, I see you have already send your PR for v4.19. Was
just wondering if this is something we can consider for rc
cycle OR if you'd consider a followup PR for the same.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH V2 0/2] firmware: ti_sci: Add host-id as an optional parameter
From: Nishanth Menon @ 2018-07-23 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180716171328.11674-1-nm@ti.com>
On 17:13-20180716, Nishanth Menon wrote:
> Please find attached series to enable host-id as an optional dt property.
>
> This is a minor update to V1 -> Mostly to pick up Greet's feedback and Rob's Ack.
>
> V1: https://patchwork.ozlabs.org/cover/931822/
>
> The series is based on v4.18-rc1 and is available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-tisci
>
> Consolidated all patches (including all series) are available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>
> Full Boot log (integrated of all series for AM654) is available here:
> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>
> Nishanth Menon (2):
> Documentation: dt: keystone: ti-sci: Add optional host-id parameter
> firmware: ti_sci: Provide host-id as an optional dt parameter
>
> .../devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
> drivers/firmware/ti_sci.c | 24 ++++++++++++++++++----
> 2 files changed, 24 insertions(+), 4 deletions(-)
Santosh,
Apologies, I see you have already send your PR for v4.19. Was
just wondering if this is something we can consider for rc
cycle OR if you'd consider a followup PR for the same.
--
Regards,
Nishanth Menon
^ permalink raw reply
* ✗ patchtest: failure for iputils: upgrade to s20190629
From: Patchwork @ 2018-07-23 13:32 UTC (permalink / raw)
To: Ross Burton; +Cc: openembedded-core
In-Reply-To: <20180723131604.24326-1-ross.burton@intel.com>
== Series Details ==
Series: iputils: upgrade to s20190629
Revision: 1
URL : https://patchwork.openembedded.org/series/13153/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:
* Issue LIC_FILES_CHKSUM changed on target iputils but there is no "License-Update" tag in commit message [test_lic_files_chksum_modified_not_mentioned]
Suggested fix Include "License-Update: <description>" into the commit message with a brief description
Current checksum file://ping.c;beginline=1;endline=35;md5=f9ceb201733e9a6cf8f00766dd278d82 file://tracepath.c;beginline=1;endline=10;md5=0ecea2bf60bff2f3d840096d87647f3d file://arping.c;beginline=1;endline=11;md5=fe84301b5c2655c950f8b92a057fafa6 file://tftpd.c;beginline=1;endline=32;md5=28834bf8a91a5b8a92755dbee709ef96
New checksum file://LICENSE;md5=b792e38abdc59f766a3153908f23e766 file://LICENSE.BSD3;md5=0f00d99239d922ffd13cabef83b33444 file://LICENSE.GPL2;md5=b234ee4d69f5fce4486a80fdaf4a4263
If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).
---
Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
^ permalink raw reply
* Re: [PATCH 05/11] touchscreen: elants: Use octal permissions
From: Greg Kroah-Hartman @ 2018-07-23 13:32 UTC (permalink / raw)
To: dev-harsh1998
Cc: trivial, Dmitry Torokhov, Simon Budig, Andi Shyti, Luca Ceresoli,
Joe Perches, Guenter Roeck, linux-input, linux-kernel
In-Reply-To: <20180723131954.30739-4-harshitjain6751@gmail.com>
On Mon, Jul 23, 2018 at 06:49:20PM +0530, dev-harsh1998 wrote:
> WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> +static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
>
> WARNING: Symbolic permissions 'S_IWUSR' are not preferred. Consider using octal permissions '0200'.
> +static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw)
>
> WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> + .dattr = __ATTR(_field, S_IRUGO, \
>
> Signed-off-by: Harshit Jain <harshitjain6751@gmail.com>
This name doesn't match up with the From: line above :(
Please fix up and try again.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v3] tg: show the sum wait time of an task group
From: 王贇 @ 2018-07-23 13:31 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra, linux-kernel
In-Reply-To: <ff7dae3b-e5f9-7157-1caa-ff02c6b23dc1@linux.alibaba.com>
Although we can rely on cpuacct to present the cpu usage of task
group, it is hard to tell how intense the competition is between
these groups on cpu resources.
Monitoring the wait time of each process or sched_debug could cost
too much, and there is no good way to accurately represent the
conflict with these info, we need the wait time on group dimension.
Thus we introduced group's wait_sum represent the conflict between
task groups, which is simply sum the wait time of group's cfs_rq.
The 'cpu.stat' is modified to show the statistic, like:
nr_periods 0
nr_throttled 0
throttled_time 0
wait_sum 2035098795584
Now we can monitor the changing on wait_sum to tell how suffering
a task group is in the fight of cpu resources.
For example:
(wait_sum - last_wait_sum) * 100 / (nr_cpu * period_ns) == X%
means the task group paid X percentage of period on waiting
for the cpu.
Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
---
Since v2:
Declare variables inside branch (From Peter).
kernel/sched/core.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78d8fac..2a7bb7c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6788,6 +6788,15 @@ static int cpu_cfs_stat_show(struct seq_file *sf, void *v)
seq_printf(sf, "nr_throttled %d\n", cfs_b->nr_throttled);
seq_printf(sf, "throttled_time %llu\n", cfs_b->throttled_time);
+ if (schedstat_enabled() && tg != &root_task_group) {
+ int i;
+ u64 ws = 0;
+
+ for_each_possible_cpu(i)
+ ws += schedstat_val(tg->se[i]->statistics.wait_sum);
+ seq_printf(sf, "wait_sum %llu\n", ws);
+ }
+
return 0;
}
#endif /* CONFIG_CFS_BANDWIDTH */
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] btrfs: extent-tree: Remove dead alignment check
From: David Sterba @ 2018-07-23 12:29 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
In-Reply-To: <20180723064729.9236-1-wqu@suse.com>
On Mon, Jul 23, 2018 at 02:47:29PM +0800, Qu Wenruo wrote:
> In find_free_extent() under checks: tag, we have the following code
>
> ------
> search_start = ALIGN(offset, fs_info->stripesize);
> /* move on to the next group */
> if (search_start + num_bytes >
> block_group->key.objectid + block_group->key.offset) {
> btrfs_add_free_space(block_group, offset, num_bytes);
> goto loop;
> }
> if (offset < search_start)
> btrfs_add_free_space(block_group, offset,
> search_start - offset);
> BUG_ON(offset > search_start);
> ------
>
> However ALIGN() is rounding up, thus @search_start >= @offset and that
> BUG_ON() will never be triggered.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
^ permalink raw reply
* Re: [PATCH V2 0/6] mailbox: ti-msgmgr: Add support for AM654 Secure Proxy
From: Nishanth Menon @ 2018-07-23 13:29 UTC (permalink / raw)
To: Jassi Brar, Mark Rutland, Rob Herring
Cc: Suman Anna, Tero Kristo, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <20180716180607.16526-1-nm@ti.com>
On 18:06-20180716, Nishanth Menon wrote:
> The V2 of the series updates a minor comment in binding and picks up Rob's Reviewed-by
>
> Since I have'nt seen additional comments, I am assuming things are fine for v4.19.
>
> The following series enables support for Secure Proxy in newest addition in TI's SoC
> portfolio - AM654 SoC (posted previously as RFC).
>
> The series is based on v4.18-rc1 and is available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-sproxy
>
> There are a couple of follow on patches to be posted as well (Kconfig changes
> for K3_ARCH and actual dts node changes).
>
> Changes since RFC are highlighted in each of the patches, but overall:
> * The K3 dependency has been broken out into a seperate series independent of
> this.
> * Binding has been seperated out as it's own file (even though the driver is
> reused).
>
> Consolidated all patches (including all series) are available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>
> Full Boot log on AM654 (integrated with all patch series) is available here:
> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>
> Nishanth Menon (6):
> mailbox: ti-msgmgr: Get rid of unused structure members
> mailbox: ti-msgmgr: Allocate Rx channel resources only on request
> mailbox: ti-msgmgr: Change message count mask to be descriptor based
> mailbox: ti-msgmgr: Move the memory region name to descriptor
> dt-bindings: mailbox: Add support for secure proxy threads
> mailbox: ti-msgmgr: Add support for Secure Proxy
>
> .../bindings/mailbox/ti,secure-proxy.txt | 50 +++
> drivers/mailbox/ti-msgmgr.c | 353 +++++++++++++++++----
> 2 files changed, 336 insertions(+), 67 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
Jassi,
I dont see this in next-20180723. You'd asked me to hold off on pings
https://lkml.org/lkml/2017/12/16/353 -> so, held off as much as I could
before wondering on the status.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)
From: Josh Poimboeuf @ 2018-07-23 13:30 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, Prashant Bhole, linux-kernel
In-Reply-To: <20180719211954.GZ2512@hirez.programming.kicks-ass.net>
On Thu, Jul 19, 2018 at 11:19:54PM +0200, Peter Zijlstra wrote:
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -143,6 +143,8 @@ enum perf_event_sample_format {
> PERF_SAMPLE_PHYS_ADDR = 1U << 19,
>
> PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */
> +
> + __PERF_SAMPLE_CALLCHAIN_EARLY = 1UL << 63,
Given the kbuild test robot errors for building on 32-bit, looks like
the 63 needs to be changed to 31 so it fits in an int?
--
Josh
^ permalink raw reply
* Re: [PATCH V2 0/6] mailbox: ti-msgmgr: Add support for AM654 Secure Proxy
From: Nishanth Menon @ 2018-07-23 13:29 UTC (permalink / raw)
To: Jassi Brar, Mark Rutland, Rob Herring
Cc: Suman Anna, Tero Kristo, linux-kernel, devicetree,
linux-arm-kernel
In-Reply-To: <20180716180607.16526-1-nm@ti.com>
On 18:06-20180716, Nishanth Menon wrote:
> The V2 of the series updates a minor comment in binding and picks up Rob's Reviewed-by
>
> Since I have'nt seen additional comments, I am assuming things are fine for v4.19.
>
> The following series enables support for Secure Proxy in newest addition in TI's SoC
> portfolio - AM654 SoC (posted previously as RFC).
>
> The series is based on v4.18-rc1 and is available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-sproxy
>
> There are a couple of follow on patches to be posted as well (Kconfig changes
> for K3_ARCH and actual dts node changes).
>
> Changes since RFC are highlighted in each of the patches, but overall:
> * The K3 dependency has been broken out into a seperate series independent of
> this.
> * Binding has been seperated out as it's own file (even though the driver is
> reused).
>
> Consolidated all patches (including all series) are available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>
> Full Boot log on AM654 (integrated with all patch series) is available here:
> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>
> Nishanth Menon (6):
> mailbox: ti-msgmgr: Get rid of unused structure members
> mailbox: ti-msgmgr: Allocate Rx channel resources only on request
> mailbox: ti-msgmgr: Change message count mask to be descriptor based
> mailbox: ti-msgmgr: Move the memory region name to descriptor
> dt-bindings: mailbox: Add support for secure proxy threads
> mailbox: ti-msgmgr: Add support for Secure Proxy
>
> .../bindings/mailbox/ti,secure-proxy.txt | 50 +++
> drivers/mailbox/ti-msgmgr.c | 353 +++++++++++++++++----
> 2 files changed, 336 insertions(+), 67 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
Jassi,
I dont see this in next-20180723. You'd asked me to hold off on pings
https://lkml.org/lkml/2017/12/16/353 -> so, held off as much as I could
before wondering on the status.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH V2 0/6] mailbox: ti-msgmgr: Add support for AM654 Secure Proxy
From: Nishanth Menon @ 2018-07-23 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180716180607.16526-1-nm@ti.com>
On 18:06-20180716, Nishanth Menon wrote:
> The V2 of the series updates a minor comment in binding and picks up Rob's Reviewed-by
>
> Since I have'nt seen additional comments, I am assuming things are fine for v4.19.
>
> The following series enables support for Secure Proxy in newest addition in TI's SoC
> portfolio - AM654 SoC (posted previously as RFC).
>
> The series is based on v4.18-rc1 and is available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-sproxy
>
> There are a couple of follow on patches to be posted as well (Kconfig changes
> for K3_ARCH and actual dts node changes).
>
> Changes since RFC are highlighted in each of the patches, but overall:
> * The K3 dependency has been broken out into a seperate series independent of
> this.
> * Binding has been seperated out as it's own file (even though the driver is
> reused).
>
> Consolidated all patches (including all series) are available here:
> https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
>
> Full Boot log on AM654 (integrated with all patch series) is available here:
> https://pastebin.ubuntu.com/p/bBFmnzYtCd/
>
> Nishanth Menon (6):
> mailbox: ti-msgmgr: Get rid of unused structure members
> mailbox: ti-msgmgr: Allocate Rx channel resources only on request
> mailbox: ti-msgmgr: Change message count mask to be descriptor based
> mailbox: ti-msgmgr: Move the memory region name to descriptor
> dt-bindings: mailbox: Add support for secure proxy threads
> mailbox: ti-msgmgr: Add support for Secure Proxy
>
> .../bindings/mailbox/ti,secure-proxy.txt | 50 +++
> drivers/mailbox/ti-msgmgr.c | 353 +++++++++++++++++----
> 2 files changed, 336 insertions(+), 67 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/ti,secure-proxy.txt
Jassi,
I dont see this in next-20180723. You'd asked me to hold off on pings
https://lkml.org/lkml/2017/12/16/353 -> so, held off as much as I could
before wondering on the status.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v2 2/2] crypto/scheduler: add packet-size-distr mode param parse
From: Fan Zhang @ 2018-07-23 13:17 UTC (permalink / raw)
To: dev; +Cc: pablo.de.lara.guarch
In-Reply-To: <20180723131715.62875-1-roy.fan.zhang@intel.com>
This patch adds packet-size-distr mode specific parameter parser
to support different threshold packet size value other than default
128 bytes.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
doc/guides/cryptodevs/scheduler.rst | 7 ++-
drivers/crypto/scheduler/rte_cryptodev_scheduler.h | 1 +
drivers/crypto/scheduler/scheduler_pmd.c | 53 ++++++++++++++++++++++
3 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index 4d7f5b152..a754a27e6 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -137,7 +137,12 @@ operation:
**option_type** must be **CDEV_SCHED_OPTION_THRESHOLD** and **option** should
point to a rte_cryptodev_scheduler_threshold_option structure filled with
appropriate threshold value. Please NOTE this threshold has be a power-of-2
- unsigned integer.
+ unsigned integer. It is possible to use **mode_param** initialization
+ parameter to achieve the same purpose. For example:
+
+ ... --vdev "crypto_scheduler,mode=packet-size-distr,mode_param=threshold:512" ...
+
+ The above parameter will overwrite the threshold value to 512.
* **CDEV_SCHED_MODE_FAILOVER:**
diff --git a/drivers/crypto/scheduler/rte_cryptodev_scheduler.h b/drivers/crypto/scheduler/rte_cryptodev_scheduler.h
index 1c164da7c..3faea4099 100644
--- a/drivers/crypto/scheduler/rte_cryptodev_scheduler.h
+++ b/drivers/crypto/scheduler/rte_cryptodev_scheduler.h
@@ -76,6 +76,7 @@ enum rte_cryptodev_schedule_option_type {
/**
* Threshold option structure
*/
+#define RTE_CRYPTODEV_SCHEDULER_PARAM_THRES "threshold"
struct rte_cryptodev_scheduler_threshold_option {
uint32_t threshold; /**< Threshold for packet-size mode */
};
diff --git a/drivers/crypto/scheduler/scheduler_pmd.c b/drivers/crypto/scheduler/scheduler_pmd.c
index ac9185e65..a9221a946 100644
--- a/drivers/crypto/scheduler/scheduler_pmd.c
+++ b/drivers/crypto/scheduler/scheduler_pmd.c
@@ -71,6 +71,8 @@ const struct scheduler_parse_map scheduler_ordering_map[] = {
{"disable", 0}
};
+#define CDEV_SCHED_MODE_PARAM_SEP_CHAR ':'
+
static int
cryptodev_scheduler_create(const char *name,
struct rte_vdev_device *vdev,
@@ -110,6 +112,15 @@ cryptodev_scheduler_create(const char *name,
if (init_params->mode > CDEV_SCHED_MODE_USERDEFINED &&
init_params->mode < CDEV_SCHED_MODE_COUNT) {
+ union {
+ struct rte_cryptodev_scheduler_threshold_option
+ threshold_option;
+ } option;
+ enum rte_cryptodev_schedule_option_type option_type;
+ char param_name[RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN] = {0};
+ char param_val[RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN] = {0};
+ char *s, *end;
+
ret = rte_cryptodev_scheduler_mode_set(dev->data->dev_id,
init_params->mode);
if (ret < 0) {
@@ -125,6 +136,48 @@ cryptodev_scheduler_create(const char *name,
scheduler_mode_map[i].name);
break;
}
+
+ if (strlen(init_params->mode_param_str) > 0) {
+ s = strchr(init_params->mode_param_str,
+ CDEV_SCHED_MODE_PARAM_SEP_CHAR);
+ if (s == NULL) {
+ CR_SCHED_LOG(ERR, "Invalid mode param");
+ return -EINVAL;
+ }
+
+ strlcpy(param_name, init_params->mode_param_str,
+ s - init_params->mode_param_str + 1);
+ s++;
+ strlcpy(param_val, s,
+ RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN);
+
+ switch (init_params->mode) {
+ case CDEV_SCHED_MODE_PKT_SIZE_DISTR:
+ if (strcmp(param_name,
+ RTE_CRYPTODEV_SCHEDULER_PARAM_THRES)
+ != 0) {
+ CR_SCHED_LOG(ERR, "Invalid mode param");
+ return -EINVAL;
+ }
+ option_type = CDEV_SCHED_OPTION_THRESHOLD;
+
+ option.threshold_option.threshold =
+ strtoul(param_val, &end, 0);
+ break;
+ default:
+ CR_SCHED_LOG(ERR, "Invalid mode param");
+ return -EINVAL;
+ }
+
+ if (sched_ctx->ops.option_set(dev, option_type,
+ (void *)&option) < 0) {
+ CR_SCHED_LOG(ERR, "Invalid mode param");
+ return -EINVAL;
+ }
+
+ RTE_LOG(INFO, PMD, " Sched mode param (%s = %s)\n",
+ param_name, param_val);
+ }
}
sched_ctx->reordering_enabled = init_params->enable_ordering;
--
2.13.6
^ permalink raw reply related
* [PATCH v2 1/2] crypto/scheduler: add mode param parsing
From: Fan Zhang @ 2018-07-23 13:17 UTC (permalink / raw)
To: dev; +Cc: pablo.de.lara.guarch
In-Reply-To: <20180723131715.62875-1-roy.fan.zhang@intel.com>
This patch adds the mode parameter parsing to scheduler PMD.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
doc/guides/cryptodevs/scheduler.rst | 5 +++++
drivers/crypto/scheduler/scheduler_pmd.c | 22 ++++++++++++++++++++++
2 files changed, 27 insertions(+)
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index d67894d55..4d7f5b152 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -71,6 +71,11 @@ two calls:
mode parameter values are specified in the "Cryptodev Scheduler Modes
Overview" section.
+* mode_param: Specify the mode-specific parameter. Some scheduling modes
+ may be initialized with specific parameters other than the default ones,
+ such as the **threshold** packet size of **packet-size-distr** mode. This
+ parameter fulfills the purpose.
+
* ordering: Specify the status of the crypto operations ordering feature.
The value of this parameter can be "enable" or "disable". This feature
is disabled by default.
diff --git a/drivers/crypto/scheduler/scheduler_pmd.c b/drivers/crypto/scheduler/scheduler_pmd.c
index 6c5c01d63..ac9185e65 100644
--- a/drivers/crypto/scheduler/scheduler_pmd.c
+++ b/drivers/crypto/scheduler/scheduler_pmd.c
@@ -9,6 +9,7 @@
#include <rte_malloc.h>
#include <rte_cpuflags.h>
#include <rte_reorder.h>
+#include <rte_string_fns.h>
#include "rte_cryptodev_scheduler.h"
#include "scheduler_pmd_private.h"
@@ -19,6 +20,7 @@ struct scheduler_init_params {
struct rte_cryptodev_pmd_init_params def_p;
uint32_t nb_slaves;
enum rte_cryptodev_scheduler_mode mode;
+ char mode_param_str[RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN];
uint32_t enable_ordering;
uint16_t wc_pool[RTE_MAX_LCORE];
uint16_t nb_wc;
@@ -29,6 +31,7 @@ struct scheduler_init_params {
#define RTE_CRYPTODEV_VDEV_NAME ("name")
#define RTE_CRYPTODEV_VDEV_SLAVE ("slave")
#define RTE_CRYPTODEV_VDEV_MODE ("mode")
+#define RTE_CRYPTODEV_VDEV_MODE_PARAM ("mode_param")
#define RTE_CRYPTODEV_VDEV_ORDERING ("ordering")
#define RTE_CRYPTODEV_VDEV_MAX_NB_QP_ARG ("max_nb_queue_pairs")
#define RTE_CRYPTODEV_VDEV_SOCKET_ID ("socket_id")
@@ -39,6 +42,7 @@ const char *scheduler_valid_params[] = {
RTE_CRYPTODEV_VDEV_NAME,
RTE_CRYPTODEV_VDEV_SLAVE,
RTE_CRYPTODEV_VDEV_MODE,
+ RTE_CRYPTODEV_VDEV_MODE_PARAM,
RTE_CRYPTODEV_VDEV_ORDERING,
RTE_CRYPTODEV_VDEV_MAX_NB_QP_ARG,
RTE_CRYPTODEV_VDEV_SOCKET_ID,
@@ -346,6 +350,7 @@ parse_mode_arg(const char *key __rte_unused,
if (strcmp(value, scheduler_mode_map[i].name) == 0) {
param->mode = (enum rte_cryptodev_scheduler_mode)
scheduler_mode_map[i].val;
+
break;
}
}
@@ -359,6 +364,18 @@ parse_mode_arg(const char *key __rte_unused,
}
static int
+parse_mode_param_arg(const char *key __rte_unused,
+ const char *value, void *extra_args)
+{
+ struct scheduler_init_params *param = extra_args;
+
+ strlcpy(param->mode_param_str, value,
+ RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN);
+
+ return 0;
+}
+
+static int
parse_ordering_arg(const char *key __rte_unused,
const char *value, void *extra_args)
{
@@ -438,6 +455,11 @@ scheduler_parse_init_params(struct scheduler_init_params *params,
if (ret < 0)
goto free_kvlist;
+ ret = rte_kvargs_process(kvlist, RTE_CRYPTODEV_VDEV_MODE_PARAM,
+ &parse_mode_param_arg, params);
+ if (ret < 0)
+ goto free_kvlist;
+
ret = rte_kvargs_process(kvlist, RTE_CRYPTODEV_VDEV_ORDERING,
&parse_ordering_arg, params);
if (ret < 0)
--
2.13.6
^ permalink raw reply related
* [PATCH v2 0/2] crypto/scheduler: add mode specific parameter support
From: Fan Zhang @ 2018-07-23 13:17 UTC (permalink / raw)
To: dev; +Cc: pablo.de.lara.guarch
In-Reply-To: <20180622120847.72376-1-roy.fan.zhang@intel.com>
This patch adds scheduler PMD mode specific parameter support. The
packet-size-distr mode now support custom threshold during initialization.
v2:
- Rebased to master (thanks to Pablo)
- Fixed documentation
Fan Zhang (2):
crypto/scheduler: add mode param parsing
crypto/scheduler: add packet-size-distr mode param parse
doc/guides/cryptodevs/scheduler.rst | 12 +++-
drivers/crypto/scheduler/rte_cryptodev_scheduler.h | 1 +
drivers/crypto/scheduler/scheduler_pmd.c | 75 ++++++++++++++++++++++
3 files changed, 87 insertions(+), 1 deletion(-)
--
2.13.6
^ permalink raw reply
* Re: [Qemu-arm] [Qemu-devel] [RFC PATCH 4/6] hw/arm/virt-acpi-build: distinguish possible and present cpus
From: Igor Mammedov @ 2018-07-23 13:28 UTC (permalink / raw)
To: Andrew Jones; +Cc: peter.maydell, qemu-arm, qemu-devel, eric.auger
In-Reply-To: <20180704124923.32483-5-drjones@redhat.com>
On Wed, 4 Jul 2018 14:49:21 +0200
Andrew Jones <drjones@redhat.com> wrote:
> When building ACPI tables regarding CPUs we should always build
> them for the number of possible CPUs, not the number of present
> CPUs. We then ensure only the present CPUs are enabled.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> hw/arm/virt-acpi-build.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 6ea47e258832..1d1fc824da6f 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -49,14 +49,22 @@
> #define ARM_SPI_BASE 32
> #define ACPI_POWER_BUTTON_DEVICE "PWRB"
>
> -static void acpi_dsdt_add_cpus(Aml *scope, int smp_cpus)
> +static int possible_cpus(VirtMachineState *vms)
> +{
> + return MACHINE_GET_CLASS(vms)->possible_cpu_arch_ids(MACHINE(vms))->len;
> +}
> +
> +static void acpi_dsdt_add_cpus(Aml *scope, int possible, int present)
> {
> uint16_t i;
>
> - for (i = 0; i < smp_cpus; i++) {
> + for (i = 0; i < possible; i++) {
> Aml *dev = aml_device("C%.03X", i);
> aml_append(dev, aml_name_decl("_HID", aml_string("ACPI0007")));
> aml_append(dev, aml_name_decl("_UID", aml_int(i)));
> + if (i >= present) {
acpi_dsdt_add_cpus(Aml *scope, const CPUArchIdList *possible_cpus = mc->possible_cpu_arch_ids(machine)) {
for (i = 0; i < possible_cpus->len; i++) {
...
if (possible_cpus->cpus[i].cpu == NULL)
aml_append(dev, aml_name_decl("_STA", aml_int(0)));
}
}
would be better to be consistent with x86 variant (well I prefer using a single source for CPU enumeration whenever possible) and drop helper above.
> + aml_append(dev, aml_name_decl("_STA", aml_int(0)));
> + }
> aml_append(scope, dev);
> }
> }
> @@ -650,7 +658,7 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> gicd->base_address = cpu_to_le64(memmap[VIRT_GIC_DIST].base);
> gicd->version = vms->gic_version;
>
> - for (i = 0; i < vms->smp_cpus; i++) {
> + for (i = 0; i < possible_cpus(vms); i++) {
ditto
> AcpiMadtGenericCpuInterface *gicc = acpi_data_push(table_data,
> sizeof(*gicc));
> ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(i));
> @@ -663,7 +671,9 @@ build_madt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> gicc->cpu_interface_number = cpu_to_le32(i);
> gicc->arm_mpidr = cpu_to_le64(armcpu->mp_affinity);
> gicc->uid = cpu_to_le32(i);
> - gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED);
> + if (i < vms->smp_cpus) {
> + gicc->flags = cpu_to_le32(ACPI_MADT_GICC_ENABLED);
> + }
>
> if (arm_feature(&armcpu->env, ARM_FEATURE_PMU)) {
> gicc->performance_interrupt = cpu_to_le32(PPI(VIRTUAL_PMU_IRQ));
> @@ -763,7 +773,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> * the RTC ACPI device at all when using UEFI.
> */
> scope = aml_scope("\\_SB");
> - acpi_dsdt_add_cpus(scope, vms->smp_cpus);
> + acpi_dsdt_add_cpus(scope, possible_cpus(vms), vms->smp_cpus);
> acpi_dsdt_add_uart(scope, &memmap[VIRT_UART],
> (irqmap[VIRT_UART] + ARM_SPI_BASE));
> acpi_dsdt_add_flash(scope, &memmap[VIRT_FLASH]);
^ 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.