r4 is cleared at function entry and used as tail call count.
But when the function does not perform tail call, r4 is
ignored, so no need to clear it.
Replace it by a NOP in that case.
Signed-off-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp32.c | 5 -
1 file changed, 4
Now that two real additional passes are performed in case of extra pass
requested by BPF core, padding is not needed anymore except during
initial pass done before memory allocation to count maximum possible
program size.
So, only do the padding when 'image' is NULL.
Signed-off-by: Christophe
That test was introducted in 2006 by
commit 00ae36de49cc ("[POWERPC] Better check in show_instructions").
At that time, there was no BPF progs.
As seen in message of commit 89d21e259a94 ("powerpc/bpf/32: Fix Oops
on tail call tests"), when a page fault occurs in test_bpf.ko for
instance, the code
BPF progs are never called with more than one argument, plus the
tail call count as a second argument when needed.
So, no need to retrieve 9th and 10th argument (5th 64 bits argument)
from the stack in prologue.
Signed-off-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp32.c | 6 --
test_bpf tail call tests end up as:
test_bpf: #0 Tail call leaf jited:1 85 PASS
test_bpf: #1 Tail call 2 jited:1 111 PASS
test_bpf: #2 Tail call 3 jited:1 145 PASS
test_bpf: #3 Tail call 4 jited:1 170 PASS
test_bpf: #4 Tail call load/store leaf jited:1 190 PASS
test_bpf: #5 Tail call
Cause pseries and POWERNV platforms to default to zeroising all potentially
user-defined registers when entering the kernel by means of any interrupt
source, reducing user-influence of the kernel and the likelihood or
producing speculation gadgets.
Acked-by: Nicholas Piggin
Signed-off-by: Rohan
Zero GPRS r14-r31 on entry into the kernel for interrupt sources to
limit influence of user-space values in potential speculation gadgets.
Prior to this commit, all other GPRS are reassigned during the common
prologue to interrupt handlers and so need not be zeroised explicitly.
This may be done
Zeroise user state in gprs (assign to zero) to reduce the influence of user
registers on speculation within kernel syscall handlers. Clears occur
at the very beginning of the sc and scv 0 interrupt handlers, with
restores occurring following the execution of the syscall handler.
Zeroise GPRS r0,
Interrupt handlers in asm/exceptions-64s.S contain a great deal of common
code produced by the GEN_COMMON macros. Currently, at the exit point of
the macro, r12 will contain the contents of the MSR. A future patch will
cause these macros to zeroise architected registers to avoid potential
Add Kconfig option for enabling clearing of registers on arrival in an
interrupt handler. This reduces the speculation influence of registers
on kernel internals. The option will be consumed by 64-bit systems that
feature speculation and wish to implement this mitigation.
This patch only
Include in asm/ppc_asm.h macros to be used in multiple successive
patches to implement zeroising architected registers in interrupt
handlers. Registers will be sanitised in this fashion in future patches
to reduce the speculation influence of user-controlled register values.
These mitigations will
Interrupt code is shared between Book3E/S 64-bit systems for interrupt
handlers. Ensure that exit code correctly restores non-volatile gprs on
each system when CONFIG_INTERRUPT_SANITIZE_REGISTERS is enabled.
Also introduce macros for clearing/restoring registers on interrupt
entry for when this
On Wed, Nov 30, 2022 at 05:10:37PM +0300, Arınç ÜNAL wrote:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> ---
> arch/arm/boot/dts/imx6qdl-skov-cpu.dtsi | 1 -
> arch/arm/boot/dts/imx6qp-prtwd3.dts
On Wed, Nov 30, 2022 at 3:14 PM Arınç ÜNAL wrote:
>
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> ---
> arch/mips/boot/dts/ralink/mt7621.dtsi | 1 -
Acked-by: Sergio Paracuellos
Thanks,
Sergio Paracuellos
On Wed, Nov 30, 2022 at 09:19:25 -0600, Greg Joyce wrote:
> On Wed, 2022-11-30 at 08:00 +0100, Hannes Reinecke wrote:
> > On 11/30/22 00:25, gjo...@linux.vnet.ibm.com wrote:
> > > + case OPAL_KEYRING:
> > > + /* the key is in the keyring */
> > > + ret =
On Thu Dec 1, 2022 at 6:45 AM AEST, Crystal Wood wrote:
> On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote:
> > BookE KVM is in a deep maintenance state, I'm not sure how much testing
> > it gets. I don't have a test setup, and it does not look like QEMU has
> > any HV architecture
Sean Christopherson writes:
> Move KVM PPC's compatibility checks to their respective module_init()
> hooks, there's no need to wait until KVM's common compat check, nor is
> there a need to perform the check on every CPU (provided by common KVM's
> hook), as the compatibility checks operate on
The latest version of grep claims the egrep is now obsolete so the build
now contains warnings that look like:
egrep: warning: egrep is obsolescent; using grep -E
fix this using "grep -E" instead.
sed -i "s/egrep/grep -E/g" `grep egrep -rwl tools/testing/selftests/powerpc`
Here are the
On Wed, 2022-11-30 at 23:02 +, Sean Christopherson wrote:
> On Thu, Nov 10, 2022, Sean Christopherson wrote:
> > On Thu, Nov 10, 2022, Robert Hoo wrote:
> > > After this patch set, still find some printk()s left in
> > > arch/x86/kvm/*,
> > > consider clean all of them up?
> >
> > Hmm, yeah,
On Wed, 30 Nov 2022, Roger Pau Monne wrote:
> The currently lockless access to the xen console list in
> vtermno_to_xencons() is incorrect, as additions and removals from the
> list can happen anytime, and as such the traversal of the list to get
> the private console data for a given termno needs
On Wed, 30 Nov 2022, Roger Pau Monne wrote:
> The hvc machinery registers both a console and a tty device based on
> the hv ops provided by the specific implementation. Those two
> interfaces however have different locks, and there's no single locks
> that's shared between the tty and the console
Convert the last two "out" lables to "err" labels now that the dust has
settled, i.e. now that there are no more planned changes to the order
of things in kvm_init().
Use "err" instead of "out" as it's easier to describe what failed than it
is to describe what needs to be unwound, e.g. if
Allow architectures to opt out of the generic hardware enabling logic,
and opt out on both s390 and PPC, which don't need to manually enable
virtualization as it's always on (when available).
In addition to letting s390 and PPC drop a bit of dead code, this will
hopefully also allow ARM to clean
Register the suspend/resume notifier hooks at the same time KVM registers
its reboot notifier so that all the code in kvm_init() that deals with
enabling/disabling hardware is bundled together. Opportunstically move
KVM's implementations to reside near the reboot notifier code for the
same
From: Isaku Yamahata
Rework detecting hardware enabling errors to use a local variable in the
"enable all" path to track whether or not enabling was successful across
all CPUs. Using a global variable complicates paths that enable hardware
only on the current CPU, e.g. kvm_resume() and
Use a per-CPU variable instead of a shared bitmap to track which CPUs
have successfully enabled virtualization hardware. Using a per-CPU bool
avoids the need for an additional allocation, and arguably yields easier
to read code. Using a bitmap would be advantageous if KVM used it to
avoid
From: Isaku Yamahata
Drop the superfluous invocation of hardware_disable_nolock() during
kvm_exit(), as it's nothing more than a glorified nop.
KVM automatically disables hardware on all CPUs when the last VM is
destroyed, and kvm_exit() cannot be called until the last VM goes
away as the
From: Isaku Yamahata
Drop kvm_count_lock and instead protect kvm_usage_count with kvm_lock now
that KVM hooks CPU hotplug during the ONLINE phase, which can sleep.
Previously, KVM hooked the STARTING phase, which is not allowed to sleep
and thus could not take kvm_lock (a mutex). This
Use the non-raw smp_processor_id() in the low hardware enable/disable
helpers as KVM absolutely relies on the CPU being stable, e.g. KVM would
end up with incorrect state if the task were migrated between accessing
cpus_hardware_enabled and actually enabling/disabling hardware.
Signed-off-by:
From: Chao Gao
Disable CPU hotplug when enabling/disabling hardware to prevent the
corner case where if the following sequence occurs:
1. A hotplugged CPU marks itself online in cpu_online_mask
2. The hotplugged CPU enables interrupt before invoking KVM's ONLINE
callback
3
From: Chao Gao
The CPU STARTING section doesn't allow callbacks to fail. Move KVM's
hotplug callback to ONLINE section so that it can abort onlining a CPU in
certain cases to avoid potentially breaking VMs running on existing CPUs.
For example, when KVM fails to enable hardware virtualization on
From: Chao Gao
Do compatibility checks when enabling hardware to effectively add
compatibility checks when onlining a CPU. Abort enabling, i.e. the
online process, if the (hotplugged) CPU is incompatible with the known
good setup.
At init time, KVM does compatibility checks to ensure that all
Move the .check_processor_compatibility() callback from kvm_x86_init_ops
to kvm_x86_ops to allow a future patch to do compatibility checks during
CPU hotplug.
Do kvm_ops_update() before compat checks so that static_call() can be
used during compat checks.
Signed-off-by: Sean Christopherson
---
Check that SVM is supported and enabled in the processor compatibility
checks. SVM already checks for support during hardware enabling,
i.e. this doesn't really add new functionality. The net effect is that
KVM will refuse to load if a CPU doesn't have SVM fully enabled, as
opposed to failing
Reorder code in vmx.c so that the VMX support check helpers reside above
the hardware enabling helpers, which will allow KVM to perform support
checks during hardware enabling (in a future patch).
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c |
Do basic VMX/SVM support checks directly in vendor code instead of
implementing them via kvm_x86_ops hooks. Beyond the superficial benefit
of providing common messages, which isn't even clearly a net positive
since vendor code can provide more precise/detailed messages, there's
zero advantage to
Use this_cpu_has() instead of boot_cpu_has() to perform the effective
"disabled by BIOS?" checks for VMX. This will allow consolidating code
between vmx_disabled_by_bios() and vmx_check_processor_compat().
Checking the boot CPU isn't a strict requirement as any divergence in VMX
enabling between
Drop kvm_arch_check_processor_compat() and its support code now that all
architecture implementations are nops.
Signed-off-by: Sean Christopherson
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eric Farman # s390
Acked-by: Anup Patel
---
arch/arm64/kvm/arm.c | 7 +--
Define pr_fmt using KBUILD_MODNAME for all KVM x86 code so that printks
use consistent formatting across common x86, Intel, and AMD code. In
addition to providing consistent print formatting, using KBUILD_MODNAME,
e.g. kvm_amd and kvm_intel, allows referencing SVM and VMX (and SEV and
SGX and
Use KBUILD_MODNAME to specify the vendor module name instead of manually
writing out the name to make it a bit more obvious that the name isn't
completely arbitrary. A future patch will also use KBUILD_MODNAME to
define pr_fmt, at which point using KBUILD_MODNAME for kvm_x86_ops.name
further
Am Mittwoch, 30. November 2022, 15:10:38 CET schrieb Arınç ÜNAL:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> ---
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
>
On 30.11.2022 18:55, Andrew Lunn wrote:
On Wed, Nov 30, 2022 at 05:10:35PM +0300, Arınç ÜNAL wrote:
Hello folks,
With this patch series, we're completely getting rid of 'label = "cpu";'
which is not used by the DSA dt-binding at all.
Information for taking the patches for maintainers:
Patch
On Wed, Nov 30, 2022 at 05:10:35PM +0300, Arınç ÜNAL wrote:
> Hello folks,
>
> With this patch series, we're completely getting rid of 'label = "cpu";'
> which is not used by the DSA dt-binding at all.
>
> Information for taking the patches for maintainers:
> Patch 1: netdev maintainers (based
CC cleger
On Wed, Nov 30, 2022 at 3:33 PM Arınç ÜNAL wrote:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> arch/arm/boot/dts/r9a06g032.dtsi | 1 -
Acked-by: Geert Uytterhoeven
> ---
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Signed-off-by: Arınç ÜNAL
---
arch/mips/boot/dts/qca/ar9331.dtsi| 1 -
arch/mips/boot/dts/ralink/mt7621.dtsi | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/mips/boot/dts/qca/ar9331.dtsi
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Signed-off-by: Arınç ÜNAL
---
arch/powerpc/boot/dts/turris1x.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/turris1x.dts
b/arch/powerpc/boot/dts/turris1x.dts
index
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Signed-off-by: Arınç ÜNAL
---
arch/arm64/boot/dts/freescale/imx8mm-venice-gw7901.dts | 1 -
arch/arm64/boot/dts/freescale/imx8mp-venice-gw74xx.dts | 1 -
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
Hello folks,
With this patch series, we're completely getting rid of 'label = "cpu";'
which is not used by the DSA dt-binding at all.
Information for taking the patches for maintainers:
Patch 1: netdev maintainers (based off netdev/net-next.git main)
Patch 2-3: SoC maintainers (based off
This is not used by the DSA dt-binding, so remove it from all devicetrees.
Signed-off-by: Arınç ÜNAL
---
arch/arm/boot/dts/armada-370-rd.dts | 1 -
arch/arm/boot/dts/armada-381-netgear-gs110emx.dts | 1 -
arch/arm/boot/dts/armada-385-clearfog-gtr-l8.dts |
This is not used by the DSA dt-binding, so remove it from the examples.
Signed-off-by: Arınç ÜNAL
---
Documentation/devicetree/bindings/net/qca,ar71xx.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
Move the CPU compatibility checks to pure x86 code, i.e. drop x86's use
of the common kvm_x86_check_cpu_compat() arch hook. x86 is the only
architecture that "needs" to do per-CPU compatibility checks, moving
the logic to x86 will allow dropping the common code, and will also
give x86 more
Tag vmcs_config and vmx_capability structs as __init, the canonical
configuration is generated during hardware_setup() and must never be
modified after that point.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/capabilities.h | 4 ++--
arch/x86/kvm/vmx/vmx.c | 4 ++--
2 files
Drop kvm_arch_init() and kvm_arch_exit() now that all implementations
are nops.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Eric Farman # s390
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Anup Patel
---
arch/arm64/kvm/arm.c| 11 ---
Tag __kvm_s390_init() and its unique helpers as __init. These functions
are only ever called during module_init(), but could not be tagged
accordingly while they were invoked from the common kvm_arch_init(),
which is not __init because of x86.
Signed-off-by: Sean Christopherson
Reviewed-by:
Move the guts of kvm_arch_init() into a new helper, __kvm_s390_init(),
and invoke the new helper directly from kvm_s390_init() instead of
bouncing through kvm_init(). Invoking kvm_arch_init() is the very
first action performed by kvm_init(), i.e. this is a glorified nop.
Moving setup to
Move KVM PPC's compatibility checks to their respective module_init()
hooks, there's no need to wait until KVM's common compat check, nor is
there a need to perform the check on every CPU (provided by common KVM's
hook), as the compatibility checks operate on global data.
Now that KVM setup is handled directly in riscv_kvm_init(), tag functions
and data that are used/set only during init with __init/__ro_after_init.
Signed-off-by: Sean Christopherson
Acked-by: Anup Patel
---
arch/riscv/include/asm/kvm_host.h | 6 +++---
arch/riscv/kvm/mmu.c | 12
Fold the guts of kvm_arch_init() into riscv_kvm_init() instead of
bouncing through kvm_init()=>kvm_arch_init(). Functionally, this is a
glorified nop as invoking kvm_arch_init() is the very first action
performed by kvm_init().
Moving setup to riscv_kvm_init(), which is tagged __init, will allow
Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes
/dev/kvm to userspace and thus allows userspace to create VMs (and call
other ioctls).
Signed-off-by: Sean Christopherson
Reviewed-by: Philippe Mathieu-Daudé
---
arch/mips/kvm/mips.c | 9 +
1 file changed, 5
Invoke kvm_mips_emulation_init() directly from kvm_mips_init() instead
of bouncing through kvm_init()=>kvm_arch_init(). Functionally, this is
a glorified nop as invoking kvm_arch_init() is the very first action
performed by kvm_init().
Emptying kvm_arch_init() will allow dropping the hook
Now that KVM no longer supports trap-and-emulate (see commit 45c7e8af4a5e
"MIPS: Remove KVM_TE support"), hardcode the MIPS callbacks to the
virtualization callbacks.
Harcoding the callbacks eliminates the technically-unnecessary check on
non-NULL kvm_mips_callbacks in kvm_arch_init(). MIPS has
Tag kvm_arm_init() and its unique helper as __init, and tag data that is
only ever modified under the kvm_arm_init() umbrella as read-only after
init.
Opportunistically name the boolean param in kvm_timer_hyp_init()'s
prototype to match its definition.
Signed-off-by: Sean Christopherson
---
Do arm/arch specific initialization directly in arm's module_init(), now
called kvm_arm_init(), instead of bouncing through kvm_init() to reach
kvm_arch_init(). Invoking kvm_arch_init() is the very first action
performed by kvm_init(), so from a initialization perspective this is a
glorified nop.
Undo everything done by init_subsystems() if a later initialization step
fails, i.e. unregister perf callbacks in addition to unregistering the
power management notifier.
Fixes: bfa79a805454 ("KVM: arm64: Elevate hypervisor mappings creation at EL2")
Signed-off-by: Sean Christopherson
---
Teardown hypervisor mode if vector slot setup fails in order to avoid
leaking any allocations done by init_hyp_mode().
Fixes: b881cdce77b4 ("KVM: arm64: Allocate hyp vectors statically")
Signed-off-by: Sean Christopherson
---
arch/arm64/kvm/arm.c | 15 ---
1 file changed, 8
From: Marc Zyngier
For a number of historical reasons, the KVM/arm64 hotplug setup is pretty
complicated, and we have two extra CPUHP notifiers for vGIC and timers.
It looks pretty pointless, and gets in the way of further changes.
So let's just expose some helpers that can be called from the
Acquire a new mutex, vendor_module_lock, in kvm_x86_vendor_init() while
doing hardware setup to ensure that concurrent calls are fully serialized.
KVM rejects attempts to load vendor modules if a different module has
already been loaded, but doesn't handle the case where multiple vendor
modules
Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes
/dev/kvm to userspace and thus allows userspace to create VMs (and call
other ioctls). E.g. KVM will encounter a NULL pointer when attempting to
add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to
Move the guts of kvm_arch_init() to a new helper, kvm_x86_vendor_init(),
so that VMX can do _all_ arch and vendor initialization before calling
kvm_init(). Calling kvm_init() must be the _very_ last step during init,
as kvm_init() exposes /dev/kvm to userspace, i.e. allows creating VMs.
No
Move Hyper-V's eVMCS initialization to a dedicated helper to clean up
vmx_init(), and add a comment to call out that the Hyper-V init code
doesn't need to be unwound if vmx_init() ultimately fails.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c |
Don't disable the eVMCS static key on module exit, kvm_intel.ko owns the
key so there can't possibly be users after the kvm_intel.ko is unloaded,
at least not without much bigger issues.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c | 4
1 file changed, 4 deletions(-)
diff
Reset the eVMCS controls in the per-CPU VP assist page during hardware
disabling instead of waiting until kvm-intel's module exit. The controls
are activated if and only if KVM creates a VM, i.e. don't need to be
reset if hardware is never enabled.
Doing the reset during hardware disabling will
Drop kvm_arch_hardware_setup() and kvm_arch_hardware_unsetup() now that
all implementations are nops.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Eric Farman # s390
Acked-by: Anup Patel
---
arch/arm64/include/asm/kvm_host.h | 1 -
arch/arm64/kvm/arm.c
Now that kvm_arch_hardware_setup() is called immediately after
kvm_arch_init(), fold the guts of kvm_arch_hardware_(un)setup() into
kvm_arch_{init,exit}() as a step towards dropping one of the hooks.
To avoid having to unwind various setup, e.g registration of several
notifiers, slot in the
Move kvm_arch_init()'s call to kvm_timer_init() down a few lines below
the XCR0 configuration code. A future patch will move hardware setup
into kvm_arch_init() and slot in vendor hardware setup before the call
to kvm_timer_init() so that timer initialization (among other stuff)
doesn't need to
Now that kvm_arch_hardware_setup() is called immediately after
kvm_arch_init(), fold the guts of kvm_arch_hardware_(un)setup() into
kvm_arch_{init,exit}() as a step towards dropping one of the hooks.
No functional change intended.
Signed-off-by: Sean Christopherson
Reviewed-by: Eric Farman
---
In preparation for folding kvm_arch_hardware_setup() into kvm_arch_init(),
unwind initialization one step at a time instead of simply calling
kvm_arch_exit(). Using kvm_arch_exit() regardless of which initialization
step failed relies on all affected state playing nice with being undone
even if
Move the call to kvm_vfio_ops_exit() further up kvm_exit() to try and
bring some amount of symmetry to the setup order in kvm_init(), and more
importantly so that the arch hooks are invoked dead last by kvm_exit().
This will allow arch code to move away from the arch hooks without any
change in
Allocate cpus_hardware_enabled after arch hardware setup so that arch
"init" and "hardware setup" are called back-to-back and thus can be
combined in a future patch. cpus_hardware_enabled is never used before
kvm_create_vm(), i.e. doesn't have a dependency with hardware setup and
only needs to be
Move initialization of KVM's IRQ FD workqueue below arch hardware setup
as a step towards consolidating arch "init" and "hardware setup", and
eventually towards dropping the hooks entirely. There is no dependency
on the workqueue being created before hardware setup, the workqueue is
used only
The main theme of this series is to kill off kvm_arch_init(),
kvm_arch_hardware_(un)setup(), and kvm_arch_check_processor_compat(), which
all originated in x86 code from way back when, and needlessly complicate
both common KVM code and architecture code. E.g. many architectures don't
mark
Register /dev/kvm, i.e. expose KVM to userspace, only after all other
setup has completed. Once /dev/kvm is exposed, userspace can start
invoking KVM ioctls, creating VMs, etc... If userspace creates a VM
before KVM is done with its configuration, bad things may happen, e.g.
KVM will fail to
On Thu, Nov 10, 2022, Sean Christopherson wrote:
> On Thu, Nov 10, 2022, Robert Hoo wrote:
> > After this patch set, still find some printk()s left in arch/x86/kvm/*,
> > consider clean all of them up?
>
> Hmm, yeah, I suppose at this point it makes sense to tack on a patch to clean
> them up.
https://bugzilla.kernel.org/show_bug.cgi?id=216713
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote:
> BookE KVM is in a deep maintenance state, I'm not sure how much testing
> it gets. I don't have a test setup, and it does not look like QEMU has
> any HV architecture enabled. It hasn't been too painful but there are
> some cases where it
From: Greg Joyce
Changelog v5:
- added check for key length based on review comment by
"Elliott, Robert (Servers)"
Changelog v4:
- scope reduced to cover just SED Opal keys
- base SED Opal keystore is now in SED block driver
- removed use of enum to
From: Greg Joyce
Allow for permanent SED authentication keys by
reading/writing to the SED Opal non-volatile keystore.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
block/sed-opal.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git
From: Greg Joyce
Define operations for SED Opal to read/write keys
from POWER LPAR Platform KeyStore(PLPKS). This allows
for non-volatile storage of SED Opal keys.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
arch/powerpc/platforms/pseries/Makefile | 1 +
From: Greg Joyce
Add read and write functions that allow SED Opal keys to stored
in a permanent keystore.
Signed-off-by: Greg Joyce
Reviewed-by: Jonathan Derrick
---
block/Makefile | 2 +-
block/sed-opal-key.c | 23 +++
include/linux/sed-opal-key.h
Based on getPerfCountInfo v1.018 documentation, some of the
hv_gpci events were deprecated for platform firmware that
supports counter_info_version 0x8 or above.
Fix the hv_gpci event list by adding a new attribute group
called "hv_gpci_event_attrs_v6" and a "ENABLE_EVENTS_COUNTERINFO_V6"
macro
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 700e0cd3a5ce6a2cb90d9a2aab729b52f092a7d6 Add linux-next specific
files for 20221130
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211090634.ryfkk0ws-...@intel.com
https
The currently lockless access to the xen console list in
vtermno_to_xencons() is incorrect, as additions and removals from the
list can happen anytime, and as such the traversal of the list to get
the private console data for a given termno needs to happen with the
lock held. Note users that
On Wed, 2022-11-30 at 08:00 +0100, Hannes Reinecke wrote:
> On 11/30/22 00:25, gjo...@linux.vnet.ibm.com wrote:
> > From: Greg Joyce
> >
> > Extend the SED block driver so it can alternatively
> > obtain a key from a sed-opal kernel keyring. The SED
> > ioctls will indicate the source of the
The hvc machinery registers both a console and a tty device based on
the hv ops provided by the specific implementation. Those two
interfaces however have different locks, and there's no single locks
that's shared between the tty and the console implementations, hence
the driver needs to protect
On 29/11/22 20:58, Christophe Leroy wrote:
Le 29/11/2022 à 16:13, Sathvika Vasireddy a écrit :
Hi all,
On 25/11/22 09:00, Stephen Rothwell wrote:
Hi all,
After merging the powerpc-objtool tree, today's linux-next build (powerpc
pseries_le_defconfig) produced these warnings:
syzbot writes:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:b7b275e60bcd Linux 6.1-rc7
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=158a7b7388
> kernel config: https://syzkaller.appspot.com/x/.config?x=2325e409a9a893e1
>
On Wed, Nov 30, 2022 at 10:34:41AM +0100, Jan Beulich wrote:
> On 30.11.2022 10:26, Roger Pau Monné wrote:
> > On Tue, Nov 29, 2022 at 02:12:10PM -0800, Stefano Stabellini wrote:
> >> On Tue, 29 Nov 2022, Roger Pau Monne wrote:
> >>> The hvc machinery registers both a console and a tty device
On 30.11.2022 10:26, Roger Pau Monné wrote:
> On Tue, Nov 29, 2022 at 02:12:10PM -0800, Stefano Stabellini wrote:
>> On Tue, 29 Nov 2022, Roger Pau Monne wrote:
>>> The hvc machinery registers both a console and a tty device based on
>>> the hv ops provided by the specific implementation. Those
On Thu, 7 Jul 2022 09:59:49 +0800, Li zeming wrote:
> I think the header file could avoid redefinition errors.
> at compile time by adding macro definitions.
>
>
Applied to powerpc/next.
[1/1] macintosh/windfarm_pid: Add header file macro definition
On Thu, 7 Jul 2022 09:53:52 +0800, Li zeming wrote:
> Add header file macro definition.
>
>
Applied to powerpc/next.
[1/1] macintosh/ams/ams: Add header file macro definition
https://git.kernel.org/powerpc/c/2dfcace75e1e1dfbd89af63fce1bfe8aebe38427
cheers
1 - 100 of 148 matches
Mail list logo
