XENPV guests enter already on the task stack and they can't fault for
native_iret() nor native_load_gs_index() since they use their own pvop
for IRET and load_gs_index(). A CR3 switch is not needed either.
So there is no reason to call error_entry() in XENPV.
[ bp: Massage commit message. ]
Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220503032107.680190-6-jiangshanlai@gmail.com
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
The macro idtentry() (through idtentry_body()) calls error_entry()
unconditionally even on XENPV. But XENPV needs to only push and clear
regs.
PUSH_AND_CLEAR_REGS in error_entry() makes the stack not return to its
original place when the function returns, which means it is not possible
to convert it to a C function.
Carve out PUSH_AND_CLEAR_REGS out of error_entry() and into a separate
function and call it before error_entry() in order to avoid calling
error_entry() on XENPV.
It will also allow for error_entry() to be converted to C code that can
use inlined sync_regs() and save a function call.
[ bp: Massage commit message. ]
Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220503032107.680190-4-jiangshanlai@gmail.com
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
error_entry() calls fixup_bad_iret() before sync_regs() if it is a fault
from a bad IRET, to copy pt_regs to the kernel stack. It switches to the
kernel stack directly after sync_regs().
But error_entry() itself is also a function call, so it has to stash
the address it is going to return to, in %r12 which is unnecessarily
complicated.
Move the stack switching after error_entry() and get rid of the need to
handle the return address.
Always stash the address error_entry() is going to return to, in %r12
and get rid of the void *error_entry_ret; slot in struct bad_iret_stack
which was supposed to account for it and pt_regs pushed on the stack.
After this, both fixup_bad_iret() and sync_regs() can work on a struct
pt_regs pointer directly.
x86, kvm: use proper ASM macros for kvm_vcpu_is_preempted
The build rightfully complains about:
arch/x86/kernel/kvm.o: warning: objtool: __raw_callee_save___kvm_vcpu_is_preempted()+0x12: missing int3 after ret
because the ASM_RET call is not being used correctly in kvm_vcpu_is_preempted().
This was hand-fixed-up in the kvm merge commit a4cfff3f0f8c ("Merge branch
'kvm-older-features' into HEAD") which of course can not be backported to
stable kernels, so just fix this up directly instead.
Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit edbaf6e5e93acda96aae23ba134ef3c1466da3b5 linux-5.15.y)
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Peter Zijlstra [Thu, 24 Jun 2021 09:41:01 +0000 (11:41 +0200)]
objtool: Introduce CFI hash
Andi reported that objtool on vmlinux.o consumes more memory than his
system has, leading to horrific performance.
This is in part because we keep a struct instruction for every
instruction in the file in-memory. Shrink struct instruction by
removing the CFI state (which includes full register state) from it
and demand allocating it.
Given most instructions don't actually change CFI state, there's lots
of repetition there, so add a hash table to find previous CFI
instances.
Reduces memory consumption (and runtime) for processing an
x86_64-allyesconfig:
pre: 4:40.84 real, 143.99 user, 44.18 sys, 30624988 mem
post: 2:14.61 real, 108.58 user, 25.04 sys, 16396184 mem
Nathan reported objtool failing with the following messages:
warning: objtool: no non-local symbols !?
warning: objtool: gelf_update_symshndx: invalid section index
The problem is due to commit 4abff6d48dbc ("objtool: Fix code relocs
vs weak symbols") failing to consider the case where an object would
have no non-local symbols.
The problem that commit tries to address is adding a STB_LOCAL symbol
to the symbol table in light of the ELF spec's requirement that:
In each symbol table, all symbols with STB_LOCAL binding preced the
weak and global symbols. As ``Sections'' above describes, a symbol
table section's sh_info section header member holds the symbol table
index for the first non-local symbol.
The approach taken is to find this first non-local symbol, move that
to the end and then re-use the freed spot to insert a new local symbol
and increment sh_info.
Except it never considered the case of object files without global
symbols and got a whole bunch of details wrong -- so many in fact that
it is a wonder it ever worked :/
Specifically:
- It failed to re-hash the symbol on the new index, so a subsequent
find_symbol_by_index() would not find it at the new location and a
query for the old location would now return a non-deterministic
choice between the old and new symbol.
- It failed to appreciate that the GElf wrappers are not a valid disk
format (it works because GElf is basically Elf64 and we only
support x86_64 atm.)
- It failed to fully appreciate how horrible the libelf API really is
and got the gelf_update_symshndx() call pretty much completely
wrong; with the direct consequence that if inserting a second
STB_LOCAL symbol would require moving the same STB_GLOBAL symbol
again it would completely come unstuck.
Write a new elf_update_symbol() function that wraps all the magic
required to update or create a new symbol at a given index.
Specifically, gelf_update_sym*() require an @ndx argument that is
relative to the @data argument; this means you have to manually
iterate the section data descriptor list and update @ndx.
Commit c087c6e7b551 ("objtool: Fix type of reloc::addend") failed to
appreciate cross building from ILP32 hosts, where 'int' == 'long' and
the issue persists.
As such, use s64/int64_t/Elf64_Sxword for this field and suffer the
pain that is ISO C99 printf formats for it.
Fixes: c087c6e7b551 ("objtool: Fix type of reloc::addend") Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
[peterz: reword changelog, s/long long/s64/] Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/alpine.LRH.2.02.2205161041260.11556@file01.intranet.prod.int.rdu2.redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Since not all compilers have a function attribute to disable KCOV
instrumentation, objtool can rewrite KCOV instrumentation in noinstr
functions as per commit:
In that when a tail-call instrucion is replaced with a RET an
additional INT3 instruction is also written, but is not represented in
the decoded instruction stream.
This then leads to false positive missing INT3 objtool warnings in
noinstr code.
Instead of adding additional struct instruction objects, mark the RET
instruction with retpoline_safe to suppress the warning (since we know
there really is an INT3).
Fixes: 1cc1e4c8aab4 ("objtool: Add straight-line-speculation validation") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20220323230712.GA8939@worktop.programming.kicks-ass.net Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Due to being a perl generated asm file, it got missed by the mass
convertion script.
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_init_x86_64()+0x3a: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_x86_64()+0xf2: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_emit_x86_64()+0x37: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: __poly1305_block()+0x6d: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: __poly1305_init_avx()+0x1e8: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_avx()+0x18a: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_avx()+0xaf8: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_emit_avx()+0x99: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_avx2()+0x18a: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_avx2()+0x776: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_avx512()+0x18a: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_avx512()+0x796: missing int3 after ret
arch/x86/crypto/poly1305-x86_64-cryptogams.o: warning: objtool: poly1305_blocks_avx512()+0x10bd: missing int3 after ret
Fixes: f94909ceb1ed ("x86: Prepare asm files for straight-line-speculation") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
The commit in Fixes started adding INT3 after RETs as a mitigation
against straight-line speculation.
The fastop SETcc implementation in kvm's insn emulator uses macro magic
to generate all possible SETcc functions and to jump to them when
emulating the respective instruction.
However, it hardcodes the size and alignment of those functions to 4: a
three-byte SETcc insn and a single-byte RET. BUT, with SLS, there's an
INT3 that gets slapped after the RET, which brings the whole scheme out
of alignment:
15: 0f 90 c0 seto %al
18: c3 ret
19: cc int3
1a: 0f 1f 00 nopl (%rax)
1d: 0f 91 c0 setno %al
20: c3 ret
21: cc int3
22: 0f 1f 00 nopl (%rax)
25: 0f 92 c0 setb %al
28: c3 ret
29: cc int3
Raise the alignment value when SLS is enabled and use a macro for that
instead of hard-coding naked numbers.
Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation") Reported-by: Jamie Heilman <jamie@audible.transient.net> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Jamie Heilman <jamie@audible.transient.net> Link: https://lore.kernel.org/r/YjGzJwjrvxg5YZ0Z@audible.transient.net
[Add a comment and a bit of safety checking, since this is going to be changed
again for IBT support. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Commit b1a1a1a09b46 ("kbuild: lto: postpone objtool") moved objtool_args
to Makefile.lib, so the arguments can be used in Makefile.modfinal as
well as Makefile.build.
With commit 850ded46c642 ("kbuild: Fix TRIM_UNUSED_KSYMS with
LTO_CLANG"), module LTO linking came back to scripts/Makefile.build
again.
So, there is no more reason to keep objtool_args in a separate file.
Get it back to the original place, close to the objtool command.
Currently, text_poke_bp() is very strict to only allow patching a
single instruction; however with straight-line-speculation it will be
required to patch: ret; int3, which is two instructions.
As such, relax the constraints a little to allow int3 padding for all
instructions that do not imply the execution of the next instruction,
ie: RET, JMP.d8 and JMP.d32.
While there, rename the text_poke_loc::rel32 field to ::disp.
Note: this fills up the text_poke_loc structure which is now a round
16 bytes big.
[ bp: Put comments ontop instead of on the side. ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/20211204134908.082342723@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-29900
CVE-2022-29901 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
"qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following
message was found:
block nbd0: Send disconnect failed -32
Which indicate that something is wrong with the server. Then,
"qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear
requests after commit 2516ab1543fd("nbd: only clear the queue on device
teardown"). And in the meantime, request can't complete through timeout
because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which
means such request will never be completed in this situation.
Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't
complete multiple times, switch back to call nbd_clear_sock() in
nbd_clear_sock_ioctl(), so that inflight requests can be cleared.
Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20220521073749.3146892-5-yukuai3@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 09dadb5985023e27d4740ebd17e6fea4640110e5) Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Yu Kuai [Wed, 22 Jun 2022 05:17:00 +0000 (07:17 +0200)]
nbd: make sure request completion won't concurrent
BugLink: https://bugs.launchpad.net/bugs/1896350
commit cddce0116058 ("nbd: Aovid double completion of a request")
try to fix that nbd_clear_que() and recv_work() can complete a
request concurrently. However, the problem still exists:
t1 t2 t3
nbd_disconnect_and_put
flush_workqueue
recv_work
blk_mq_complete_request
blk_mq_complete_request_remote -> this is true
WRITE_ONCE(rq->state, MQ_RQ_COMPLETE)
blk_mq_raise_softirq
blk_done_softirq
blk_complete_reqs
nbd_complete_rq
blk_mq_end_request
blk_mq_free_request
WRITE_ONCE(rq->state, MQ_RQ_IDLE)
nbd_clear_que
blk_mq_tagset_busy_iter
nbd_clear_req
__blk_mq_free_request
blk_mq_put_tag
blk_mq_complete_request -> complete again
There are three places where request can be completed in nbd:
recv_work(), nbd_clear_que() and nbd_xmit_timeout(). Since they
all hold cmd->lock before completing the request, it's easy to
avoid the problem by setting and checking a cmd flag.
Signed-off-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20210916093350.1410403-3-yukuai3@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from 07175cb1baf4c51051b1fbd391097e349f9a02a9) Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Yu Kuai [Wed, 22 Jun 2022 05:17:00 +0000 (07:17 +0200)]
nbd: don't handle response without a corresponding request message
BugLink: https://bugs.launchpad.net/bugs/1896350
While handling a response message from server, nbd_read_stat() will
try to get request by tag, and then complete the request. However,
this is problematic if nbd haven't sent a corresponding request
message:
BugLink: https://bugs.launchpad.net/bugs/1965241
PCIE_EDR is enabling support to handle events generated when a PCIE port
disconnects to handle errors. From the comments given in the commit which
adds this option and its help, it sounds like if the OS enables DPC (down-
stream port control) which allows to control PCIE ports in parallel to the
firmware, it should also enable EDR.
Signed-off-by: Michael Reed <Michael.Reed@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com>
[Added annotation enforcement and bug reference, and adjust annotation
to force arm64 to the same setting as it was before] Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Lukas Wunner [Tue, 17 May 2022 21:08:00 +0000 (23:08 +0200)]
PCI: pciehp: Ignore Link Down/Up caused by error-induced Hot Reset
Stuart Hayes reports that an error handled by DPC at a Root Port results
in pciehp gratuitously bringing down a subordinate hotplug port:
RP -- UP -- DP -- UP -- DP (hotplug) -- EP
pciehp brings the slot down because the Link to the Endpoint goes down.
That is caused by a Hot Reset being propagated as a result of DPC.
Per PCIe Base Spec 5.0, section 6.6.1 "Conventional Reset":
For a Switch, the following must cause a hot reset to be sent on all
Downstream Ports: [...]
* The Data Link Layer of the Upstream Port reporting DL_Down status.
In Switches that support Link speeds greater than 5.0 GT/s, the
Upstream Port must direct the LTSSM of each Downstream Port to the
Hot Reset state, but not hold the LTSSMs in that state. This permits
each Downstream Port to begin Link training immediately after its
hot reset completes. This behavior is recommended for all Switches.
* Receiving a hot reset on the Upstream Port.
Once DPC recovers, pcie_do_recovery() walks down the hierarchy and
invokes pcie_portdrv_slot_reset() to restore each port's config space.
At that point, a hotplug interrupt is signaled per PCIe Base Spec r5.0,
section 6.7.3.4 "Software Notification of Hot-Plug Events":
If the Port is enabled for edge-triggered interrupt signaling using
MSI or MSI-X, an interrupt message must be sent every time the logical
AND of the following conditions transitions from FALSE to TRUE: [...]
* The Hot-Plug Interrupt Enable bit in the Slot Control register is
set to 1b.
* At least one hot-plug event status bit in the Slot Status register
and its associated enable bit in the Slot Control register are both
set to 1b.
Prevent pciehp from gratuitously bringing down the slot by clearing the
error-induced Data Link Layer State Changed event before restoring
config space. Afterwards, check whether the link has unexpectedly
failed to retrain and synthesize a DLLSC event if so.
Allow each pcie_port_service_driver (one of them being pciehp) to define
a slot_reset callback and re-use the existing pm_iter() function to
iterate over the callbacks.
Thereby, the Endpoint driver remains bound throughout error recovery and
may restore the device to working state.
Surprise removal during error recovery is detected through a Presence
Detect Changed event. The hotplug port is expected to not signal that
event as a result of a Hot Reset.
The issue isn't DPC-specific, it also occurs when an error is handled by
AER through aer_root_reset(). So while the issue was noticed only now,
it's been around since 2006 when AER support was first introduced.
BugLink: https://bugs.launchpad.net/bugs/1965241
[bhelgaas: drop PCI_ERROR_RECOVERY Kconfig, split pm_iter() rename to
preparatory patch] Link: https://lore.kernel.org/linux-pci/08c046b0-c9f2-3489-eeef-7e7aca435bb9@gmail.com/ Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver") Link: https://lore.kernel.org/r/251f4edcc04c14f873ff1c967bc686169cd07d2d.1627638184.git.lukas@wunner.de Reported-by: Stuart Hayes <stuart.w.hayes@gmail.com> Tested-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v2.6.19+: ba952824e6c1: PCI/portdrv: Report reset for frozen channel Cc: Keith Busch <kbusch@kernel.org>
(cherry picked from commit ea401499e943c307e6d44af6c2b4e068643e7884) Signed-off-by: Michael Reed <Michael.Reed@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Martin Belanger [Tue, 21 Jun 2022 21:53:00 +0000 (23:53 +0200)]
nvme: expose cntrltype and dctype through sysfs
TP8010 introduces the Discovery Controller Type attribute (dctype).
The dctype is returned in the response to the Identify command. This
patch exposes the dctype through the sysfs. Since the dctype depends on
the Controller Type (cntrltype), another attribute of the Identify
response, the patch also exposes the cntrltype as well. The dctype will
only be displayed for discovery controllers.
A note about the naming of this attribute:
Although TP8010 calls this attribute the Discovery Controller Type,
note that the dctype is now part of the response to the Identify
command for all controller types. I/O, Discovery, and Admin controllers
all share the same Identify response PDU structure. Non-discovery
controllers as well as pre-TP8010 discovery controllers will continue
to set this field to 0 (which has always been the default for reserved
bytes). Per TP8010, the value 0 now means "Discovery controller type is
not reported" instead of "Reserved". One could argue that this
definition is correct even for non-discovery controllers, and by
extension, exposing it in the sysfs for non-discovery controllers is
appropriate.
BugLink: https://bugs.launchpad.net/bugs/1948626 Signed-off-by: Martin Belanger <martin.belanger@dell.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: John Meneghini <jmeneghi@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
(cherry picked from commit 86c2457a8e8112f16af8fd10a3e1dd7a302c3c3e) Signed-off-by: Michael Reed <Michael.Reed@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Martin Belanger [Tue, 21 Jun 2022 21:53:00 +0000 (23:53 +0200)]
nvme: send uevent on connection up
When connectivity with a controller is lost, the driver will keep
trying to reconnect once every 10 sec. When connection is restored,
user-space apps need to be informed so that they can take proper
action. For example, TP8010 introduces the DIM PDU, which is used to
register with a discovery controller (DC). The DIM PDU is sent from
user-space. The DIM PDU must be sent every time a connection is
established with a DC. Therefore, the kernel must tell user-space apps
when connection is restored so that registration can happen.
The uevent sent is a "change" uevent with environmental data
set to: "NVME_EVENT=connected".
BugLink: https://bugs.launchpad.net/bugs/1948626 Signed-off-by: Martin Belanger <martin.belanger@dell.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: John Meneghini <jmeneghi@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
(cherry picked from commit 20d64911e7580f7e29c0086d67860c18307377d7) Signed-off-by: Michael Reed <Michael.Reed@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
s390/cio: derive cdev information only for IO-subchannels
BugLink: https://bugs.launchpad.net/bugs/1980951
cdev->online for the purge function must not be checked for the
non-IO subchannel type. Make sure that we are deriving the cdev only
from sch-type SUBCHANNEL_TYPE_IO.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit 0c3812c347bfb0dc213556a195e79850c55702f5) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1978820
The cited commit changed promisc table to be created on demand with the
highest priority in the NIC table replacing the vlan table, this caused
tc NIC tables miss flow to skip the prmoisc table because it use vlan
table as miss table.
OVS offload in NIC mode use promisc by default so any unicast packet
which will be handled by tc NIC tables miss flow will skip the promisc
rule and will be dropped.
Fix this by adding new empty table in new tc level with low priority and
point the nic tc chain miss to it, the new table is managed so it will
point to vlan table if promisc is disabled and to promisc table if enabled.
Fixes: 1c46d7409f30 ("net/mlx5e: Optimize promiscuous mode") Signed-off-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Paul Blakey <paulb@nvidia.com> Reviewed-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
(cherry picked from commit 66cb64e292d21588bdb831f08a7ec0ff04d6380d master) Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
After the first ct() action the packet headers are almost fully
re-written. The next ct() tries to re-use the existing nfct entry
and marks the packet as invalid, so it gets dropped later in the
pipeline.
Clearing the cached conntrack entry whenever packet tuple is changed
to avoid the issue.
The flow key should not be cleared though, because we should still
be able to match on the ct_state if the recirculation happens after
the tuple change but before the next ct() action.
ASoC: amd: Add support for enabling DMIC on acp6x via _DSD
BugLink: https://bugs.launchpad.net/bugs/1980700
Currently the acp6x machine driver requires a hardcoded list of systems
that physically have DMIC connected.
To avoid having to continually add to an evergrowing list of systems add
support for a _DSD that can advertise this.
OEMs can add this _DSD to their BIOS under the ACP device to automatically
add the device to this driver without requiring any driver modifications.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411134532.13538-3-mario.limonciello@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 5426f506b58424f8ab2cd741bacf4b18b5fe578e) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
ASoC: amd: Add driver data to acp6x machine driver
BugLink: https://bugs.launchpad.net/bugs/1980700
Currently all of the quirked systems use the same card and so the
DMI quirk list doesn't contain driver data.
Add driver data to these quirks and then check the data was present
or not. This will allow potentially setting quirks for systems with
faulty firmware that claims to have a DMIC but doesn't really.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20220411134532.13538-2-mario.limonciello@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit e521f087780d07731e8c950f2f34d08358c86bc9) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Fixes: fc329c1de498 ("ASoC: amd: add platform devices for acp6x pdm driver and dmic driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20211130125633.GA24941@kili Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit d5c137f41352e8dd864522c417b45d8d1aebca68) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-14-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit a80d7edadfa16fa1d4aca4a2253a0af921c3aaef) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-13-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit fa991481b8b22a7797a828135ce62a73791bbe39) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-12-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 058dfdf37f25580423fd21d4b78d2daf217d0cf5) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Vijendar Mukunda [Mon, 18 Oct 2021 11:20:41 +0000 (16:50 +0530)]
ASoC: amd: enable Yellow carp acp6x drivers build
BugLink: https://bugs.launchpad.net/bugs/1949245
Yellow Carp ACP6x drivers can be built by selecting necessary
kernel config option.
The patch enables build support of the same.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-10-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 4c2e711af2193bc58f247f32edc30ee6a15e71f2) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-9-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit c8212df7bc0f2ed323ad1da96106792103ee94f1) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-8-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit ceb4fcc13ae58102ad31aa4071d9e57e57eea3df) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Vijendar Mukunda [Mon, 18 Oct 2021 11:20:37 +0000 (16:50 +0530)]
ASoC: amd: add acp6x irq handler
BugLink: https://bugs.launchpad.net/bugs/1949245
Add ACP6x irq handler for handling irq events for ACP IP.
Add pdm irq events handling.
Whenever audio data equal to the PDM watermark level are consumed,
interrupt is generated. Acknowledge the interrupt.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-7-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit cc0deaa2dc7300bb33e44e52cde0b6947a5d3a5d) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Vijendar Mukunda [Mon, 18 Oct 2021 11:20:36 +0000 (16:50 +0530)]
ASoC: amd: add acp6x pdm platform driver
BugLink: https://bugs.launchpad.net/bugs/1949245
PDM platform driver binds to the platform device created by
ACP6x PCI device. PDM driver registers ALSA DMA and CPU DAI
components with ASoC framework.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-6-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 7610174a5bfe6cf34eda8f972311e629ae6dc2d1) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Vijendar Mukunda [Mon, 18 Oct 2021 11:20:35 +0000 (16:50 +0530)]
ASoC: amd: add platform devices for acp6x pdm driver and dmic driver
BugLink: https://bugs.launchpad.net/bugs/1949245
ACP6.x IP has PDM decoder block.
Create a platform device for it, so that the PDM platform driver
can be bound to this device.
Pass PCI resources like MMIO to this platform device.
Create a platform device for generic dmic codec driver.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-5-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit fc329c1de49825a30d5381e18316a3fd45aac7a9) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-4-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 8c7161f2c97b2dba018ecf0af8a0553e283a5c3e) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit c62442bd5d9f86575d74c77b891ef0df9e3cb6dd) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com> Link: https://lore.kernel.org/r/20211018112044.1705805-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 53880e382bb1323897f43f16f4b1b98ac5044871) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Claudio Imbrenda [Tue, 21 Jun 2022 19:36:00 +0000 (21:36 +0200)]
KVM: s390: pv: avoid stalls when making pages secure
BugLink: https://bugs.launchpad.net/bugs/1979296
Improve make_secure_pte to avoid stalls when the system is heavily
overcommitted. This was especially problematic in kvm_s390_pv_unpack,
because of the loop over all pages that needed unpacking.
Due to the locks being held, it was not possible to simply replace
uv_call with uv_call_sched. A more complex approach was
needed, in which uv_call is replaced with __uv_call, which does not
loop. When the UVC needs to be executed again, -EAGAIN is returned, and
the caller (or its caller) will try again.
When -EAGAIN is returned, the path is the same as when the page is in
writeback (and the writeback check is also performed, which is
harmless).
Fixes: 214d9bbcd3a672 ("s390/mm: provide memory management functions for protected KVM guests") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Link: https://lore.kernel.org/r/20210920132502.36111-5-imbrenda@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
(cherry picked from commit f0a1a0615a6ff6d38af2c65a522698fb4bb85df6) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Frank Heimes [Tue, 21 Jun 2022 10:36:00 +0000 (12:36 +0200)]
UBUNTU: [Config] CONFIG_S390_UV_UAPI=y for s390x
BugLink: https://bugs.launchpad.net/bugs/1959973
With commit "drivers/s390/char: Add Ultravisor io device"
a new misc character device to expose some Ultravisor
functions to userspace is added which provides attestations support.
This commit activated the corresponding kernel config option.
Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Steffen Eiden [Tue, 21 Jun 2022 10:36:00 +0000 (12:36 +0200)]
drivers/s390/char: Add Ultravisor io device
BugLink: https://bugs.launchpad.net/bugs/1959973
This patch adds a new miscdevice to expose some Ultravisor functions
to userspace. Userspace can send IOCTLs to the uvdevice that will then
emit a corresponding Ultravisor Call and hands the result over to
userspace. The uvdevice is available if the Ultravisor Call facility is
present.
Userspace can call the Retrieve Attestation Measurement
Ultravisor Call using IOCTLs on the uvdevice.
The uvdevice will do some sanity checks first.
Then, copy the request data to kernel space, build the UVCB,
perform the UV call, and copy the result back to userspace.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/kvm/20220516113335.338212-1-seiden@linux.ibm.com/
Message-Id: <20220516113335.338212-1-seiden@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> (whitespace and tristate fixes, pick)
(cherry picked from commit 4689752c79fa30e91b49b39a9fba93c4d1f3e20c linux-next) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
In order to not add fancy protection for drv_priv we can move
htc_handle->drv_priv initialization at the end of the
ath9k_htc_probe_device() and add helper macro to make
all *_STAT_* macros NULL safe, since syzbot has reported related NULL
deref in that macros [1]
If there is still a closed socket associated with the transport, then we
need to trigger an autoclose before we can set up a new connection.
Reported-by: wanghai (M) <wanghai38@huawei.com> Fixes: f00432063db1 ("SUNRPC: Ensure we flush any closed sockets before xs_xprt_free()") Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
CVE-2022-28893
(backported from commit aad41a7d7cf6c6fa804c872a2480f8e541da37cf)
[cengizcan: we don't have commit c4f0396688b5 which fixes the indent
issue so change context] Signed-off-by: Cengiz Can <cengiz.can@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
We must ensure that all sockets are closed before we call xprt_free()
and release the reference to the net namespace. The problem is that
calling fput() will defer closing the socket until delayed_fput() gets
called.
Let's fix the situation by allowing rpciod and the transport teardown
code (which runs on the system wq) to call __fput_sync(), and directly
close the socket.
Reported-by: Felix Fu <foyjog@gmail.com> Acked-by: Al Viro <viro@zeniv.linux.org.uk> Fixes: a73881c96d73 ("SUNRPC: Fix an Oops in udp_poll()") Cc: stable@vger.kernel.org # 5.1.x: 3be232f11a3c: SUNRPC: Prevent immediate close+reconnect Cc: stable@vger.kernel.org # 5.1.x: 89f42494f92f: SUNRPC: Don't call connect() more than once on a TCP socket Cc: stable@vger.kernel.org # 5.1.x Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> Cc: Meena Shanmugam <meenashanmugam@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2022-28893
(backported from commit 54f6834b283d9b4d070b0639d9ef5e1d156fe7b0 linux-5.15.y)
[cengizcan: we already have __fput_sync exported as GPL only so do not
EXPORT_SYMBOL it again] Signed-off-by: Cengiz Can <cengiz.can@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Willy Tarreau [Fri, 24 Jun 2022 20:34:47 +0000 (17:34 -0300)]
floppy: use a statically allocated error counter
Interrupt handler bad_flp_intr() may cause a UAF on the recently freed
request just to increment the error count. There's no point keeping
that one in the request anyway, and since the interrupt handler uses a
static pointer to the error which cannot be kept in sync with the
pending request, better make it use a static error counter that's reset
for each new request. This reset now happens when entering
redo_fd_request() for a new request via set_next_request().
One initial concern about a single error counter was that errors on one
floppy drive could be reported on another one, but this problem is not
real given that the driver uses a single drive at a time, as that
PC-compatible controllers also have this limitation by using shared
signals. As such the error count is always for the "current" drive.
Reported-by: Minh Yuan <yuanmingbuaa@gmail.com> Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org> Tested-by: Denis Efremov <efremov@linux.com> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit f71f01394f742fc4558b3f9f4c7ef4c4cf3b07c8)
CVE-2022-1652 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Zachary Tahenakos <zachary.tahenakos@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com>
The commit 2565e5b69c44 was added as a workaround to keep MSI-X
remapping enabled if IOMMU enables interrupt remapping. VMD would keep
running in low performance mode. There is no dependency between MSI-X
remapping by VMD and interrupt remapping by IOMMU.
Link: https://lore.kernel.org/r/20220511095707.25403-3-nirmal.patel@linux.intel.com Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
(cherry picked from commit c94f732e8001a860b42aa740b0a178a29907463c) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Nirmal Patel [Wed, 11 May 2022 09:57:06 +0000 (02:57 -0700)]
PCI: vmd: Assign VMD IRQ domain before enumeration
BugLink: https://bugs.launchpad.net/bugs/1976587
During the boot process all the PCI devices are assigned default PCI-MSI
IRQ domain including VMD endpoint devices. If interrupt-remapping is
enabled by IOMMU, the PCI devices except VMD get new INTEL-IR-MSI IRQ
domain. And VMD is supposed to create and assign a separate VMD-MSI IRQ
domain for its child devices in order to support MSI-X remapping
capabilities.
Now when MSI-X remapping in VMD is disabled in order to improve
performance, VMD skips VMD-MSI IRQ domain assignment process to its
child devices. Thus the devices behind VMD get default PCI-MSI IRQ
domain instead of INTEL-IR-MSI IRQ domain when VMD creates root bus and
configures child devices.
As a result host OS fails to boot and DMAR errors were observed when
interrupt remapping was enabled on Intel Icelake CPUs. For instance:
DMAR: DRHD: handling fault status reg 2
DMAR: [INTR-REMAP] Request device [0xe2:0x00.0] fault index 0xa00 [fault reason 0x25] Blocked a compatibility format interrupt request
To fix this issue, dev_msi_info struct in dev struct maintains correct
value of IRQ domain. VMD will use this information to assign proper IRQ
domain to its child devices when it doesn't create a separate IRQ domain.
Link: https://lore.kernel.org/r/20220511095707.25403-2-nirmal.patel@linux.intel.com Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
(cherry picked from commit 886e67100b904cb1b106ed1dfa8a60696aff519a) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Avraham Stern [Fri, 10 Jun 2022 09:01:02 +0000 (17:01 +0800)]
mac80211: fix struct ieee80211_tx_info size
BugLink: https://bugs.launchpad.net/bugs/1978297
The size of the status_driver_data field was not adjusted when
the is_valid_ack_signal field was added.
Since the size of struct ieee80211_tx_info is limited, replace
the is_valid_ack_signal field with a flags field, and adjust the
struct size accordingly.
drm/amd/display: Don't reinitialize DMCUB on s0ix resume
BugLink: https://bugs.launchpad.net/bugs/1978244
[Why]
PSP will suspend and resume DMCUB. Driver should just wait for DMCUB to
finish the auto load before continuining instead of placing it into
reset, wiping its firmware state and reinitializing.
If we don't let DMCUB fully finish initializing for S0ix then some state
will be lost and screen corruption can occur due to incorrect address
translation.
[How]
Use dmub_srv callbacks to determine in DMCUB is running and wait for
auto-load to complete before continuining.
In S0ix DMCUB will be running and DAL fw so initialize will skip.
In S3 DMCUB will not be running and we will do a full hardware init.
In S3 DMCUB will be running but will not be DAL fw so we will also do
a full hardware init.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Mikita Lipski <Mikita.Lipski@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 79d6b9351f086e0f914a26915d96ab52286ec46c) Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
With the broken test case, "underlay in a VRF", fixed in the
test_vxlan_under_vrf.sh, we should remove the SAUCE patches that mark
this test failure as an expected failure to catch regressions in the
future. This could reduce maintenance cost as well.
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com>
With the broken test case, "underlay in a VRF", fixed in the
test_vxlan_under_vrf.sh, we should remove the SAUCE patches that mark
this test failure as an expected failure to catch regressions in the
future. This could reduce maintenance cost as well.
Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1979051
The purpose of this patch is to introduce a fix to hp_wmi_read_int()
and eliminate failure error (0x05). Several WMI queries leverage
hp_wmi_read_int() to read their data and were failing with error 0x05.
The failure occurs because hp_wmi_read_int() calls
hp_wmi_perform_query() with input parameter of size greater than zero.
Invoking those WMI commands with an input buffer size greater than
zero causes the command to be rejected and error 0x05 be returned.
All changes were validated on a HP ZBook Workstation notebook,
HP EliteBook x360, and HP EliteBook 850 G8.
Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com> Link: https://lore.kernel.org/r/20220310210853.28367-2-jorge.lopez2@hp.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 12b19f14a21a2ee6348825d95b642ef2cd16794f) Signed-off-by: Andy Chi <andy.chi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Update Kconfig file to allow the driver to be built on ARM64 as well.
Fail vmci_guest_probe_device() on ARM64 if the device does not support
MMIO register access. Lastly, add virtualization specific barriers
which map to actual memory barrier instructions on ARM64, because it
is required in case of ARM64 for queuepair (de)queuing.
Reviewed-by: Bryan Tan <bryantan@vmware.com> Reviewed-by: Cyprien Laplace <claplace@vmware.com> Signed-off-by: Vishnu Dasa <vdasa@vmware.com> Link: https://lore.kernel.org/r/20220414193316.14356-1-vdasa@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1f7142915d304804a9bd952245fce92786b1b62f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Vishnu Dasa [Tue, 14 Jun 2022 19:06:16 +0000 (13:06 -0600)]
VMCI: Check exclusive_vectors when freeing interrupt 1
BugLink: https://bugs.launchpad.net/bugs/1978145
free_irq() may be called to free an interrupt that was not
allocated. Add missing 'if' statement to check for
exclusive_vectors when freeing interrupt 1.
Fixes: cc68f2177fcb ("VMCI: dma dg: register dummy IRQ handlers for DMA datagrams") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Bryan Tan <bryantan@vmware.com> Reviewed-by: Rajesh Jalisatgi <rjalisatgi@vmware.com> Signed-off-by: Vishnu Dasa <vdasa@vmware.com> Link: https://lore.kernel.org/r/20220318055843.30606-1-vdasa@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5df0e734b8c39598effe0f17e5bd8ff7748a0693) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Vishnu Dasa [Tue, 14 Jun 2022 19:06:15 +0000 (13:06 -0600)]
VMCI: Release notification_bitmap in error path
BugLink: https://bugs.launchpad.net/bugs/1978145
notification_bitmap may not be released when VMCI_CAPS_DMA_DATAGRAM
capability is missing from the device. Add missing
'err_free_notification_bitmap' label and use it instead of
'err_free_data_buffers' to avoid this.
Fixes: eed2298d9360 ("VMCI: dma dg: detect DMA datagram capability") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Bryan Tan <bryantan@vmware.com> Reviewed-by: Rajesh Jalisatgi <rjalisatgi@vmware.com> Signed-off-by: Vishnu Dasa <vdasa@vmware.com> Link: https://lore.kernel.org/r/20220318060040.31621-1-vdasa@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c8e9b30ccae605bf1dbeaf03971f9b83f70b928d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
VMCI: Fix some error handling paths in vmci_guest_probe_device()
BugLink: https://bugs.launchpad.net/bugs/1978145
The 'err_remove_vmci_dev_g' error label is not at the right place.
This could lead to un-released resource.
There is also a missing label. If pci_alloc_irq_vectors() fails, the
previous vmci_event_subscribe() call must be undone.
Jorgen Hansen [Tue, 14 Jun 2022 19:06:13 +0000 (13:06 -0600)]
VMCI: dma dg: add support for DMA datagrams receive
BugLink: https://bugs.launchpad.net/bugs/1978145
Use the DMA based receive operation instead of the ioread8_rep
based datagram receive when DMA datagrams are supported.
In the receive operation, configure the header to point to the
page aligned VMCI_MAX_DG_SIZE part of the receive buffer
using s/g configuration for the header. This ensures that the
existing dispatch routine can be used with little modification.
Initiate the receive by writing the lower 32 bit of the buffer
to the VMCI_DATA_IN_LOW_ADDR register, and wait for the busy
flag to be changed by the device using a wait queue.
The existing dispatch routine for received datagrams is reused
for the DMA datagrams with a few modifications:
- the receive buffer is always the maximum size for DMA datagrams
(IO ports would try with a shorter buffer first to reduce
overhead of the ioread8_rep operation).
- for DMA datagrams, datagrams are provided contiguous in the
buffer as opposed to IO port datagrams, where they can start
on any page boundary
Reviewed-by: Vishnu Dasa <vdasa@vmware.com> Signed-off-by: Jorgen Hansen <jhansen@vmware.com> Link: https://lore.kernel.org/r/20220207102725.2742-9-jhansen@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 463713eb6164b6577f8e91447c7745628215531b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Jorgen Hansen [Tue, 14 Jun 2022 19:06:12 +0000 (13:06 -0600)]
VMCI: dma dg: add support for DMA datagrams sends
BugLink: https://bugs.launchpad.net/bugs/1978145
Use DMA based send operation from the transmit buffer instead of the
iowrite8_rep based datagram send when DMA datagrams are supported.
The outgoing datagram is sent as inline data in the VMCI transmit
buffer. Once the header has been configured, the send is initiated
by writing the lower 32 bit of the buffer base address to the
VMCI_DATA_OUT_LOW_ADDR register. Only then will the device process
the header and the datagram itself. Following that, the driver busy
waits (it isn't possible to sleep on the send path) for the header
busy flag to change - indicating that the send is complete.
Reviewed-by: Vishnu Dasa <vdasa@vmware.com> Signed-off-by: Jorgen Hansen <jhansen@vmware.com> Link: https://lore.kernel.org/r/20220207102725.2742-8-jhansen@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 22aa5c7f323022477b70e044eb00e6bfea9498e8) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
This is done in preparation for the send and receive datagram
operations, where the buffers are used for the exchange of data
between driver and device.
Reviewed-by: Vishnu Dasa <vdasa@vmware.com> Signed-off-by: Jorgen Hansen <jhansen@vmware.com> Link: https://lore.kernel.org/r/20220207102725.2742-7-jhansen@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5ee109828e73bbe4213c373988608d8f33e03d78) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Jorgen Hansen [Tue, 14 Jun 2022 19:06:07 +0000 (13:06 -0600)]
VMCI: dma dg: add MMIO access to registers
BugLink: https://bugs.launchpad.net/bugs/1978145
Detect the support for MMIO access through examination of the length
of the region requested in BAR1. If it is 256KB, the VMCI device
supports MMIO access to registers.
If MMIO access is supported, map the area of the region used for
MMIO access (64KB size at offset 128KB).
Add wrapper functions for accessing 32 bit register accesses through
either MMIO or IO ports based on device configuration.
Sending and receiving datagrams through iowrite8_rep/ioread8_rep is
left unchanged for now, and will be addressed in a later change.
Reviewed-by: Vishnu Dasa <vdasa@vmware.com> Signed-off-by: Jorgen Hansen <jhansen@vmware.com> Link: https://lore.kernel.org/r/20220207102725.2742-3-jhansen@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e283a0e8b7ea83915e988ed059384af166b444c0) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Jorgen Hansen [Tue, 14 Jun 2022 19:06:06 +0000 (13:06 -0600)]
VMCI: dma dg: whitespace formatting change for vmci register defines
BugLink: https://bugs.launchpad.net/bugs/1978145
Update formatting of existing register defines in preparation for
adding additional register definitions for the VMCI device.
Reviewed-by: Vishnu Dasa <vdasa@vmware.com> Signed-off-by: Jorgen Hansen <jhansen@vmware.com> Link: https://lore.kernel.org/r/20220207102725.2742-2-jhansen@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fac608138c6136126faadafa5554cc0bbabf3c44) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Khaled Elmously <khalid.elmously@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
The switch to a keyed guest does not require a classic sske as the other
guest CPUs are not accessing the key before the switch is complete.
By using the NQ SSKE things are faster especially with multiple guests.
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Suggested-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20220530092706.11637-3-borntraeger@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
(cherry picked from commit 3ae11dbcfac906a8c3a480e98660a823130dc16a) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
s390/gmap: voluntarily schedule during key setting
BugLink: https://bugs.launchpad.net/bugs/1975582
With large and many guest with storage keys it is possible to create
large latencies or stalls during initial key setting:
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 18-....: (2099 ticks this GP) idle=54e/1/0x4000000000000002 softirq=35598716/35598716 fqs=998
(t=2100 jiffies g=155867385 q=20879)
Task dump for CPU 18:
CPU 1/KVM R running task 0 1030947 256019 0x06000004
Call Trace:
sched_show_task
rcu_dump_cpu_stacks
rcu_sched_clock_irq
update_process_times
tick_sched_handle
tick_sched_timer
__hrtimer_run_queues
hrtimer_interrupt
do_IRQ
ext_int_handler
ptep_zap_key
The mmap lock is held during the page walking but since this is a
semaphore scheduling is still possible. Same for the kvm srcu.
To minimize overhead do this on every segment table entry or large page.
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20220530092706.11637-2-borntraeger@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
(cherry picked from commit 6d5946274df1fff539a7eece458a43be733d1db8) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Lee Shawn C [Mon, 30 May 2022 06:01:09 +0000 (14:01 +0800)]
drm/i915: update new TMDS clock setting defined by VBT
BugLink: https://bugs.launchpad.net/bugs/1976214
VBT 249 update to support more TMDS clock rate 3.00G, 3.40G
and 5.94G. Refer to this new definition to configure max
TMDS clock rate for HDMI driver.
BSpec: 20124
v2: new subject
Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303083802.5071-1-shawn.c.lee@intel.com
(backported from commit 5708fe0db0edfaaf6ef83106a4404bc102afe129) Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Kevin Hao [Mon, 30 May 2022 10:59:46 +0000 (11:59 +0100)]
powerpc: Export mmu_feature_keys[] as non-GPL
BugLink: https://bugs.launchpad.net/bugs/1976248
When the mmu_feature_keys[] was introduced in the commit c12e6f24d413
("powerpc: Add option to use jump label for mmu_has_feature()"),
it is unlikely that it would be used either directly or indirectly in
the out of tree modules. So we exported it as GPL only.
But with the evolution of the codes, especially the PPC_KUAP support, it
may be indirectly referenced by some primitive macro or inline functions
such as get_user() or __copy_from_user_inatomic(), this will make it
impossible to build many non GPL modules (such as ZFS) on ppc
architecture. Fix this by exposing the mmu_feature_keys[] to the non-GPL
modules too.
Fixes: 7613f5a66bec ("powerpc/64s/kuap: Use mmu_has_feature()") Reported-by: Nathaniel Filardo <nwfilardo@gmail.com> Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220329085709.4132729-1-haokexin@gmail.com
(backported from commit d9e5c3e9e75162f845880535957b7fd0b4637d23 upstream) Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Update the comment about what happens when link goes down after we have
checked for link-up. If a PIO request is done while link-down, we have
a serious problem.
Link: https://lore.kernel.org/r/20220110015018.26359-23-kabel@kernel.org Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Callback for irq_mask_ack() is the same as for irq_mask(). As there is no
special handling for irq_ack(), there is no need to define irq_mask_ack()
too.
Link: https://lore.kernel.org/r/20220110015018.26359-20-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Emulated root bridge currently provides only one Legacy INTA interrupt
which is used for reporting PCIe PME and ERR events and handled by kernel
PCIe PME and AER drivers.
Aardvark HW reports these PME and ERR events separately, so there is no
need to mix real INTA interrupt and emulated INTA interrupt for PCIe PME
and AER drivers.
Register a new advk-RP (as in Root Port) irq chip and a new irq domain
for emulated root bridge and use this new separate irq domain for
providing INTA interrupt from emulated root bridge for PME and ERR events.
The real INTA interrupt from real devices is now separate.
A custom map_irq callback function on PCI host bridge structure is used to
allocate IRQ mapping for emulated root bridge from new irq domain. Original
callback of_irq_parse_and_map_pci() is used for all other devices as before.
Link: https://lore.kernel.org/r/20220110015018.26359-19-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Enable aardvark PME interrupt unconditionally by unmasking it and read PME
requester ID to emulated bridge config space immediately after receiving
interrupt.
PME requester ID is stored in the PCIE_MSG_LOG_REG register, which contains
the last inbound message. So when new inbound message is received by HW
(including non-PM), the content in PCIE_MSG_LOG_REG register is replaced by
a new value.
PCIe specification mandates that subsequent PMEs are kept pending until the
PME Status Register bit is cleared by software by writing a 1b.
Support for masking/unmasking PME interrupt on emulated bridge via
PCI_EXP_RTCTL_PMEIE bit is now implemented only in emulated bridge config
space, to ensure that we do not miss any aardvark PME interrupt.
Reading of PCI_EXP_RTCAP and PCI_EXP_RTSTA registers is simplified as final
value is now always stored into emulated bridge config space by the
interrupt handler, so there is no need to implement support for these
registers in read_pcie callback.
Clearing of W1C bit PCI_EXP_RTSTA_PME is now also simplified as it is done
by pci-bridge-emul.c code for emulated bridge config space. So there is no
need to implement support for clearing this bit in write_pcie callback.
Link: https://lore.kernel.org/r/20220110015018.26359-18-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Currently enabling PCI_EXP_RTSTA_PME bit in PCI_EXP_RTCTL register does
nothing. This is because PCIe PME driver expects to receive PCIe interrupt
defined in PCI_EXP_FLAGS_IRQ register, but aardvark hardware does not
trigger PCIe INTx/MSI interrupt for PME event, rather it triggers custom
aardvark interrupt which this driver is not processing yet.
Fix this issue by handling PME interrupt in advk_pcie_handle_int() and
chaining it to PCIe interrupt 0 with generic_handle_domain_irq() (since
aardvark sets PCI_EXP_FLAGS_IRQ to zero). With this change PCIe PME driver
finally starts receiving PME interrupt.
Link: https://lore.kernel.org/r/20220110015018.26359-17-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
To optimize advk_pci_bridge_emul_pcie_conf_write() code, touch
PCIE_ISR0_REG and PCIE_ISR0_MASK_REG registers only when it is really
needed, when processing PCI_EXP_RTCTL_PMEIE and PCI_EXP_RTSTA_PME bits.
Link: https://lore.kernel.org/r/20220110015018.26359-16-kabel@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>