Le 20/07/2025 à 00:43, Ruben Wauters a écrit :
[Vous ne recevez pas souvent de courriers de rubenr...@aol.com. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
The calculations for operand/opcode/macro numbers are done in an
identical manner to the alre
15.1.0
arc allmodconfiggcc-15.1.0
arc allnoconfiggcc-15.1.0
arc allyesconfiggcc-15.1.0
arc defconfiggcc-15.1.0
arc randconfig-001-20250729gcc-8.5.0
arc rand
The pull request you sent on Tue, 29 Jul 2025 08:18:45 +0530:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-6.17-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5f5c9952b33cb4e8d25c70ef29f7a45cd26b6a9b
Thank you!
--
Deet-doot-d
On Tue, 2025-07-29 at 10:42 -0700, Sean Christopherson wrote:
> Extend KVM's export macro framework to provide EXPORT_SYMBOL_GPL_FOR_KVM(),
> and use the helper macro to export symbols for KVM throughout x86 if and
> only if KVM will build one or more modules, and only for those modules.
>
> To av
在 2025/7/29 21:48, Breno Leitao 写道:
On Mon, Jul 28, 2025 at 09:08:25AM +0800, Shuai Xue wrote:
在 2025/7/26 00:16, Breno Leitao 写道:
On Fri, Jul 25, 2025 at 03:40:58PM +0800, Shuai Xue wrote:
enum hwerr_error_type {
HWERR_RECOV_MCE, // maps to errors in do_machine_
Hi all,
After merging the jc_docs tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/arch/powerpc/index.rst:7: WARNING: duplicated entry found in
toctree: arch/powerpc/htm
Introduced by commit
c361f76da696 ("docs: powerpc: Add htm.rst to table of contents")
inter
On Tue, Jul 29, 2025 at 06:25:39AM +0100, Lorenzo Stoakes wrote:
> Andrew - FYI there's nothing to worry about here, the type remains
> precisely the same, and I'll send a patch to fix this trivial issue so when
> later this type changes vmalloc will be uaffected.
>
> On Tue, Jul 29, 2025 at 09:15
Extend KVM's export macro framework to provide EXPORT_SYMBOL_GPL_FOR_KVM(),
and use the helper macro to export symbols for KVM throughout x86 if and
only if KVM will build one or more modules, and only for those modules.
To avoid unnecessary exports when CONFIG_KVM=m but kvm.ko will not be
built (
Rework almost all of KVM x86's exports to expose symbols only to KVM's
vendor modules, i.e. to kvm-{amd,intel}.ko. Keep the generic exports that
are guarded by CONFIG_KVM_EXTERNAL_WRITE_TRACKING=y, as they're explicitly
designed/intended for external usage.
Signed-off-by: Sean Christopherson
---
Drop the exporting of several kvm_arch_xxx() hooks that are only called
from arch-neutral code, i.e. that are only called from kvm.ko.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/x86.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a1c
Move kvm_intr_is_single_vcpu() to lapic.c, drop its export, and make its
"fast" helper local to lapic.c. kvm_intr_is_single_vcpu() is only usable
if the local APIC is in-kernel, i.e. it most definitely belongs in the
local APIC code.
No functional change intended.
Fixes: 2f5fb6b965b3 ("KVM: x86:
Rework the vast majority of KVM's exports to expose symbols only to KVM
submodules, i.e. to x86's kvm-{amd,intel}.ko and PPC's kvm-{pr,hv}.ko.
With few exceptions, KVM's exported APIs are intended (and safe) for KVM-
internal usage only.
Keep kvm_get_kvm(), kvm_get_kvm_safe(), and kvm_put_kvm() as
Use the newfangled EXPORT_SYMBOL_GPL_FOR_MODULES() along with some macro
shenanigans to export KVM-internal symbols if and only if KVM has one or
more sub-modules, and only for those sub-modules, e.g. x86's kvm-amd.ko
and/or kvm-intel.ko.
Patch 5 gives KVM x86 the full treatment. If anyone wants
Use kvm_is_gpa_in_memslot() to check the validity of the notification
indicator byte address instead of open coding equivalent logic in the VFIO
AP driver.
Opportunistically use a dedicated wrapper that exists and is exported
expressly for the VFIO AP module. kvm_is_gpa_in_memslot() is generally
On Fri, Jul 25, 2025 at 09:05:46PM +0100, Robin Murphy wrote:
> But given what we do already know of from decades of experience, obvious
> question: For the tiny minority of users who know full well when they're
> dealing with a non-page-backed physical address, what's wrong with using
> dma_map_r
On Mon, Jul 28, 2025 at 09:08:25AM +0800, Shuai Xue wrote:
> 在 2025/7/26 00:16, Breno Leitao 写道:
> > On Fri, Jul 25, 2025 at 03:40:58PM +0800, Shuai Xue wrote:
> >
> > enum hwerr_error_type {
> > HWERR_RECOV_MCE, // maps to errors in do_machine_check()
> > HWERR_REC
Greetings!!!
Tested this patch by applying on 6.16 kernel. Build and boot was fine.
Assigned the LPAR to different RG, and with this patch, RG Index and
active_procs in RG reported the correct information. Hence,
Tested-by: Venkat Rao Bagalkote
Regards,
Venkat.
Hi Christophe,
On Tue, 29 Jul 2025 07:41:40 + LEROY Christophe
wrote:
>
> If I remember correctly you maintain the Ozlabs patchwork aren't you ?
Actually Jeremy Kerr (cc'd) actually manages patchwork on
patchwork.ozlabs.org (I just admin the server it runs on).
> For more than one year now
Hi Stephen,
If I remember correctly you maintain the Ozlabs patchwork aren't you ?
For more than one year now, patchwork for linuxppc-dev hasn't sent
notifications about patches status changes. Last notification I received
was 11 June 2024.
Is there a reason for that change ? I recently got qu
19 matches
Mail list logo
