mirror of
https://github.com/linux-msm/laptops-kernel.git
synced 2026-08-13 14:19:53 -07:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Cross-merge networking fixes after downstream PR (net-6.18-rc3). No conflicts or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski
@@ -27,6 +27,7 @@ Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
|
||||
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
||||
Alex Williamson <alex@shazbot.org> <alex.williamson@redhat.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
|
||||
|
||||
@@ -0,0 +1,36 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i2c/apm,xgene-slimpro-i2c.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: APM X-Gene SLIMpro Mailbox I2C
|
||||
|
||||
maintainers:
|
||||
- Khuong Dinh <khuong@os.amperecomputing.com>
|
||||
|
||||
description:
|
||||
An I2C controller accessed over the "SLIMpro" mailbox.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: apm,xgene-slimpro-i2c
|
||||
|
||||
mboxes:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- mboxes
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
compatible = "apm,xgene-slimpro-i2c";
|
||||
mboxes = <&mailbox 0>;
|
||||
};
|
||||
@@ -1,15 +0,0 @@
|
||||
APM X-Gene SLIMpro Mailbox I2C Driver
|
||||
|
||||
An I2C controller accessed over the "SLIMpro" mailbox.
|
||||
|
||||
Required properties :
|
||||
|
||||
- compatible : should be "apm,xgene-slimpro-i2c"
|
||||
- mboxes : use the label reference for the mailbox as the first parameter.
|
||||
The second parameter is the channel number.
|
||||
|
||||
Example :
|
||||
i2cslimpro {
|
||||
compatible = "apm,xgene-slimpro-i2c";
|
||||
mboxes = <&mailbox 0>;
|
||||
};
|
||||
@@ -24,6 +24,10 @@ properties:
|
||||
- enum:
|
||||
- qcom,qcs8300-qmp-ufs-phy
|
||||
- const: qcom,sa8775p-qmp-ufs-phy
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,kaanapali-qmp-ufs-phy
|
||||
- const: qcom,sm8750-qmp-ufs-phy
|
||||
- enum:
|
||||
- qcom,msm8996-qmp-ufs-phy
|
||||
- qcom,msm8998-qmp-ufs-phy
|
||||
|
||||
@@ -79,6 +79,7 @@ properties:
|
||||
- fsl,imx-audio-nau8822
|
||||
- fsl,imx-audio-sgtl5000
|
||||
- fsl,imx-audio-si476x
|
||||
- fsl,imx-audio-tlv320
|
||||
- fsl,imx-audio-tlv320aic31xx
|
||||
- fsl,imx-audio-tlv320aic32x4
|
||||
- fsl,imx-audio-wm8524
|
||||
|
||||
@@ -33,6 +33,7 @@ properties:
|
||||
- qcom,apq8096-sndcard
|
||||
- qcom,glymur-sndcard
|
||||
- qcom,qcm6490-idp-sndcard
|
||||
- qcom,qcs615-sndcard
|
||||
- qcom,qcs6490-rb3gen2-sndcard
|
||||
- qcom,qcs8275-sndcard
|
||||
- qcom,qcs9075-sndcard
|
||||
|
||||
@@ -24,10 +24,10 @@ description: |
|
||||
Instruments Smart Amp speaker protection algorithm. The
|
||||
integrated speaker voltage and current sense provides for real time
|
||||
monitoring of loudspeaker behavior.
|
||||
The TAS5825/TAS5827 is a stereo, digital input Class-D audio
|
||||
amplifier optimized for efficiently driving high peak power into
|
||||
small loudspeakers. An integrated on-chip DSP supports Texas
|
||||
Instruments Smart Amp speaker protection algorithm.
|
||||
The TAS5802/TAS5815/TAS5825/TAS5827/TAS5828 is a stereo, digital input
|
||||
Class-D audio amplifier optimized for efficiently driving high peak
|
||||
power into small loudspeakers. An integrated on-chip DSP supports
|
||||
Texas Instruments Smart Amp speaker protection algorithm.
|
||||
|
||||
Specifications about the audio amplifier can be found at:
|
||||
https://www.ti.com/lit/gpn/tas2120
|
||||
@@ -35,8 +35,10 @@ description: |
|
||||
https://www.ti.com/lit/gpn/tas2563
|
||||
https://www.ti.com/lit/gpn/tas2572
|
||||
https://www.ti.com/lit/gpn/tas2781
|
||||
https://www.ti.com/lit/gpn/tas5815
|
||||
https://www.ti.com/lit/gpn/tas5825m
|
||||
https://www.ti.com/lit/gpn/tas5827
|
||||
https://www.ti.com/lit/gpn/tas5828m
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
@@ -65,11 +67,21 @@ properties:
|
||||
Protection and Audio Processing, 16/20/24/32bit stereo I2S or
|
||||
multichannel TDM.
|
||||
|
||||
ti,tas5802: 22-W, Inductor-Less, Digital Input, Closed-Loop Class-D
|
||||
Audio Amplifier with 96-Khz Extended Processing and Low Idle Power
|
||||
Dissipation.
|
||||
|
||||
ti,tas5815: 30-W, Digital Input, Stereo, Closed-loop Class-D Audio
|
||||
Amplifier with 96 kHz Enhanced Processing
|
||||
|
||||
ti,tas5825: 38-W Stereo, Inductor-Less, Digital Input, Closed-Loop 4.5V
|
||||
to 26.4V Class-D Audio Amplifier with 192-kHz Extended Audio Processing.
|
||||
|
||||
ti,tas5827: 47-W Stereo, Digital Input, High Efficiency Closed-Loop Class-D
|
||||
Amplifier with Class-H Algorithm
|
||||
ti,tas5827: 47-W Stereo, Digital Input, High Efficiency Closed-Loop
|
||||
Class-D Amplifier with Class-H Algorithm
|
||||
|
||||
ti,tas5828: 50-W Stereo, Digital Input, High Efficiency Closed-Loop
|
||||
Class-D Amplifier with Hybrid-Pro Algorithm
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
@@ -80,8 +92,11 @@ properties:
|
||||
- ti,tas2563
|
||||
- ti,tas2570
|
||||
- ti,tas2572
|
||||
- ti,tas5802
|
||||
- ti,tas5815
|
||||
- ti,tas5825
|
||||
- ti,tas5827
|
||||
- ti,tas5828
|
||||
- const: ti,tas2781
|
||||
- enum:
|
||||
- ti,tas2781
|
||||
@@ -177,12 +192,28 @@ allOf:
|
||||
minimum: 0x38
|
||||
maximum: 0x3f
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- ti,tas5802
|
||||
- ti,tas5815
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 4
|
||||
items:
|
||||
minimum: 0x54
|
||||
maximum: 0x57
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- ti,tas5827
|
||||
- ti,tas5828
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
|
||||
@@ -15,6 +15,7 @@ select:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,kaanapali-ufshc
|
||||
- qcom,sm8650-ufshc
|
||||
- qcom,sm8750-ufshc
|
||||
required:
|
||||
@@ -24,6 +25,7 @@ properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- qcom,kaanapali-ufshc
|
||||
- qcom,sm8650-ufshc
|
||||
- qcom,sm8750-ufshc
|
||||
- const: qcom,ufshc
|
||||
|
||||
@@ -11,6 +11,7 @@ found on https://linux-ax25.in-berlin.de.
|
||||
|
||||
There is a mailing list for discussing Linux amateur radio matters
|
||||
called linux-hams@vger.kernel.org. To subscribe to it, send a message to
|
||||
majordomo@vger.kernel.org with the words "subscribe linux-hams" in the body
|
||||
of the message, the subject field is ignored. You don't need to be
|
||||
subscribed to post but of course that means you might miss an answer.
|
||||
linux-hams+subscribe@vger.kernel.org or use the web interface at
|
||||
https://vger.kernel.org. The subject and body of the message are
|
||||
ignored. You don't need to be subscribed to post but of course that
|
||||
means you might miss an answer.
|
||||
|
||||
@@ -137,16 +137,20 @@ d. Checksum offload header v5
|
||||
|
||||
Checksum offload header fields are in big endian format.
|
||||
|
||||
Packet format::
|
||||
|
||||
Bit 0 - 6 7 8-15 16-31
|
||||
Function Header Type Next Header Checksum Valid Reserved
|
||||
|
||||
Header Type is to indicate the type of header, this usually is set to CHECKSUM
|
||||
|
||||
Header types
|
||||
= ==========================================
|
||||
|
||||
= ===============
|
||||
0 Reserved
|
||||
1 Reserved
|
||||
2 checksum header
|
||||
= ===============
|
||||
|
||||
Checksum Valid is to indicate whether the header checksum is valid. Value of 1
|
||||
implies that checksum is calculated on this packet and is valid, value of 0
|
||||
@@ -183,9 +187,11 @@ rmnet in a single linear skb. rmnet will process the individual
|
||||
packets and either ACK the MAP command or deliver the IP packet to the
|
||||
network stack as needed
|
||||
|
||||
MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding....
|
||||
Packet format::
|
||||
|
||||
MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad...
|
||||
MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding....
|
||||
|
||||
MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad...
|
||||
|
||||
3. Userspace configuration
|
||||
==========================
|
||||
|
||||
@@ -96,9 +96,8 @@ needed to these network configuration daemons to make sure that an IP is
|
||||
received only on the 'failover' device.
|
||||
|
||||
Below is the patch snippet used with 'cloud-ifupdown-helper' script found on
|
||||
Debian cloud images:
|
||||
Debian cloud images::
|
||||
|
||||
::
|
||||
@@ -27,6 +27,8 @@ do_setup() {
|
||||
local working="$cfgdir/.$INTERFACE"
|
||||
local final="$cfgdir/$INTERFACE"
|
||||
@@ -172,9 +171,8 @@ appropriate FDB entry is added.
|
||||
|
||||
The following script is executed on the destination hypervisor once migration
|
||||
completes, and it reattaches the VF to the VM and brings down the virtio-net
|
||||
interface.
|
||||
interface::
|
||||
|
||||
::
|
||||
# reattach-vf.sh
|
||||
#!/bin/bash
|
||||
|
||||
|
||||
@@ -38,6 +38,81 @@ Like ``clang-format`` for the rest of the kernel, ``rustfmt`` works on
|
||||
individual files, and does not require a kernel configuration. Sometimes it may
|
||||
even work with broken code.
|
||||
|
||||
Imports
|
||||
~~~~~~~
|
||||
|
||||
``rustfmt``, by default, formats imports in a way that is prone to conflicts
|
||||
while merging and rebasing, since in some cases it condenses several items into
|
||||
the same line. For instance:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
// Do not use this style.
|
||||
use crate::{
|
||||
example1,
|
||||
example2::{example3, example4, example5},
|
||||
example6, example7,
|
||||
example8::example9,
|
||||
};
|
||||
|
||||
Instead, the kernel uses a vertical layout that looks like this:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
use crate::{
|
||||
example1,
|
||||
example2::{
|
||||
example3,
|
||||
example4,
|
||||
example5, //
|
||||
},
|
||||
example6,
|
||||
example7,
|
||||
example8::example9, //
|
||||
};
|
||||
|
||||
That is, each item goes into its own line, and braces are used as soon as there
|
||||
is more than one item in a list.
|
||||
|
||||
The trailing empty comment allows to preserve this formatting. Not only that,
|
||||
``rustfmt`` will actually reformat imports vertically when the empty comment is
|
||||
added. That is, it is possible to easily reformat the original example into the
|
||||
expected style by running ``rustfmt`` on an input like:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
// Do not use this style.
|
||||
use crate::{
|
||||
example1,
|
||||
example2::{example3, example4, example5, //
|
||||
},
|
||||
example6, example7,
|
||||
example8::example9, //
|
||||
};
|
||||
|
||||
The trailing empty comment works for nested imports, as shown above, as well as
|
||||
for single item imports -- this can be useful to minimize diffs within patch
|
||||
series:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
use crate::{
|
||||
example1, //
|
||||
};
|
||||
|
||||
The trailing empty comment works in any of the lines within the braces, but it
|
||||
is preferred to keep it in the last item, since it is reminiscent of the
|
||||
trailing comma in other formatters. Sometimes it may be simpler to avoid moving
|
||||
the comment several times within a patch series due to changes in the list.
|
||||
|
||||
There may be cases where exceptions may need to be made, i.e. none of this is
|
||||
a hard rule. There is also code that is not migrated to this style yet, but
|
||||
please do not introduce code in other styles.
|
||||
|
||||
Eventually, the goal is to get ``rustfmt`` to support this formatting style (or
|
||||
a similar one) automatically in a stable release without requiring the trailing
|
||||
empty comment. Thus, at some point, the goal is to remove those comments.
|
||||
|
||||
|
||||
Comments
|
||||
--------
|
||||
|
||||
@@ -1229,6 +1229,9 @@ It is not possible to read back a pending external abort (injected via
|
||||
KVM_SET_VCPU_EVENTS or otherwise) because such an exception is always delivered
|
||||
directly to the virtual CPU).
|
||||
|
||||
Calling this ioctl on a vCPU that hasn't been initialized will return
|
||||
-ENOEXEC.
|
||||
|
||||
::
|
||||
|
||||
struct kvm_vcpu_events {
|
||||
@@ -1309,6 +1312,8 @@ exceptions by manipulating individual registers using the KVM_SET_ONE_REG API.
|
||||
|
||||
See KVM_GET_VCPU_EVENTS for the data structure.
|
||||
|
||||
Calling this ioctl on a vCPU that hasn't been initialized will return
|
||||
-ENOEXEC.
|
||||
|
||||
4.33 KVM_GET_DEBUGREGS
|
||||
----------------------
|
||||
@@ -6432,9 +6437,18 @@ most one mapping per page, i.e. binding multiple memory regions to a single
|
||||
guest_memfd range is not allowed (any number of memory regions can be bound to
|
||||
a single guest_memfd file, but the bound ranges must not overlap).
|
||||
|
||||
When the capability KVM_CAP_GUEST_MEMFD_MMAP is supported, the 'flags' field
|
||||
supports GUEST_MEMFD_FLAG_MMAP. Setting this flag on guest_memfd creation
|
||||
enables mmap() and faulting of guest_memfd memory to host userspace.
|
||||
The capability KVM_CAP_GUEST_MEMFD_FLAGS enumerates the `flags` that can be
|
||||
specified via KVM_CREATE_GUEST_MEMFD. Currently defined flags:
|
||||
|
||||
============================ ================================================
|
||||
GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file
|
||||
descriptor.
|
||||
GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during
|
||||
KVM_CREATE_GUEST_MEMFD (memory files created
|
||||
without INIT_SHARED will be marked private).
|
||||
Shared memory can be faulted into host userspace
|
||||
page tables. Private memory cannot.
|
||||
============================ ================================================
|
||||
|
||||
When the KVM MMU performs a PFN lookup to service a guest fault and the backing
|
||||
guest_memfd has the GUEST_MEMFD_FLAG_MMAP set, then the fault will always be
|
||||
|
||||
@@ -13,7 +13,8 @@ will act as the VM interrupt controller, requiring emulated user-space devices
|
||||
to inject interrupts to the VGIC instead of directly to CPUs. It is not
|
||||
possible to create both a GICv3 and GICv2 on the same VM.
|
||||
|
||||
Creating a guest GICv3 device requires a host GICv3 as well.
|
||||
Creating a guest GICv3 device requires a host GICv3 host, or a GICv5 host with
|
||||
support for FEAT_GCIE_LEGACY.
|
||||
|
||||
|
||||
Groups:
|
||||
|
||||
+3
-2
@@ -3841,6 +3841,7 @@ F: drivers/hwmon/asus-ec-sensors.c
|
||||
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
|
||||
M: Corentin Chary <corentin.chary@gmail.com>
|
||||
M: Luke D. Jones <luke@ljones.dev>
|
||||
M: Denis Benato <benato.denis96@gmail.com>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://asus-linux.org/
|
||||
@@ -26892,7 +26893,7 @@ S: Maintained
|
||||
F: drivers/vfio/cdx/*
|
||||
|
||||
VFIO DRIVER
|
||||
M: Alex Williamson <alex.williamson@redhat.com>
|
||||
M: Alex Williamson <alex@shazbot.org>
|
||||
L: kvm@vger.kernel.org
|
||||
S: Maintained
|
||||
T: git https://github.com/awilliam/linux-vfio.git
|
||||
@@ -27055,7 +27056,7 @@ T: git git://linuxtv.org/media.git
|
||||
F: drivers/media/test-drivers/vimc/*
|
||||
|
||||
VIRT LIB
|
||||
M: Alex Williamson <alex.williamson@redhat.com>
|
||||
M: Alex Williamson <alex@shazbot.org>
|
||||
M: Paolo Bonzini <pbonzini@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
VERSION = 6
|
||||
PATCHLEVEL = 18
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc1
|
||||
EXTRAVERSION = -rc2
|
||||
NAME = Baby Opossum Posse
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
||||
@@ -965,6 +965,7 @@ config HAVE_CFI_ICALL_NORMALIZE_INTEGERS_RUSTC
|
||||
def_bool y
|
||||
depends on HAVE_CFI_ICALL_NORMALIZE_INTEGERS
|
||||
depends on RUSTC_VERSION >= 107900
|
||||
depends on ARM64 || X86_64
|
||||
# With GCOV/KASAN we need this fix: https://github.com/rust-lang/rust/pull/129373
|
||||
depends on (RUSTC_LLVM_VERSION >= 190103 && RUSTC_VERSION >= 108200) || \
|
||||
(!GCOV_KERNEL && !KASAN_GENERIC && !KASAN_SW_TAGS)
|
||||
|
||||
@@ -24,22 +24,48 @@
|
||||
* ID_AA64MMFR4_EL1.E2H0 < 0. On such CPUs HCR_EL2.E2H is RES1, but it
|
||||
* can reset into an UNKNOWN state and might not read as 1 until it has
|
||||
* been initialized explicitly.
|
||||
*
|
||||
* Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but
|
||||
* don't advertise it (they predate this relaxation).
|
||||
*
|
||||
* Initalize HCR_EL2.E2H so that later code can rely upon HCR_EL2.E2H
|
||||
* indicating whether the CPU is running in E2H mode.
|
||||
*/
|
||||
mrs_s x1, SYS_ID_AA64MMFR4_EL1
|
||||
sbfx x1, x1, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH
|
||||
cmp x1, #0
|
||||
b.ge .LnVHE_\@
|
||||
b.lt .LnE2H0_\@
|
||||
|
||||
/*
|
||||
* Unfortunately, HCR_EL2.E2H can be RES1 even if not advertised
|
||||
* as such via ID_AA64MMFR4_EL1.E2H0:
|
||||
*
|
||||
* - Fruity CPUs predate the !FEAT_E2H0 relaxation, and seem to
|
||||
* have HCR_EL2.E2H implemented as RAO/WI.
|
||||
*
|
||||
* - On CPUs that lack FEAT_FGT, a hypervisor can't trap guest
|
||||
* reads of ID_AA64MMFR4_EL1 to advertise !FEAT_E2H0. NV
|
||||
* guests on these hosts can write to HCR_EL2.E2H without
|
||||
* trapping to the hypervisor, but these writes have no
|
||||
* functional effect.
|
||||
*
|
||||
* Handle both cases by checking for an essential VHE property
|
||||
* (system register remapping) to decide whether we're
|
||||
* effectively VHE-only or not.
|
||||
*/
|
||||
msr_hcr_el2 x0 // Setup HCR_EL2 as nVHE
|
||||
isb
|
||||
mov x1, #1 // Write something to FAR_EL1
|
||||
msr far_el1, x1
|
||||
isb
|
||||
mov x1, #2 // Try to overwrite it via FAR_EL2
|
||||
msr far_el2, x1
|
||||
isb
|
||||
mrs x1, far_el1 // If we see the latest write in FAR_EL1,
|
||||
cmp x1, #2 // we can safely assume we are VHE only.
|
||||
b.ne .LnVHE_\@ // Otherwise, we know that nVHE works.
|
||||
|
||||
.LnE2H0_\@:
|
||||
orr x0, x0, #HCR_E2H
|
||||
.LnVHE_\@:
|
||||
msr_hcr_el2 x0
|
||||
isb
|
||||
.LnVHE_\@:
|
||||
.endm
|
||||
|
||||
.macro __init_el2_sctlr
|
||||
|
||||
@@ -816,6 +816,11 @@ struct kvm_vcpu_arch {
|
||||
u64 hcrx_el2;
|
||||
u64 mdcr_el2;
|
||||
|
||||
struct {
|
||||
u64 r;
|
||||
u64 w;
|
||||
} fgt[__NR_FGT_GROUP_IDS__];
|
||||
|
||||
/* Exception Information */
|
||||
struct kvm_vcpu_fault_info fault;
|
||||
|
||||
@@ -1600,6 +1605,51 @@ static inline bool kvm_arch_has_irq_bypass(void)
|
||||
void compute_fgu(struct kvm *kvm, enum fgt_group_id fgt);
|
||||
void get_reg_fixed_bits(struct kvm *kvm, enum vcpu_sysreg reg, u64 *res0, u64 *res1);
|
||||
void check_feature_map(void);
|
||||
void kvm_vcpu_load_fgt(struct kvm_vcpu *vcpu);
|
||||
|
||||
static __always_inline enum fgt_group_id __fgt_reg_to_group_id(enum vcpu_sysreg reg)
|
||||
{
|
||||
switch (reg) {
|
||||
case HFGRTR_EL2:
|
||||
case HFGWTR_EL2:
|
||||
return HFGRTR_GROUP;
|
||||
case HFGITR_EL2:
|
||||
return HFGITR_GROUP;
|
||||
case HDFGRTR_EL2:
|
||||
case HDFGWTR_EL2:
|
||||
return HDFGRTR_GROUP;
|
||||
case HAFGRTR_EL2:
|
||||
return HAFGRTR_GROUP;
|
||||
case HFGRTR2_EL2:
|
||||
case HFGWTR2_EL2:
|
||||
return HFGRTR2_GROUP;
|
||||
case HFGITR2_EL2:
|
||||
return HFGITR2_GROUP;
|
||||
case HDFGRTR2_EL2:
|
||||
case HDFGWTR2_EL2:
|
||||
return HDFGRTR2_GROUP;
|
||||
default:
|
||||
BUILD_BUG_ON(1);
|
||||
}
|
||||
}
|
||||
|
||||
#define vcpu_fgt(vcpu, reg) \
|
||||
({ \
|
||||
enum fgt_group_id id = __fgt_reg_to_group_id(reg); \
|
||||
u64 *p; \
|
||||
switch (reg) { \
|
||||
case HFGWTR_EL2: \
|
||||
case HDFGWTR_EL2: \
|
||||
case HFGWTR2_EL2: \
|
||||
case HDFGWTR2_EL2: \
|
||||
p = &(vcpu)->arch.fgt[id].w; \
|
||||
break; \
|
||||
default: \
|
||||
p = &(vcpu)->arch.fgt[id].r; \
|
||||
break; \
|
||||
} \
|
||||
\
|
||||
p; \
|
||||
})
|
||||
|
||||
#endif /* __ARM64_KVM_HOST_H__ */
|
||||
|
||||
@@ -1220,10 +1220,19 @@
|
||||
__val; \
|
||||
})
|
||||
|
||||
/*
|
||||
* The "Z" constraint combined with the "%x0" template should be enough
|
||||
* to force XZR generation if (v) is a constant 0 value but LLVM does not
|
||||
* yet understand that modifier/constraint combo so a conditional is required
|
||||
* to nudge the compiler into using XZR as a source for a 0 constant value.
|
||||
*/
|
||||
#define write_sysreg_s(v, r) do { \
|
||||
u64 __val = (u64)(v); \
|
||||
u32 __maybe_unused __check_r = (u32)(r); \
|
||||
asm volatile(__msr_s(r, "%x0") : : "rZ" (__val)); \
|
||||
if (__builtin_constant_p(__val) && __val == 0) \
|
||||
asm volatile(__msr_s(r, "xzr")); \
|
||||
else \
|
||||
asm volatile(__msr_s(r, "%x0") : : "r" (__val)); \
|
||||
} while (0)
|
||||
|
||||
/*
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user