On 8/1/24 01:44, Arnaldo Carvalho de Melo wrote:
> On Wed, Jul 31, 2024 at 04:44:49PM -0300, Arnaldo Carvalho de Melo wrote:
>> On Fri, Jul 26, 2024 at 11:08:55AM -0300, Arnaldo Carvalho de Melo wrote:
>>> On Tue, Jul 23, 2024 at 09:02:23AM -0700, Ian Rogers wrote:
On Mon, Jul 22, 2024 at 1
Sean Christopherson writes:
> Disallow copying MTE tags to guest memory while KVM is dirty logging, as
> writing guest memory without marking the gfn as dirty in the memslot could
> result in userspace failing to migrate the updated page. Ideally (maybe?),
> KVM would simply mark the gfn as dirt
Hello Baoquan,
On 01/08/24 13:13, Baoquan He wrote:
On 07/31/24 at 08:57pm, Sourabh Jain wrote:
The following errors are observed when kexec is done with SMT=off on
powerpc.
[ 358.458385] Removing IBM Power 842 compression device
[ 374.795734] kexec_core: Starting new kernel
[ 374.795748] k
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use direct phys_addr_t limit address for DMA zone limit.
Current code using zone_dma_bits assume that al
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB.
When device DMA limit does not fit in DMA32 zone it should use DMA zone,
even when DMA zone is stricter than needed.
Same goes for devices that can't allocate from the entire normal zone.
Limit to DMA32 in that case.
Reported-by: Catalin Marinas
Signed-off-by: Baruch Siach
---
kernel/dma/direc
On Thu, Aug 01, 2024 at 11:25:06AM +0300, Baruch Siach wrote:
> When device DMA limit does not fit in DMA32 zone it should use DMA zone,
> even when DMA zone is stricter than needed.
>
> Same goes for devices that can't allocate from the entire normal zone.
> Limit to DMA32 in that case.
>
> Repo
Sean Christopherson writes:
> Remove KVM_ERR_PTR_BAD_PAGE and instead return NULL, as "bad page" is just
> a leftover bit of weirdness from days of old when KVM stuffed a "bad" page
> into the guest instead of actually handling missing pages. See commit
> cea7bb21280e ("KVM: MMU: Make gfn_to_pag
Sean Christopherson writes:
> Allow passing a NULL @page to kvm_release_page_{clean,dirty}(), there's no
> tangible benefit to forcing the callers to pre-check @page, and it ends up
> generating a lot of duplicate boilerplate code.
>
> Signed-off-by: Sean Christopherson
Reviewed-by: Alex Bennée
Sean Christopherson writes:
> Add an API to release an unused page, i.e. to put a page without marking
> it accessed or dirty. The API will be used when KVM faults-in a page but
> bails before installing the guest mapping (and other similar flows).
>
> Signed-off-by: Sean Christopherson
> ---
>
Sean Christopherson writes:
> Drop @atomic from the myriad "to_pfn" APIs now that all callers pass
> "false".
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Sean Christopherson writes:
> Use a single pointer instead of a single-entry array for the struct page
> pointer in hva_to_pfn_fast(). Using an array makes the code unnecessarily
> annoying to read and update.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson
Reviewed-b
Sean Christopherson writes:
> Hoist the kvm_{set,release}_page_{clean,dirty}() APIs further up in
> kvm_main.c so that they can be used by the kvm_follow_pfn family of APIs.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson
Reviewed-by: Alex Bennée
--
Alex Bennée
Virt
+ Steven Price for this patch (and the following one), as this really
is his turf.
On Sat, 27 Jul 2024 00:51:10 +0100,
Sean Christopherson wrote:
>
> Put the page reference acquired by gfn_to_pfn_prot() if
> kvm_vm_ioctl_mte_copy_tags() runs into ZONE_DEVICE memory. KVM's less-
> than-stellar h
On Thu, Aug 01, 2024 at 11:25:07AM +0300, Baruch Siach wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9b5ab6818f7f..c45e2152ca9e 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -115,35 +115,35 @@ static void __init arch_reserve_crashkernel(void)
> }
On Thu, Aug 01, 2024 at 11:25:07AM +0300, Baruch Siach wrote:
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index d10613eb0f63..a6e15db9d1e7 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -70,9 +70,10 @@ static bool cma_in_zone(gfp_t gfp)
> /* CMA can't cross zone bo
On Thu, Jul 25, 2024 at 04:49:50PM +0100, Dave Martin wrote:
> On Fri, May 03, 2024 at 02:01:31PM +0100, Joey Gouly wrote:
> > Modify arch_calc_vm_prot_bits() and vm_get_page_prot() such that the pkey
> > value is set in the vm_flags and then into the pgprot value.
> >
> > Signed-off-by: Joey Goul
On Thu, Aug 01, 2024 at 11:55:02AM +0100, Joey Gouly wrote:
> On Thu, Jul 25, 2024 at 04:49:50PM +0100, Dave Martin wrote:
> > On Fri, May 03, 2024 at 02:01:31PM +0100, Joey Gouly wrote:
> > > Modify arch_calc_vm_prot_bits() and vm_get_page_prot() such that the pkey
> > > value is set in the vm_fla
Ok, I guess this is what Robin was referring to.
A midlayer like SCSI really shouldn't directly call dma layer
functions without knowing that the underlying bus is DMA capable.
I'll see what I can do about it, and in the meantime drop this patch
and the companion from the dma-mapping tree.
On Wed, Jul 31, 2024 at 06:24:24PM -0700, Nathan Chancellor wrote:
> Unfortunately, I am not sure either... I do not see anything obviously,
> so perhaps it could just be avoided with the __diag() infrastructure?
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 3dbc0b89d6fb..b58e
On Thu, Aug 01, 2024, Alex Bennée wrote:
> Sean Christopherson writes:
>
> > Add an API to release an unused page, i.e. to put a page without marking
> > it accessed or dirty. The API will be used when KVM faults-in a page but
> > bails before installing the guest mapping (and other similar flow
On Thu, Aug 01, 2024 at 01:03:44PM +0530, kajoljain wrote:
>
>
> On 8/1/24 01:44, Arnaldo Carvalho de Melo wrote:
> > On Wed, Jul 31, 2024 at 04:44:49PM -0300, Arnaldo Carvalho de Melo wrote:
> >> On Fri, Jul 26, 2024 at 11:08:55AM -0300, Arnaldo Carvalho de Melo wrote:
> >>> On Tue, Jul 23, 2024
On Thu, Aug 01, 2024 at 03:44:54PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 31, 2024 at 06:24:24PM -0700, Nathan Chancellor wrote:
> > Unfortunately, I am not sure either... I do not see anything obviously,
> > so perhaps it could just be avoided with the __diag() infrastructure?
> >
> > diff
Convert dt-binding rcpm from txt to yaml format.
Add fsl,ls1028a-rcpm compatible string.
Additional changes:
- Add missed compatible string fsl,-rcpm.
- Remove map fsl,-rcpm to fsl,qoriq-rcpm-.
Signed-off-by: Frank Li
---
Chagne from v2 to v3
- fallback use const
- order as fallback compatible s
On Thu, 01 Aug 2024 07:14:01 +0200, Pawel Dembicki wrote:
> P2020RDB contains multiple peripherals, which isn't added to
> devicetree:
> - Switch: Microchip VSC7385
> - PMIC: Renesas ZL2006
> - Temperature sensor: Analog Devices ADT7461
> - Two eeproms: 24C256 and 24C01
> - GPIO expande
On Thu, Jul 25, 2024 at 05:00:18PM +0100, Dave Martin wrote:
> Hi,
>
> On Fri, May 03, 2024 at 02:01:36PM +0100, Joey Gouly wrote:
> > Add PKEY support to signals, by saving and restoring POR_EL0 from the
> > stackframe.
> >
> > Signed-off-by: Joey Gouly
> > Cc: Catalin Marinas
> > Cc: Will De
On Thu, Jul 25, 2024 at 04:57:09PM +0100, Dave Martin wrote:
> On Fri, May 03, 2024 at 02:01:33PM +0100, Joey Gouly wrote:
> > If a memory fault occurs that is due to an overlay/pkey fault, report that
> > to
> > userspace with a SEGV_PKUERR.
> >
> > Signed-off-by: Joey Gouly
> > Cc: Catalin Mar
On Thu, Jul 25, 2024 at 04:49:08PM +0100, Dave Martin wrote:
> On Fri, May 03, 2024 at 02:01:28PM +0100, Joey Gouly wrote:
> > Expose a HWCAP and ID_AA64MMFR3_EL1_S1POE to userspace, so they can be used
> > to
> > check if the CPU supports the feature.
> >
> > Signed-off-by: Joey Gouly
> > Cc: C
On Wed, Jul 31, 2024 at 11:14 PM Pawel Dembicki wrote:
>
On the subject, every patch is an 'update'. Please make it more
specific. If you have a hard time coming up with something specific,
that's a sign your patch is making too many separate changes.
> P2020RDB contains multiple peripherals, wh
On Thu, Aug 01, 2024 at 04:54:41PM +0100, Joey Gouly wrote:
> On Thu, Jul 25, 2024 at 05:00:18PM +0100, Dave Martin wrote:
> > Hi,
> >
> > On Fri, May 03, 2024 at 02:01:36PM +0100, Joey Gouly wrote:
> > > Add PKEY support to signals, by saving and restoring POR_EL0 from the
> > > stackframe.
> >
On Thu, Aug 01, 2024 at 05:04:03PM +0100, Joey Gouly wrote:
> On Thu, Jul 25, 2024 at 04:49:08PM +0100, Dave Martin wrote:
> > On Fri, May 03, 2024 at 02:01:28PM +0100, Joey Gouly wrote:
> > > Expose a HWCAP and ID_AA64MMFR3_EL1_S1POE to userspace, so they can be
> > > used to
> > > check if the C
On Thu, 1 Aug 2024 09:08:02 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> sgi-ip27 is the only system that defines NODE_DATA() differently than
> the rest of NUMA machines.
>
> Add node_data array of struct pglist pointers that will point to
> __node_data[node]->pglist an
On Thu, 1 Aug 2024 09:08:03 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> For SGI IP27 machines node_possible_map is statically set to
> NODE_MASK_ALL and it is not updated during NUMA initialization.
>
> Ensure that it only contains nodes present in the system.
>
> Sign
On Thu, 1 Aug 2024 09:08:04 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Commit f8f9f21c7848 ("MIPS: Fix build error for loongson64 and
> sgi-ip27") added HAVE_ARCH_NODEDATA_EXTENSION to sgi-ip27 to silence a
> compilation error that happened because sgi-ip27 didn't defin
On Thu, 1 Aug 2024 09:08:06 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Commit f8f9f21c7848 ("MIPS: Fix build error for loongson64 and
> sgi-ip27") added HAVE_ARCH_NODEDATA_EXTENSION to loongson64 to silence a
> compilation error that happened because loongson64 didn't d
On Thu, Aug 01, 2024, Aneesh Kumar K.V wrote:
> Sean Christopherson writes:
>
> > Disallow copying MTE tags to guest memory while KVM is dirty logging, as
> > writing guest memory without marking the gfn as dirty in the memslot could
> > result in userspace failing to migrate the updated page. I
On Mon Jul 29, 2024 at 4:29 PM EEST, Stefan Berger wrote:
> Commit d2add27cf2b8 ("tpm: Add NULL primary creation") introduced
> CONFIG_TCG_TPM2_HMAC. When this option is enabled on ppc64 then the
> following message appears in the kernel log due to a missing call to
> tpm2_sessions_init().
>
> [
RESERVEDMEM_OF_DECLARE usage has been removed. For
non-popwerpc platforms, such as ls1043, this warning
is redundant. ls1043 itself uses shared-dma-mem.
Fixes: 3e62273ac63a ("soc: fsl: qbman: Remove RESERVEDMEM_OF_DECLARE usage")
Signed-off-by: Xiaolei Wang
---
drivers/soc/fsl/qbman/qman_ccsr.c
Hi all,
As more and more sites are using DKIM signing or emails (and DMARC),
more and more of the list traffic is not being delivered due to Mailman
altering messages in subtle ways (so the DKIM signature is no longer
valid). The easiest thing to do is to tell Mailman to munge the From:
address s
Hi all
On Fri, 2 Aug 2024 13:03:47 +1000 Stephen Rothwell
wrote:
>
> As more and more sites are using DKIM signing or emails (and DMARC),
> more and more of the list traffic is not being delivered due to Mailman
> altering messages in subtle ways (so the DKIM signature is no longer
> valid). Th
From: Catalin Marinas
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use plain address for DMA zone limit.
Since DMA zone can now potentially span beyond 4GB physical limit
When device DMA limit does not fit in DMA32 zone it should use DMA zone,
even when DMA zone is stricter than needed.
Same goes for devices that can't allocate from the entire normal zone.
Limit to DMA32 in that case.
Reported-by: Catalin Marinas
Reviewed-by: Catalin Marinas
Signed-off-by: Baruc
From: Catalin Marinas
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made arm64 DMA/DMA32 zones span the entire
RAM when RAM starts above 32-bits. This breaks hardware with DMA area
that start above 32-bits. But the commit log says that "we haven't
notice
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB.
44 matches
Mail list logo
