On 16/11/2018 16:25, David Gibson wrote:
> On Tue, Nov 13, 2018 at 07:28:12PM +1100, Alexey Kardashevskiy wrote:
>> We already changed NPU API for GPUs to not to call OPAL and the remaining
>> bit is initializing NPU structures.
>>
>> This uses a new QEMU capability which marks NPU-enabled
On 16/11/2018 16:23, David Gibson wrote:
> On Tue, Nov 13, 2018 at 07:28:11PM +1100, Alexey Kardashevskiy wrote:
>> We might have memory@ nodes with "linux,usable-memory" set to zero
>> (for example, to replicate powernv's behaviour for GPU coherent memory)
>> which means that the memory needs
On 16/11/2018 15:54, David Gibson wrote:
> On Tue, Nov 13, 2018 at 07:28:10PM +1100, Alexey Kardashevskiy wrote:
>> It is quite common for a device to support more than 32bit but less than
>> 64bit for DMA, for example, GPUs often support 42..50bits. However
>> the pseries platform only allows
On 14/11/2018 15:28, Alistair Popple wrote:
> Hi Alexey,
>
> On Tuesday, 13 November 2018 7:28:07 PM AEDT Alexey Kardashevskiy wrote:
>> static struct npu *npdev_to_npu(struct pci_dev *npdev)
>> {
>> -struct pnv_phb *nphb;
>> +struct pci_controller *hose =
> -Original Message-
> From: David Miller
> Sent: Saturday, November 17, 2018 5:42 AM
> To: Madalin-cristian Bucur
> Subject: Re: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control
>
> From: Madalin Bucur
> Date: Tue, 13 Nov 2018 18:29:51 +0200
>
> > + for_each_cpu(cpu, cpus) {
>
The current implementation of the OPAL_PCI_EEH_FREEZE_STATUS call in
skiboot's NPU driver does not touch the pci_error_type parameter so
it might have garbage but the powernv code analyzes it nevertheless.
This initializes pcierr and fstate to zero in all call sites.
Signed-off-by: Alexey
On 17-11-18, 10:24, Christophe Leroy wrote:
> Today, powerpc has three CONFIG labels which means exactly the same:
> - CONFIG_6xx
> - CONFIG_PPC_BOOK3S_32
> - CONFIG_PPC_STD_MMU_32
>
> By consistency with PPC64, CONFIG_PPC_BOOK3S_32 is the preferred one.
> Using a label with includes _PPC_ also
On Wed, 2018-11-07 at 16:56 +, Christophe Leroy wrote:
> This patch adds a skeleton for Kernel Userspace Execution Prevention.
>
> Then subarches implementing it have to define CONFIG_PPC_HAVE_KUEP
> and provide setup_kuep() function.
>
> Signed-off-by: Christophe Leroy
An open question
On 19/11/2018 12:12, David Gibson wrote:
> On Tue, Nov 13, 2018 at 07:28:19PM +1100, Alexey Kardashevskiy wrote:
>> At the moment powernv registers an IOMMU group for each PE. There is
>> an exception though - NPU (an emulated PCI bridge representing an NVLink);
>> powernv attaches these
On Mon, Nov 19, 2018 at 09:08:20AM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
Umm. I don't see a 'suspicious RCU usage' message in here. I see a
lot of vmalloc warnings ... ?
> [7.699777] swapper: vmalloc:
On Tue, Nov 13, 2018 at 07:28:19PM +1100, Alexey Kardashevskiy wrote:
> At the moment powernv registers an IOMMU group for each PE. There is
> an exception though - NPU (an emulated PCI bridge representing an NVLink);
> powernv attaches these bridges to the GPU IOMMU group which becomes
> a
On 17/11/18 9:11 am, Rob Herring wrote:
Remove directly accessing device_node.type pointer and use the accessors
instead. This will eventually allow removing the type pointer.
This description doesn't quite match what's being fixed - we're not
accessing the .type pointer, we're getting the
On Tue, Nov 13, 2018 at 07:28:17PM +1100, Alexey Kardashevskiy wrote:
> Flushing caches using the dcbf instruction takes quite some time if we
> need to flush gigabytes (16GB takes more than 15s); OPAL just added
> a big hammer to flush all caches.
>
> This adds opal_purge_cache() which will be
On Tue, Nov 13, 2018 at 07:28:18PM +1100, Alexey Kardashevskiy wrote:
> At the moment NPU IOMMU is manipulated directly from the IODA2 PCI
> PE code; PCI PE acts as a master to NPU PE. Soon we will have compound
> IOMMU groups with several PEs from several different PHB (such as
> interconnected
On Tue, Nov 13, 2018 at 07:28:15PM +1100, Alexey Kardashevskiy wrote:
> Registering new IOMMU groups and adding devices to them are separated in
> code and the latter is dug in the DMA setup code which it does not
> really belong to.
>
> This moved IOMMU groups setup to a separate helper which
On Tue, Nov 13, 2018 at 07:28:16PM +1100, Alexey Kardashevskiy wrote:
> The iommu_table pointer stored in iommu_table_group may get stale
> by accident, this adds referencing and removes a redundant comment
> about this.
>
> Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
> ---
On Sun, Nov 18, 2018 at 3:55 PM Ard Biesheuvel
wrote:
>
> On Sat, 17 Nov 2018 at 23:47, Y Song wrote:
> >
> > On Sat, Nov 17, 2018 at 6:58 PM Ard Biesheuvel
> > wrote:
> > >
> > > All arch overrides of the __weak bpf_jit_free() amount to the same
> > > thing: the allocated memory was never
On Sat, 17 Nov 2018 at 23:47, Y Song wrote:
>
> On Sat, Nov 17, 2018 at 6:58 PM Ard Biesheuvel
> wrote:
> >
> > All arch overrides of the __weak bpf_jit_free() amount to the same
> > thing: the allocated memory was never mapped read-only, and so
> > it does not have to be remapped to read-write
On Wed, Nov 14, 2018 at 09:20:23PM +1100, Michael Ellerman wrote:
> Joel Stanley writes:
> > Hello Alan,
> >
> > On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell
> > wrote:
> >
> >> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> >> produced these warning:
> >>
> >> ld:
On Sat, Nov 17, 2018 at 6:58 PM Ard Biesheuvel
wrote:
>
> On arm64, modules are allocated from a 128 MB window which is close to
> the core kernel, so that relative direct branches are guaranteed to be
> in range (except in some KASLR configurations). Also, module_alloc()
> is in charge of
On Sat, Nov 17, 2018 at 6:58 PM Ard Biesheuvel
wrote:
>
> All arch overrides of the __weak bpf_jit_free() amount to the same
> thing: the allocated memory was never mapped read-only, and so
> it does not have to be remapped to read-write before being freed.
>
> So in preparation of permitting
On Thu, Nov 15, 2018 at 11:47:52PM +1100, Michael Ellerman wrote:
> Alan Modra writes:
>
> > On Wed, Nov 14, 2018 at 01:32:18PM +1030, Joel Stanley wrote:
> >> I wasn't sure where this should go or if the ordering matters.
> >
> > The usual answer is: "Look at where the section goes in the
22 matches
Mail list logo
