Le 24/02/2025 à 18:09, Nathan Chancellor a écrit :
On Mon, Feb 24, 2025 at 02:19:14PM +0100, Christophe Leroy wrote:
Well, this problem already exists on clang 18 it seems:
0004 :
4: 7c 08 02 a6 mflrr0
8: 94 21 ff e0 stwur1,-32(r1)
c: 93 c1 00 18 stw
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 58b82d6fd77c..045c61cc7e54 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -12890,11 +12890,11 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> mutex_unlock(&kvm->slots_lock);
> }
> kvm_unload_v
On Mon, Feb 24, 2025 at 03:55:39PM -0800, Sean Christopherson wrote:
> Don't load (and then put) a vCPU when unloading its MMU during VM
> destruction, as nothing in kvm_mmu_unload() accesses vCPU state beyond the
> root page/address of each MMU, i.e. can't possible need to run with the
> vCPU load
On Mon, Feb 24, 2025 at 03:55:38PM -0800, Sean Christopherson wrote:
> After freeing a vCPU, assert that it is no longer reachable, and that
> kvm_get_vcpu() doesn't return garbage or a pointer to some other vCPU.
> While KVM obviously shouldn't be attempting to access a freed vCPU, it's
> all too
On 2025/2/18 22:10, Yicong Yang wrote:
From: Yicong Yang
For ACPI we'll build the topology from PPTT and we cannot directly
get the SMT number of each core. Instead using a temporary xarray
to record the heterogeneous information (from ACPI_PPTT_ACPI_IDENTICAL)
and SMT information of the first
On Thu, Feb 20, 2025 at 07:33:34PM +0100, Gerald Schaefer wrote:
> On Tue, 18 Feb 2025 14:55:36 +1100
> Alistair Popple wrote:
>
> [...]
> > diff --git a/mm/memremap.c b/mm/memremap.c
> > index 9a8879b..532a52a 100644
> > --- a/mm/memremap.c
> > +++ b/mm/memremap.c
> > @@ -460,11 +460,10 @@ void
Le 24/02/2025 à 19:54, Maciej W. Rozycki a écrit :
***ATTENTION, Sopra Steria Group cannot confirm the identity of this email
sender (SPF record failure). This might be a fake email from an attacker, if
you have any doubts report and delete the email.***
***ATTENTION, Sopra Steria Group ne
On Mon, Feb 24, 2025 at 11:00 AM Andrey Albershteyn wrote:
> On 2025-02-21 16:08:33, Mickaël Salaün wrote:
> > It looks security checks are missing. With IOCTL commands, file
> > permissions are checked at open time, but with these syscalls the path
> > is only resolved but no specific access see
allnoconfiggcc-13.2.0
arc allyesconfiggcc-13.2.0
arc randconfig-001-20250224gcc-13.2.0
arc randconfig-001-20250225gcc-13.2.0
arc randconfig-002-20250224gcc-13.2.0
arc
Remove kvm_arch_sync_events() now that x86 no longer uses it (no other
arch has ever used it).
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/kvm_host.h | 2 --
arch/loongarch/include/asm/kvm_host.h | 1 -
arch/mips/include/asm/kvm_host.h |
Fold the guts of kvm_arch_sync_events() into kvm_arch_pre_destroy_vm(), as
the kvmclock and PIT background workers only need to be stopped before
destroying vCPUs (to avoid accessing vCPUs as they are being freed); it's
a-ok for them to be running while the VM is visible on the global vm_list.
Not
When destroying a VM, unload a vCPU's MMUs as part of normal vCPU freeing,
instead of as a separate prepratory action. Unloading MMUs ahead of time
is a holdover from commit 7b53aa565084 ("KVM: Fix vcpu freeing for guest
smp"), which "fixed" a rather egregious flaw where KVM would attempt to
free
Don't load (and then put) a vCPU when unloading its MMU during VM
destruction, as nothing in kvm_mmu_unload() accesses vCPU state beyond the
root page/address of each MMU, i.e. can't possible need to run with the
vCPU loaded.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/x86.c | 9 +---
After freeing a vCPU, assert that it is no longer reachable, and that
kvm_get_vcpu() doesn't return garbage or a pointer to some other vCPU.
While KVM obviously shouldn't be attempting to access a freed vCPU, it's
all too easy for KVM to make a VM-wide request, e.g. via KVM_BUG_ON() or
kvm_flush_re
Free vCPUs before freeing any VM state, as both SVM and VMX may access
VM state when "freeing" a vCPU that is currently "in" L2, i.e. that needs
to be kicked out of nested guest mode.
Commit 6fcee03df6a1 ("KVM: x86: avoid loading a vCPU after .vm_destroy was
called") partially fixed the issue, but
Process pending events on nested VM-Exit if the vCPU has an injectable IRQ
or NMI, as the event may have become pending while L2 was active, i.e. may
not be tracked in the context of vmcs01. E.g. if L1 has passed its APIC
through to L2 and an IRQ arrives while L2 is active, then KVM needs to
reque
This was _supposed_ to be a tiny one-off patch to fix a nVMX bug where KVM
fails to detect that, after nested VM-Exit, L1 has a pending IRQ (or NMI).
But because x86's nested teardown flows are garbage (KVM simply forces a
nested VM-Exit to put the vCPU back into L1), that simple fix snowballed.
T
On Sat, Feb 22, 2025 at 8:38 AM Sven Peter via B4 Relay
wrote:
>
> Hi,
>
> This series adds a few fixes/improvements to the error recovery for
> Apple/PASemi i2c controllers.
> The patches have been in our downstream tree and were originally used
> to debug a rare glitch caused by clock strechting
Reviewed-by: Alyssa Rosenzweig
Le Sat , Feb 22, 2025 at 01:38:32PM +, Sven Peter via B4 Relay a écrit :
> Hi,
>
> This series adds a few fixes/improvements to the error recovery for
> Apple/PASemi i2c controllers.
> The patches have been in our downstream tree and were originally used
> to d
On Tue, Jan 28, 2025 at 11:46:29AM -0500, Yury Norov wrote:
> cpumask_next_wrap() is overly complicated, comparing to it's generic
> version find_next_bit_wrap(), not mentioning it duplicates the above.
> It roots to the times when the function was used in the implementation
> of for_each_cpu_wrap(
On Mon, 24 Feb 2025, Christophe Leroy wrote:
> > Restricted pointers ("%pK") are not meant to be used through printk().
> > It can unintentionally expose security sensitive, raw pointer values.
> >
> > Use regular pointer formatting instead.
> >
> > Link:
> > https://eur01.safelinks.protection.o
Le 24/02/2025 à 17:25, Peter Zijlstra a écrit :
On Fri, Feb 21, 2025 at 02:20:41PM +0530, Sathvika Vasireddy wrote:
@@ -1625,6 +1626,11 @@ static int add_call_destinations(struct objtool_file
*file)
reloc = insn_reloc(file, insn);
if (!reloc) {
On Mon, Feb 24, 2025 at 02:19:14PM +0100, Christophe Leroy wrote:
> Well, this problem already exists on clang 18 it seems:
>
> 0004 :
>4: 7c 08 02 a6 mflrr0
>8: 94 21 ff e0 stwur1,-32(r1)
>c: 93 c1 00 18 stw r30,24(r1)
> 10: 90 01 00 24 stw
On 2025-02-24 11:54:34, Jan Kara wrote:
> On Tue 11-02-25 18:22:47, Andrey Albershteyn wrote:
> > From: Andrey Albershteyn
> >
> > Introduce getfsxattrat and setfsxattrat syscalls to manipulate inode
> > extended attributes/flags. The syscalls take parent directory fd and
> > path to the child to
On Fri, Feb 21, 2025 at 02:20:41PM +0530, Sathvika Vasireddy wrote:
> > > @@ -1625,6 +1626,11 @@ static int add_call_destinations(struct
> > > objtool_file *file)
> > > reloc = insn_reloc(file, insn);
> > > if (!reloc) {
> > > dest_off
On 2025-02-24 12:32:17, Christian Brauner wrote:
> On Fri, Feb 21, 2025 at 08:15:24PM +0100, Amir Goldstein wrote:
> > On Fri, Feb 21, 2025 at 7:13 PM Darrick J. Wong wrote:
> > >
> > > On Tue, Feb 11, 2025 at 06:22:47PM +0100, Andrey Albershteyn wrote:
> > > > From: Andrey Albershteyn
> > > >
>
On 2025-02-21 16:08:33, Mickaël Salaün wrote:
> It looks security checks are missing. With IOCTL commands, file
> permissions are checked at open time, but with these syscalls the path
> is only resolved but no specific access seems to be checked (except
> inode_owner_or_capable via vfs_fileattr_s
Hi Christophe,
> On 24. Feb 2025, at 13:56, Christophe Leroy wrote:
> Le 19/02/2025 à 12:20, Thorsten Blum a écrit :
>> Remove hard-coded strings by using the str_enabled_disabled() helper
>> function.
>> Use pr_debug() instead of printk(KERN_DEBUG) to silence a checkpatch
>> warning.
>> Reviewed-
On 2/24/25 17:31, Christophe Leroy wrote:
>
>
> Le 17/02/2025 à 05:22, Anshuman Khandual a écrit :
>> Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
>> But generic ptdump gets enabled via PTDUMP_CORE. These configs combination
>> is confusing as they sound very simi
Le 24/02/2025 à 11:33, Christophe Leroy a écrit :
Le 24/02/2025 à 08:15, Christophe Leroy a écrit :
Le 19/02/2025 à 17:20, Sathvika Vasireddy a écrit :
Architectures like PowerPC use a pattern where the compiler generates a
branch-and-link (bl) instruction that targets the very next inst
On 2/24/25 17:34, Christophe Leroy wrote:
>
>
> Le 17/02/2025 à 05:22, Anshuman Khandual a écrit :
>> GENERIC_PTDUMP gets selected on powerpc explicitly and hence can be dropped
>> off from mpc885_ads_defconfig.
>>
>> Cc: Madhavan Srinivasan
>> Cc: Michael Ellerman
>> Cc: Nicholas Piggin
>>
On Sun, 23 Feb 2025 21:27:41 +0100
Thorsten Blum wrote:
> Remove unnecessary bool conversions and simplify the code.
>
> Signed-off-by: Thorsten Blum
> ---
> sound/soc/fsl/fsl_qmc_audio.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_qmc_audio.
Changes from v3
Link: https://lore.kernel.org/all/20250123120749.90505-1-vaib...@linux.ibm.com/
* Moved the new 'kvm-hv' pmu code to a separate module named 'kvm-hv-pmu'
* Fixed a kunit test code crash that happened when run on kvm-hv on
bare-metal.
* Minor changes to the 'kvm-hv' pmu code / patc
Add support for adding and parsing Hostwide elements to the
Guest-state-buffer data structure used in apiv2. These elements are used to
share meta-information pertaining to entire L1-Lpar and this
meta-information is maintained by L0-PowerVM hypervisor. Example of this
include the amount of the pag
Hi,
Le 19/02/2025 à 12:20, Thorsten Blum a écrit :
Remove hard-coded strings by using the str_enabled_disabled() helper
function.
Use pr_debug() instead of printk(KERN_DEBUG) to silence a checkpatch
warning.
Reviewed-by: Ricardo B. Marlière
Signed-off-by: Thorsten Blum
---
When you resend
Update 'kvm-hv-pmu.c' to add five new perf-events mapped to the five
Hostwide counters. Since these newly introduced perf events are at system
wide scope and can be read from any L1-Lpar CPU, 'kvmppc_pmu' scope and
capabilities are updated appropriately.
Also introduce two new helpers. First is kv
Implement and setup necessary structures to send a prepolulated
Guest-State-Buffer(GSB) requesting hostwide counters to L0-PowerVM and have
the returned GSB holding the values of these counters parsed. This is done
via existing GSB implementation and with the newly added support of
Hostwide element
Introduce a new PMU named 'kvm-hv' inside a new module named 'kvm-hv-pmu'
to report Book3s kvm-hv specific performance counters. This will expose
KVM-HV specific performance attributes to user-space via kernel's PMU
infrastructure and would enableusers to monitor active kvm-hv based guests.
The pa
Update 'test-guest-state-buffer.c' to add two new KUNIT test cases for
validating correctness of changes to Guest-state-buffer management
infrastructure for adding support for Hostwide GSB elements.
The newly introduced test test_gs_hostwide_msg() checks if the Hostwide
elements can be set and par
Update kvm-nested APIv2 documentation to include five new
Guest-State-Elements to fetch the hostwide counters. These counters are
per L1-Lpar and indicate the amount of Heap/Page-table memory allocated,
available and Page-table memory reclaimed for all L2-Guests active
instances
Cc: linux-...@vger
Le 17/02/2025 à 08:39, Thomas Weißschuh a écrit :
Restricted pointers ("%pK") are not meant to be used through printk().
It can unintentionally expose security sensitive, raw pointer values.
Use regular pointer formatting instead.
Link:
https://eur01.safelinks.protection.outlook.com/?url=ht
On Fri, Feb 21, 2025 at 02:20:41PM +0530, Sathvika Vasireddy wrote:
> Also, just out of curiosity, how does x86 do it? Does it not use a branch to
> next instruction approach?
x86_64 can use LEA like:
#define _THIS_IP_ ({ unsigned long __here; asm ("lea 0(%%rip), %0" : "=r"
(__here)); __here;
Le 17/02/2025 à 05:22, Anshuman Khandual a écrit :
GENERIC_PTDUMP gets selected on powerpc explicitly and hence can be dropped
off from mpc885_ads_defconfig.
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-k
Le 17/02/2025 à 05:22, Anshuman Khandual a écrit :
Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
But generic ptdump gets enabled via PTDUMP_CORE. These configs combination
is confusing as they sound very similar and does not differentiate between
platform's feature
On Fri, Feb 21, 2025 at 08:15:24PM +0100, Amir Goldstein wrote:
> On Fri, Feb 21, 2025 at 7:13 PM Darrick J. Wong wrote:
> >
> > On Tue, Feb 11, 2025 at 06:22:47PM +0100, Andrey Albershteyn wrote:
> > > From: Andrey Albershteyn
> > >
> > > Introduce getfsxattrat and setfsxattrat syscalls to manip
Le 14/02/2025 à 08:26, Anshuman Khandual a écrit :
On 2/13/25 17:19, Christophe Leroy wrote:
Le 13/02/2025 à 12:23, Steven Price a écrit :
On 13/02/2025 04:09, Anshuman Khandual wrote:
Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
But generic ptdump gets ena
Le 14/02/2025 à 08:17, Anshuman Khandual a écrit :
On 2/13/25 13:08, Christophe Leroy wrote:
Le 13/02/2025 à 05:09, Anshuman Khandual a écrit :
Platforms subscribe into generic ptdump implementation via GENERIC_PTDUMP.
But generic ptdump gets enabled via PTDUMP_CORE. These configs combinat
On Tue 11-02-25 18:22:47, Andrey Albershteyn wrote:
> From: Andrey Albershteyn
>
> Introduce getfsxattrat and setfsxattrat syscalls to manipulate inode
> extended attributes/flags. The syscalls take parent directory fd and
> path to the child together with struct fsxattr.
>
> This is an alternat
Le 21/02/2025 à 09:50, Sathvika Vasireddy a écrit :
[Vous ne recevez pas souvent de courriers de s...@linux.ibm.com. Découvrez
pourquoi ceci est important à https://aka.ms/
LearnAboutSenderIdentification ]
Hi Josh, Thanks for the review.
On 2/21/25 1:29 AM, Josh Poimboeuf wrote:
On Wed, F
Le 24/02/2025 à 08:15, Christophe Leroy a écrit :
Le 19/02/2025 à 17:20, Sathvika Vasireddy a écrit :
Architectures like PowerPC use a pattern where the compiler generates a
branch-and-link (bl) instruction that targets the very next instruction,
followed by loading the link register (mflr)
config-001-20250224gcc-13.2.0
arc randconfig-002-20250223gcc-13.2.0
arc randconfig-002-20250224gcc-13.2.0
arcvdk_hs38_defconfiggcc-13.2.0
arm allmodconfiggcc-
> On 19 Feb 2025, at 4:06 AM, Namhyung Kim wrote:
>
> Added Masami.
>
> On Wed, Feb 12, 2025 at 06:49:49PM +0530, Athira Rajeev wrote:
>> Perf probe on vfs_fstatat fails as below on a powerpc system
>>
>> ./perf probe -nf --max-probes=512 -a 'vfs_fstatat $params'
>> Segmentation fault (core
52 matches
Mail list logo
