Am 16.11.21 um 12:50 schrieb David Woodhouse:
From: David Woodhouse
Signed-off-by: David Woodhouse
Looks good.
Reviewed-by: Christian Borntraeger
---
arch/s390/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/Makefile b/arch/s390/k
On 11/16/21 8:29 PM, LEROY Christophe wrote:
> Hi
>
> Le 16/11/2021 à 05:49, Kajol Jain a écrit :
>> Patchset adds performance stats reporting support for nvdimm.
>> Added interface includes support for pmu register/unregister
>> functions. A structure is added called nvdimm_pmu to be used for
Nathan Lynch writes:
>
> Signed-off-by: Nathan Lynch
> ---
>
> Notes:
> This could be considered a sequel to:
>
>
> https://lore.kernel.org/linuxppc-dev/20210504030358.1715034-1-nath...@linux.ibm.com/
>
> which tried to address both the suboptimal delay behavior as well as
On 11/11/21 6:50 pm, Nicholas Piggin wrote:
Excerpts from Hari Bathini's message of November 11, 2021 10:06 pm:
On 11/11/21 11:44 am, Michael Ellerman wrote:
Hari Bathini writes:
In panic path, fadump is triggered via a panic notifier function.
Before calling panic notifier functions, sm
Provide API documentation for rtas_busy_delay_time(), explaining why we
return the same value for 9900 and -2.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/p
This can be considered a successor to:
https://lore.kernel.org/linuxppc-dev/20210504030358.1715034-1-nath...@linux.ibm.com/
which tried to address both the suboptimal delay behavior as well as API
issues. This version achieves the performance improvements and leaves major
API changes for another
Generally RTAS cannot block, and in PAPR it is required to return control
to the OS within a few tens of microseconds. In order to support operations
which may take longer to complete, many RTAS primitives can return
intermediate -2 ("busy") or 990x ("extended delay") values, which indicate
that th
On Fri, May 29, 2020 at 08:03:02AM -0500, Eric W. Biederman wrote:
> Luis Chamberlain writes:
>
> > The way to create a subdirectory from the base set of directories
> > is a bit obscure, so provide a helper which makes this clear, and
> > also helps remove boiler plate code required to do this w
On 16 Nov 2021, at 3:58, David Hildenbrand wrote:
> On 15.11.21 20:37, Zi Yan wrote:
>> From: Zi Yan
>>
>> Hi David,
>
> Hi,
>
> thanks for looking into this.
>
>>
>> You suggested to make alloc_contig_range() deal with pageblock_order instead
>> of
>> MAX_ORDER - 1 and get rid of MAX_ORDER - 1
Nathan Lynch writes:
> Remove the pseries scanlog driver.
>
> This code supports functions from Power4-era servers that are not present
> on targets currently supported by arch/powerpc. System manuals from this
> time have this description:
>
> Scan Dump data is a set of chip data that the servi
On 11/16/21 5:59 PM, Nick Terrell wrote:
On Nov 15, 2021, at 8:44 AM, Helge Deller wrote:
On 11/15/21 17:12, Geert Uytterhoeven wrote:
On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v5.16-rc1[1] compared to v5
allmodconfig
i386 randconfig-c001-2026
mips randconfig-c004-2026
powerpc mpc836x_rdk_defconfig
arm pxa_defconfig
powerpc mpc8313_rdb_defconfig
sh r7785rp_defconfig
allmodconfig
i386 randconfig-c001-2026
mips randconfig-c004-2026
powerpc mpc836x_rdk_defconfig
arm pxa_defconfig
powerpc mpc8313_rdb_defconfig
sh r7785rp_defconfig
s390
allmodconfig
i386 randconfig-c001-2026
mips randconfig-c004-2026
powerpc mpc836x_rdk_defconfig
arm pxa_defconfig
powerpc mpc8313_rdb_defconfig
sh r7785rp_defconfig
s390
config
arm allmodconfig
i386 randconfig-c001-2026
mips tb0287_defconfig
sh sh7724_generic_defconfig
m68k m5249evb_defconfig
x86_64 defconfig
armcerfcube_defconf
Fix the following issues reported by kernel-doc:
$ scripts/kernel-doc -v -none arch/powerpc/kernel/rtas.c
arch/powerpc/kernel/rtas.c:810: info: Scanning doc for function
rtas_activate_firmware
arch/powerpc/kernel/rtas.c:818: warning: contents before sections
arch/powerpc/kernel/rtas.c:841: info:
On 02.11.21 22:15, Joakim Tjernlund wrote:
> On Sat, 2021-10-30 at 14:20 +, Joakim Tjernlund wrote:
>> On Fri, 2021-10-29 at 17:14 +, Eugene Bordenkircher wrote:
>
>>> We've discovered a situation where the FSL udc driver
>>> (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterat
On Tue, 2021-11-16 at 18:43 +, Sean Christopherson wrote:
> On Tue, Nov 16, 2021, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > It's all fairly baroque but in the end, I don't think there's any reason
> > for $(KVM)/irqchip.o to have been handled differently, as they all end
> > up
On 11/16/21 17:58, Marc Zyngier wrote:
On Tue, 16 Nov 2021 13:40:22 +,
Cédric Le Goater wrote:
Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the
'nomap' domains still in use under the powerpc arch. With th
On Tue, 16 Nov 2021 13:40:22 +,
Cédric Le Goater wrote:
>
> Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
> exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the
> 'nomap' domains still in use under the powerpc arch. With this new
> flag, the revmap_tree of
On 11/16/21 17:07, Sean Christopherson wrote:
if (!kvm_arch_has_assigned_device(kvm) ||
!irq_remapping_cap(IRQ_POSTING_CAP) ||
- !kvm_vcpu_apicv_active(kvm->vcpus[0]))
+ !irqchip_in_kernel(kvm) || !enable_apicv)
return 0;
id
Now that the vcpu array is backed by an xarray, use the optimised
iterator that matches the underlying data structure.
Suggested-by: Sean Christopherson
Signed-off-by: Marc Zyngier
---
include/linux/kvm_host.h | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/l
Everywhere we use kvm_for_each_vpcu(), we use an int as the vcpu
index. Unfortunately, we're about to move rework the iterator,
which requires this to be upgrade to an unsigned long.
Let's bite the bullet and repaint all of it in one go.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/arch_timer
At least on arm64 and x86, the vcpus array is pretty huge (up to
1024 entries on x86) and is mostly empty in the majority of the cases
(running 1k vcpu VMs is not that common).
This mean that we end-up with a 4kB block of unused memory in the
middle of the kvm structure.
Instead of wasting away t
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Signed-off-by: Marc Zyngier
---
arch/x86/kvm/vmx/posted_intr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx/posted_intr.c b/arch/x86
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Reviewed-by: Claudio Imbrenda
Signed-off-by: Marc Zyngier
---
arch/s390/kvm/kvm-s390.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/s39
As we are about to change the way vcpus are allocated, mandate
the use of kvm_get_vcpu() instead of open-coding the access.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Marc Zyngier
---
arch/mips/kvm/loongson_ipi.c | 4 ++--
arch/mips/kvm/mips.c | 2 +-
2 files changed, 3 insertio
All architectures have similar loops iterating over the vcpus,
freeing one vcpu at a time, and eventually wiping the reference
off the vcpus array. They are also inconsistently taking
the kvm->lock mutex when wiping the references from the array.
Make this code common, which will simplify further
The kvm structure is pretty large. A large portion of it is the vcpu
array, which is 4kB on arm64 with 512 vcpu, double that on x86-64. Of
course, hardly anyone runs VMs this big, so this is often a net waste
of memory and cache locality.
A possible approach is to turn the fixed-size array into a
On Tue, 16 Nov 2021 15:03:40 +,
Paolo Bonzini wrote:
>
> On 11/5/21 20:20, Marc Zyngier wrote:
> > The kvm structure is pretty large. A large portion of it is the vcpu
> > array, which is 4kB on x86_64 and arm64 as they deal with 512 vcpu
> > VMs. Of course, hardly anyone runs VMs this big, s
Hi Masahiro,
Le 09/11/2021 à 19:50, Masahiro Yamada a écrit :
Since commit bce74491c300 ("powerpc/vdso: fix unnecessary rebuilds of
vgettimeofday.o"), "make ARCH=powerpc clean" does not clean up the
arch/powerpc/kernel/{vdso32,vdso64} directories.
Use the subdir- trick to let "make clean" desce
Hi Kees,
Le 16/10/2021 à 08:42, Christophe Leroy a écrit :
Le 15/10/2021 à 23:31, Kees Cook a écrit :
On Thu, Oct 14, 2021 at 07:50:01AM +0200, Christophe Leroy wrote:
execute_location() and execute_user_location() intent
to copy do_nothing() text and execute it at a new location.
However, a
On 11/5/21 20:20, Marc Zyngier wrote:
The kvm structure is pretty large. A large portion of it is the vcpu
array, which is 4kB on x86_64 and arm64 as they deal with 512 vcpu
VMs. Of course, hardly anyone runs VMs this big, so this is often a
net waste of memory and cache locality.
A possible app
Hi
Le 16/11/2021 à 05:49, Kajol Jain a écrit :
> Patchset adds performance stats reporting support for nvdimm.
> Added interface includes support for pmu register/unregister
> functions. A structure is added called nvdimm_pmu to be used for
> adding arch/platform specific data such as cpumask, nvd
On 11/16/21 15:23, Greg Kurz wrote:
On Tue, 16 Nov 2021 14:40:22 +0100
Cédric Le Goater wrote:
Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the
'nomap' domains still in use under the powerpc arch. With this n
On Tue, 16 Nov 2021 15:49:13 +0100
Cédric Le Goater wrote:
> On 11/16/21 15:23, Greg Kurz wrote:
> > On Tue, 16 Nov 2021 14:40:22 +0100
> > Cédric Le Goater wrote:
> >
> >> Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
> >> exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP fl
On Tue, 16 Nov 2021 14:40:22 +0100
Cédric Le Goater wrote:
> Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
> exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the
> 'nomap' domains still in use under the powerpc arch. With this new
> flag, the revmap_tree of the
On 11/16/21 15:13, Juergen Gross wrote:
On 05.11.21 20:20, Marc Zyngier wrote:
The kvm structure is pretty large. A large portion of it is the vcpu
array, which is 4kB on x86_64 and arm64 as they deal with 512 vcpu
VMs. Of course, hardly anyone runs VMs this big, so this is often a
net waste of
On 11/5/21 21:03, Sean Christopherson wrote:
But I think even that is flawed, as APICv can be dynamically deactivated and
re-activated while the VM is running, and I don't see a path that re-updates
the IRTE when APICv is re-activated. So I think a more conservative check is
needed, e.g.
diff -
On 11/6/21 12:17, Marc Zyngier wrote:
If you too believe that this is just wrong, I'm happy to drop the
locking altogether. If that breaks someone's flow, they'll shout soon
enough.
Yes, it's not necessary. It was added in 2009 (commit 988a2cae6a3c,
"KVM: Use macro to iterate over vcpus.") a
Le 10/11/2021 à 21:24, Valentin Schneider a écrit :
Per PREEMPT_DYNAMIC, checking CONFIG_PREEMPT doesn't tell you the actual
preemption model of the live kernel. Use the newly-introduced accessors
instead.
Is that change worth it for now ? As far as I can see powerpc doesn't
have DYNAMIC PR
Commit 4f86a06e2d6e ("irqdomain: Make normal and nomap irqdomains
exclusive") introduced an IRQ_DOMAIN_FLAG_NO_MAP flag to isolate the
'nomap' domains still in use under the powerpc arch. With this new
flag, the revmap_tree of the IRQ domain is not used anymore. This
change broke the support of sha
Le 10/11/2021 à 21:24, Valentin Schneider a écrit :
CONFIG_PREEMPT{_NONE, _VOLUNTARY} designate either:
o The build-time preemption model when !PREEMPT_DYNAMIC
o The default boot-time preemption model when PREEMPT_DYNAMIC
IOW, using those on PREEMPT_DYNAMIC kernels is meaningless - the actual
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/mips/kvm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index d3710959da55..21ff75bcdbc4 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm/Makefile
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/riscv/kvm/Makefile | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/riscv/kvm/Makefile b/arch/riscv/kvm/Makefile
index 30cdd1df0098..300590225348 100644
--- a/arch/riscv/kvm/Makefile
+++ b/arch/riscv/kvm/
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/s390/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/s390/kvm/Makefile b/arch/s390/kvm/Makefile
index b3aaadc60ead..e4f50453cf7f 100644
--- a/arch/s390/kvm/Makefile
+++ b/arch/s390/kvm/Make
From: David Woodhouse
Signed-off-by: David Woodhouse
---
arch/arm64/kvm/Makefile | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index 989bb5dad2c8..04a53f71a6b6 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm
From: David Woodhouse
Splitting kvm_main.c out into smaller and better-organized files is
slightly non-trivial when it involves editing a bunch of per-arch
KVM makefiles. Provide virt/kvm/Makefile.kvm for them to include.
Signed-off-by: David Woodhouse
---
arch/x86/kvm/Makefile | 7 +--
v
From: David Woodhouse
It's all fairly baroque but in the end, I don't think there's any reason
for $(KVM)/irqchip.o to have been handled differently, as they all end
up in $(kvm-y) in the end anyway, regardless of whether they get there
via $(common-objs-y) and the CPU-specific object lists.
The
From: David Woodhouse
I'd like to make the build include dirty_ring.c based on whether the
arch wants it or not. That's a whole lot simpler if there's a config
symbol instead of doing it implicitly on KVM_DIRTY_LOG_PAGE_OFFSET
being set to something non-zero.
Signed-off-by: David Woodhouse
---
On Mon, 2021-11-15 at 20:26 +0100, Paolo Bonzini wrote:
> > > Also, for the small requests: since you are at it, can you add the code
> > > in a new file under virt/kvm/?
> >
> > Hm... only if I can make hva_to_pfn() and probably a handful of other
> > things non-static?
>
> Yes, I think sooner or
Hello Marc,
This patch is breaking the POWER9/POWER10 XIVE driver (these are not
old PPC systems :) on machines sharing the same LSI HW IRQ. For instance,
a linux KVM guest with a virtio-rng and a virtio-balloon device. In that
case, Linux creates two distinct IRQ mappings which can lead to some
On Mon, Nov 15, 2021 at 05:12:50PM +0100, Geert Uytterhoeven wrote:
> > + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko]
> > undefined!: => N/A
> > + error: modpost: "mips_cm_lock_other"
> > [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
> > + error: mo
On Mon, Nov 15, 2021 at 06:53:53PM -0500, Nayna wrote:
>
> On 11/12/21 03:30, Michal Suchánek wrote:
> > Hello,
> >
> > On Thu, Nov 11, 2021 at 05:26:41PM -0500, Nayna wrote:
> > > On 11/8/21 07:05, Michal Suchánek wrote:
> > > > Hello,
> > > >
> > > > The other part is that distributions apply
On Mon, Nov 15, 2021 at 10:24:36PM +, Leo Li wrote:
> > From: Andy Shevchenko
> > Sent: Monday, November 15, 2021 5:30 AM
> > On Wed, Nov 10, 2021 at 12:59:52PM +0200, Andy Shevchenko wrote:
...
> > > v2: updated Cc list based on previous changes to MAINTAINERS
> >
> > Any comments on this,
On 15.11.21 20:37, Zi Yan wrote:
> From: Zi Yan
>
> Hi David,
Hi,
thanks for looking into this.
>
> You suggested to make alloc_contig_range() deal with pageblock_order instead
> of
> MAX_ORDER - 1 and get rid of MAX_ORDER - 1 dependency in virtio_mem[1]. This
> patchset is my attempt to ach
On Mon, 15 Nov 2021 19:05:17 +,
Cédric Le Goater wrote:
>
> Hello Mark,
s/k/c/
>
> On 5/20/21 18:37, Marc Zyngier wrote:
> > Direct mappings are completely exclusive of normal mappings, meaning
> > that we can refactor the code slightly so that we can get rid of
> > the revmap_direct_max_i
57 matches
Mail list logo
