On Tue Mar 28, 2023 at 3:46 AM AEST, Christophe Leroy wrote:
>
>
> Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
> > The _switch stack frame setup are substantially the same, so are the
> > comments. The difference in how the stack and current are switched,
> > and other hardware and software
Hi,
On 2023-03-23 03:47:18, Kautuk Consul wrote:
> kvmppc_vcore_create() might not be able to allocate memory through
> kzalloc. In that case the kvm->arch.online_vcores shouldn't be
> incremented.
> Add a check for kzalloc failure and return with -ENOMEM from
> kvmppc_core_vcpu_create_hv().
On Fri, Mar 24, 2023 at 09:17:38AM +, Jiaxun Yang wrote:
> >
> > Is patch a 6.3 candidate or should all of it go into 6.4?
>
> Please leave it for 6.4, as corresponding MIPS arch part will be a part of
> 6.4.
Ok. I'll really need review from the MIPS and drivers/of/ maintainers,
through.
Replace of_get_property()+of_translate_address()+ioremap() with a call
to of_iomap() which does all those steps.
Signed-off-by: Rob Herring
---
.../platforms/embedded6xx/usbgecko_udbg.c | 20 +--
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git
Replace of_address_to_resource()+ioremap() with a call to of_iomap()
which does both of those steps.
Signed-off-by: Rob Herring
---
arch/powerpc/sysdev/fsl_rio.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c
icp_native_init_one_node() only needs the number of entries in "reg".
Replace the open coded "reg" parsing with of_address_count() to get the
number of "reg" entries.
Signed-off-by: Rob Herring
---
arch/powerpc/sysdev/xics/icp-native.c | 17 +
1 file changed, 5 insertions(+), 12
"ranges" is a standard property with common parsing functions. Users
shouldn't be implementing their own parsing of it. Reimplement the
ISA brige "ranges" parsing using the common ranges iterator functions.
The common routines are flexible enough to work on PCI and non-PCI to
ISA bridges, so
> +static inline void arch_dma_cache_wback(phys_addr_t paddr, size_t size)
> {
> + dma_cache_wback(paddr, size);
> +}
>
> +static inline void arch_dma_cache_inv(phys_addr_t paddr, size_t size)
> +{
> + dma_cache_inv(paddr, size);
> }
> +static inline void
>> Can the queueing cause the creation of an IO thread (if one does not
>> exist, or all blocked?)
>
> Yep
>
> Since writing this email, I've gone through a lot of different tests.
> Here's a rough listing of what I found:
>
> - Like using the hack patch, if I just limit the number of IO
Replace open coded reading of "reg" or of_get_address()/
of_translate_address() calls with a single call to
of_address_to_resource().
Signed-off-by: Rob Herring
---
v2:
- Fix compile in tsi108_dev.c
---
arch/powerpc/mm/numa.c| 21 +++--
On 3/27/23 14:15, Sean Anderson wrote:
> On 3/24/23 09:17, Ioana Ciornei wrote:
>> On Tue, Mar 21, 2023 at 04:13:12PM -0400, Sean Anderson wrote:
>>> This adds serdes support to the LS1088ARDB. I have tested the QSGMII
>>> ports as well as the two 10G ports. The SFP slot is now fully supported,
On 3/27/23 14:45, Nicholas Piggin wrote:
This is a basic first pass at powernv support using OPAL (skiboot)
firmware.
The ACCEL is a bit clunky, defaulting to kvm for powernv machine, which
isn't right and has to be manually overridden. It also does not yet run
in the run_tests.sh batch
cgr_lock may be locked with interrupts already disabled by
smp_call_function_single. As such, we must use a raw spinlock to avoid
problems on PREEMPT_RT kernels. Although this bug has existed for a
while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust
queue depth on rate
smp_call_function_single disables IRQs when executing the callback. To
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
This is already done by qman_update_cgr and qman_delete_cgr; fix the
other lockers.
Fixes: c535e923bb97 ("soc/fsl: Introduce DPAA 1.x QMan device driver")
On 3/24/23 09:17, Ioana Ciornei wrote:
> On Tue, Mar 21, 2023 at 04:13:12PM -0400, Sean Anderson wrote:
>> This adds serdes support to the LS1088ARDB. I have tested the QSGMII
>> ports as well as the two 10G ports. The SFP slot is now fully supported,
>> instead of being modeled as a fixed-link.
Commit c93bd175414a ("powerpc/fsl: move to use bus_get_dev_root()")
changed to use bus_get_dev_root() but didn't consider that the function
can fail and return an uninitialized value of ret (hint, the function
can never fail, but the compiler doesn't know that.)
Fix this up by setting ret to
Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
> This file contains only the enter_prom implementation now.
> Trim includes and update header comment while we're here.
>
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/kernel/Makefile | 8 +++--
>
Le 25/03/2023 à 14:06, Nicholas Piggin a écrit :
> The _switch stack frame setup are substantially the same, so are the
> comments. The difference in how the stack and current are switched,
> and other hardware and software housekeeping is done is moved into
> macros.
>
> Signed-off-by:
On Mon, Mar 27, 2023, Nicholas Piggin wrote:
> On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote:
> > On Thu, Mar 16, 2023, Michael Ellerman wrote:
> > > Nicholas Piggin writes:
> > > > Hi,
> > > >
> > > > This series adds initial KVM selftests support for powerpc
> > > > (64-bit,
On Mon, Mar 13, 2023 at 5:26 AM Viresh Kumar wrote:
>
> On 10-03-23, 08:47, Rob Herring wrote:
> > It is preferred to use typed property access functions (i.e.
> > of_property_read_ functions) rather than low-level
> > of_get_property/of_find_property functions for reading properties.
> > Convert
On Wed, 15 Mar 2023 16:20:53 -0700, Ira Weiny wrote:
> Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
> callbacks") removed the calls to memcpy_page_flushcache().
>
> kmap_atomic() is deprecated and used in the x86 version of
> memcpy_page_flushcache().
>
> Remove the
On 3/27/23 7:54?AM, Michael Ellerman wrote:
> "Nicholas Piggin" writes:
>> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>>> from my (arguably very short) checking is not commonly done for other
>>> archs. This is
On 3/27/23 14:45, Nicholas Piggin wrote:
This series is growing a bit I'm sorry. v2 series added extra interrupt
vectors support which was actually wrong because interrupt handling
code can only cope with 0x100-size vectors and new ones are 0x80 and
0x20. It managed to work because those alias
On Sat, Mar 25, 2023 at 09:45:37AM +0100, Greg Kroah-Hartman wrote:
> struct class should never be modified in a sysfs callback as there is
> nothing in the structure to modify, and frankly, the structure is almost
> never used in a sysfs callback, so mark it as constant to allow struct
> class to
On Mon, Mar 27, 2023 at 5:14 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> xtensa is one of the platforms that has both write-back and write-through
> caches, and needs to account for both in its DMA mapping operations.
>
> It does this through a set of operations that is different from
On Mon, Mar 27, 2023 at 02:13:16PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The arm version of the arch_sync_dma_for_cpu() function annotates pages as
> PG_dcache_clean after a DMA, but no other architecture does this here.
... because this is an arm32 specific feature.
On 27/03/2023 14.45, Nicholas Piggin wrote:
Check to ensure exception handlers are not being overwritten or
invalid exception numbers are used.
Signed-off-by: Nicholas Piggin
---
Since v2:
- New patch
lib/powerpc/processor.c | 12
1 file changed, 12 insertions(+)
diff --git
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 011eb7443621f49ca1e8cdf9c74c215f25019118 Add linux-next specific
files for 20230327
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202303082135.njdx1bij-...@intel.com
https
"Nicholas Piggin" writes:
> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, except when PF_IO_WORKER's have been
Jens Axboe writes:
> On 3/24/23 6:42?PM, Michael Ellerman wrote:
>> Jens Axboe writes:
>>> I got a report sent to me from mariadb, in where 5.10.158 works fine and
>>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test
>>> case. Beware that this email is long, as I'm trying to
On Mon, Mar 27, 2023 at 8:15 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> csky is the only architecture that does a full flush for the
> dma_sync_*_for_device(..., DMA_FROM_DEVICE) operation. The requirement
> is only make sure there are no dirty cache lines for the buffer,
> which can be
On Mon, Mar 27, 2023 at 02:13:12PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> These were remove ages ago in commit 702b94bff3c5 ("ARM: dma-mapping:
> remove dmac_clean_range and dmac_inv_range") in an effort to sanitize
> the dma-mapping API.
Really no, please no. Let's not go back
On Mon, Mar 27, 2023, at 14:56, Christophe Leroy wrote:
> Le 27/03/2023 à 14:13, Arnd Bergmann a écrit :
>> From: Arnd Bergmann
>>
>> The powerpc dma_sync_*_for_cpu() variants do more flushes than on other
>> architectures. Reduce it to what everyone else does:
>>
>> - No flush is needed
Le 27/03/2023 à 14:13, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> The powerpc dma_sync_*_for_cpu() variants do more flushes than on other
> architectures. Reduce it to what everyone else does:
>
> - No flush is needed after data has been sent to a device
>
> - When data has been
On 2023-03-27 13:13, Arnd Bergmann wrote:
From: Arnd Bergmann
The arm version of the arch_sync_dma_for_cpu() function annotates pages as
PG_dcache_clean after a DMA, but no other architecture does this here. On
ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
to use
This enables HV privilege registers to be tested with the powernv
machine.
Acked-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
powerpc/sprs.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/powerpc/sprs.c b/powerpc/sprs.c
index
This is a basic first pass at powernv support using OPAL (skiboot)
firmware.
The ACCEL is a bit clunky, defaulting to kvm for powernv machine, which
isn't right and has to be manually overridden. It also does not yet run
in the run_tests.sh batch process, more work is needed to exclude
certain
The next change will load the kernels at different addresses depending
on test options, so this needs to be reverted back to dynamic
discovery.
Signed-off-by: Nicholas Piggin
---
powerpc/cstart64.S | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git
Interrupt vectors were not being populated for all architected
interrupt types, which could lead to crashes rather than a message for
unhandled interrupts.
0x20 sized vectors require some reworking of the code to fit. This
also adds support for HV / HSRR type interrupts which will be used in
a
Exception handlers are currently indexed in units of 0x100, but
powerpc can have vectors that are aligned to as little as 0x20
bytes. Increase granularity of the handler functions before
adding support for thse vectors.
Signed-off-by: Nicholas Piggin
---
Since v2:
- New patch
The VPA is an optional memory structure shared between the hypervisor
and operating system, defined by PAPR. This test defines the structure
and adds registration, deregistration, and a few simple sanity tests.
[Thanks to Thomas Huth for suggesting many of the test cases.]
Signed-off-by: Nicholas
A significant rework that builds an array of 'struct spr', where each
element describes an SPR. This makes various metadata about the SPR
like name and access type easier to carry and use.
Hypervisor privileged registers are described despite not being used
at the moment for completeness, but
Move some common helpers and defines to processor.h.
Signed-off-by: Nicholas Piggin
---
Since v2:
- New patch
lib/powerpc/asm/processor.h | 38 +
powerpc/spapr_hcall.c | 9 +
powerpc/sprs.c | 9 -
3 files changed, 35
This is a very basic detection that does not include all new SPRs.
Reviewed-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
powerpc/sprs.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/powerpc/sprs.c b/powerpc/sprs.c
index ba4ddee..6ee6dba 100644
---
This consolidates several implementations, and it no longer leaves
MSR[EE] enabled after the decrementer interrupt is handled, but
rather disables it on return.
The handler no longer allows a continuous ticking, but rather dec
has to be re-armed and EE re-enabled (e.g., via H_CEDE hcall) each
Check to ensure exception handlers are not being overwritten or
invalid exception numbers are used.
Signed-off-by: Nicholas Piggin
---
Since v2:
- New patch
lib/powerpc/processor.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/powerpc/processor.c
This adds the non-migration variant of the SPR test to the matrix,
which can be simpler to run and debug.
Reviewed-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
Since v2:
- Don't use a new group for local SPRs [Thomas review]
powerpc/unittests.cfg | 3 +++
1 file changed, 3 insertions(+)
KVM development on powerpc has moved to the Linux on Power mailing list,
as per linux.git commit 19b27f37ca97d ("MAINTAINERS: Update powerpc KVM
entry").
Reviewed-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This series is growing a bit I'm sorry. v2 series added extra interrupt
vectors support which was actually wrong because interrupt handling
code can only cope with 0x100-size vectors and new ones are 0x80 and
0x20. It managed to work because those alias to the 0x100 boundary, but
if more than one
On 3/27/23 12:36?AM, Nicholas Piggin wrote:
> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, except when PF_IO_WORKER's
On 3/26/23 10:22?PM, Nicholas Piggin wrote:
> On Sat Mar 25, 2023 at 11:20 AM AEST, Jens Axboe wrote:
>> On 3/24/23 7:15?PM, Jens Axboe wrote:
Are there any CONFIG options I'd need to trip this?
>>>
>>> I don't think you need any special CONFIG options. I'll attach my config
>>> here, and I
From: Arnd Bergmann
Now that all of these have consistent behavior, replace them with
a single shared implementation of arch_sync_dma_for_device() and
arch_sync_dma_for_cpu() and three parameters to pick how they should
operate:
- If the CPU has speculative prefetching, then the cache
has
From: Arnd Bergmann
The arm version of the arch_sync_dma_for_cpu() function annotates pages as
PG_dcache_clean after a DMA, but no other architecture does this here. On
ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
to use the same hook in order to have identical
From: Arnd Bergmann
As the final step of the conversion to generic arch_sync_dma_*
helpers, change the Arm implementation to look the same as the
new generic version, by calling the dmac_{clean,inv,flush}_area
low-level functions instead of the abstracted dmac_{map,unmap}_area
version.
On
From: Arnd Bergmann
The cache management operations for noncoherent DMA on ARMv6 work
in two different ways:
* When CONFIG_DMA_CACHE_RWFO is set, speculative prefetches on in-flight
DMA buffers lead to data corruption when the prefetched data is written
back on top of data from the
From: Arnd Bergmann
The arm specific iommu code in dma-mapping.c uses the page+offset based
__dma_page_cpu_to_dev()/__dma_page_dev_to_cpu() helpers in place of the
phys_addr_t based arch_sync_dma_for_device()/arch_sync_dma_for_cpu()
wrappers around the.
In order to be able to move the latter
From: Arnd Bergmann
These were remove ages ago in commit 702b94bff3c5 ("ARM: dma-mapping:
remove dmac_clean_range and dmac_inv_range") in an effort to sanitize
the dma-mapping API.
Now this logic is getting moved into the generic dma-mapping
implementation in order to give architectures less
From: Arnd Bergmann
Most ARM CPUs can have write-back caches and that require
cache management to be done in the dma_sync_*_for_device()
operation. This is typically done in both writeback and
writethrough mode.
The cache-v4.S (arm720/740/7tdmi/9tdmi) and cache-v4wt.S
(arm920t, arm940t)
From: Arnd Bergmann
non-coherent devices on parisc traditionally use a full flush+invalidate
before and after each DMA, which is more expensive that what we do on
other architectures.
Before transfers to a device, the cache only has to be written back,
but apparently there is no operation for
From: Arnd Bergmann
Some architectures that need to invalidate buffers after bidirectional
DMA because of speculative prefetching only do a simpler writeback
before that DMA, while architectures that don't need to do the second
invalidate tend to have a combined writeback+invalidate before the
From: Arnd Bergmann
The mips arch_sync_dma_for_device()/arch_sync_dma_for_cpu() functions
behave the same way as on other architectures, but in order to unify
the implementations, the code needs to be rearranged to pick the type
of cache operation in the outermost function.
Signed-off-by: Arnd
From: Arnd Bergmann
Some architectures that need to invalidate buffers after bidirectional
DMA because of speculative prefetching only do a simpler writeback
before that DMA, while architectures that don't need to do the second
invalidate tend to have a combined writeback+invalidate before the
From: Arnd Bergmann
csky is the only architecture that does a full flush for the
dma_sync_*_for_device(..., DMA_FROM_DEVICE) operation. The requirement
is only make sure there are no dirty cache lines for the buffer,
which can be either done through an invalidate operation (as on most
From: Arnd Bergmann
For a DMA_BIDIRECTIONAL transfer, the caches have to be cleaned
first to let the device see data written by the CPU, and invalidated
after the transfer to let the CPU see data written by the device.
riscv also invalidates the caches before the transfer, which does
not appear
From: Arnd Bergmann
No other architecture intentionally writes back dirty cache lines into
a buffer that a device has just finished writing into. If the cache is
clean, this has no effect at all, but if a cacheline in the buffer has
actually been written by the CPU, there is a drive bug that is
From: Arnd Bergmann
The powerpc implementation of arch_sync_dma_for_device() is unique in that
it sometimes performs a full flush for the arch_sync_dma_for_device(paddr,
size, DMA_FROM_DEVICE) operation when the address is unaligned, but
otherwise invalidates the caches.
Since the _for_cpu()
From: Arnd Bergmann
The powerpc dma_sync_*_for_cpu() variants do more flushes than on other
architectures. Reduce it to what everyone else does:
- No flush is needed after data has been sent to a device
- When data has been received from a device, the cache only needs to
be invalidated to
From: Arnd Bergmann
The powerpc arch_sync_dma_for_device()/arch_sync_dma_for_cpu() functions
behave differently from all other architectures, at least for some of
the operations.
As a preparation for making the behavior more consistent, reorder the
logic in which they decide whether to flush,
From: Arnd Bergmann
The microblaze dma_sync_* implementation uses the same function
for both _for_cpu() and _for_device(), which is inconsistent
with other architectures and slightly more expensive.
Split it up into separate functions and skip the parts that
are not needed:
- on
From: Arnd Bergmann
Leon has a very minimalistic cache that has no range operations
and requires being flushed entirely to deal with noncoherent
DMA. Most in-order architectures do their cache management in
the dma_sync_*for_device() operations rather than dma_sync_*for_cpu.
Since the cache is
From: Arnd Bergmann
xtensa is one of the platforms that has both write-back and write-through
caches, and needs to account for both in its DMA mapping operations.
It does this through a set of operations that is different from any
architecture. This is not a problem by itself, but it makes it
From: Arnd Bergmann
The cache management operations on DMA are different from the
other architectures:
- on DMA_TO_DEVICE, Openrisc currently invalidates the cache
after the writeback, where a simple writeback without
invalidation should be sufficient.
- on DMA_BIDIRECTIONAL, Openrisc
From: Arnd Bergmann
After a long discussion about adding SoC specific semantics for when
to flush caches in drivers/soc/ drivers that we determined to be
fundamentally flawed[1], I volunteered to try to move that logic into
architecture-independent code and make all existing architectures do
the
On Thu Mar 23, 2023 at 10:36 PM AEST, Thomas Huth wrote:
> On 20/03/2023 08.03, Nicholas Piggin wrote:
> > +/* SPRs common denominator back to PowerPC Operating Environment
> > Architecture */
> > +static const struct spr sprs_common[1024] = {
> > + [1] = {"XER",64, RW,
kvmppc_hv_entry isn't called from anywhere other than
book3s_hv_rmhandlers.S itself. Removing .global scope for
this function and annotating it with SYM_CODE_START_LOCAL
and SYM_CODE_END.
Signed-off-by: Kautuk Consul
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 ++--
1 file changed, 2
On 2023-03-27 20:30:02, Nicholas Piggin wrote:
> On Mon Mar 27, 2023 at 8:04 PM AEST, Kautuk Consul wrote:
> > kvmppc_hv_entry isn't called from anywhere other than
> > book3s_hv_rmhandlers.S itself. Removing .global scope for
> > this function and annotating it with SYM_CODE_START_LOCAL
> > and
On Mon Mar 27, 2023 at 8:04 PM AEST, Kautuk Consul wrote:
> kvmppc_hv_entry isn't called from anywhere other than
> book3s_hv_rmhandlers.S itself. Removing .global scope for
> this function and annotating it with SYM_CODE_START_LOCAL
> and SYM_CODE_END.
Does removing .global introduce the objtool
Le 27/03/2023 à 08:36, Nicholas Piggin a écrit :
> On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
>> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
>> from my (arguably very short) checking is not commonly done for other
>> archs. This is fine, except when
On Mon Mar 27, 2023 at 7:55 PM AEST, Kautuk Consul wrote:
> On 2023-03-27 19:51:34, Nicholas Piggin wrote:
> > On Mon Mar 27, 2023 at 7:34 PM AEST, Kautuk Consul wrote:
> > > On 2023-03-27 14:58:03, Kautuk Consul wrote:
> > > > On 2023-03-27 19:19:37, Nicholas Piggin wrote:
> > > > > On Thu Mar
On 2023-03-27 15:25:24, Kautuk Consul wrote:
> On 2023-03-27 19:51:34, Nicholas Piggin wrote:
> > On Mon Mar 27, 2023 at 7:34 PM AEST, Kautuk Consul wrote:
> > > On 2023-03-27 14:58:03, Kautuk Consul wrote:
> > > > On 2023-03-27 19:19:37, Nicholas Piggin wrote:
> > > > > On Thu Mar 16, 2023 at
kvmppc_hv_entry isn't called from anywhere other than
book3s_hv_rmhandlers.S itself. Removing .global scope for
this function and annotating it with SYM_CODE_START_LOCAL
and SYM_CODE_END.
Signed-off-by: Kautuk Consul
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 ++--
1 file changed, 2
On 2023-03-27 19:51:34, Nicholas Piggin wrote:
> On Mon Mar 27, 2023 at 7:34 PM AEST, Kautuk Consul wrote:
> > On 2023-03-27 14:58:03, Kautuk Consul wrote:
> > > On 2023-03-27 19:19:37, Nicholas Piggin wrote:
> > > > On Thu Mar 16, 2023 at 3:10 PM AEST, Kautuk Consul wrote:
> > > > >
On Mon Mar 27, 2023 at 7:34 PM AEST, Kautuk Consul wrote:
> On 2023-03-27 14:58:03, Kautuk Consul wrote:
> > On 2023-03-27 19:19:37, Nicholas Piggin wrote:
> > > On Thu Mar 16, 2023 at 3:10 PM AEST, Kautuk Consul wrote:
> > > > kvmppc_hv_entry isn't called from anywhere other than
> > > >
On 2023-03-27 15:04:38, Kautuk Consul wrote:
> On 2023-03-27 14:58:03, Kautuk Consul wrote:
> > On 2023-03-27 19:19:37, Nicholas Piggin wrote:
> > > On Thu Mar 16, 2023 at 3:10 PM AEST, Kautuk Consul wrote:
> > > > kvmppc_hv_entry isn't called from anywhere other than
> > > >
On 2023-03-27 14:58:03, Kautuk Consul wrote:
> On 2023-03-27 19:19:37, Nicholas Piggin wrote:
> > On Thu Mar 16, 2023 at 3:10 PM AEST, Kautuk Consul wrote:
> > > kvmppc_hv_entry isn't called from anywhere other than
> > > book3s_hv_rmhandlers.S itself. Removing .global scope for
> > > this
On 2023-03-27 19:19:37, Nicholas Piggin wrote:
> On Thu Mar 16, 2023 at 3:10 PM AEST, Kautuk Consul wrote:
> > kvmppc_hv_entry isn't called from anywhere other than
> > book3s_hv_rmhandlers.S itself. Removing .global scope for
> > this function and annotating it with SYM_INNER_LABEL.
> >
> >
On Thu Mar 16, 2023 at 3:10 PM AEST, Kautuk Consul wrote:
> kvmppc_hv_entry isn't called from anywhere other than
> book3s_hv_rmhandlers.S itself. Removing .global scope for
> this function and annotating it with SYM_INNER_LABEL.
>
> Signed-off-by: Kautuk Consul
> ---
>
On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
> from my (arguably very short) checking is not commonly done for other
> archs. This is fine, except when PF_IO_WORKER's have been created and
> the task does something
On Fri Mar 24, 2023 at 12:07 AM AEST, Thomas Huth wrote:
> On 20/03/2023 08.03, Nicholas Piggin wrote:
> > The VPA is a(n optional) memory structure shared between the hypervisor
> > and operating system, defined by PAPR. This test defines the structure
> > and adds registration, deregistration,
89 matches
Mail list logo
