Re: [PATCH 2/2] powerpc/uaccess: Move might_fault() into user_access_begin()

Christophe Leroy writes: > Le 08/02/2021 à 14:57, Michael Ellerman a écrit : >> We have a might_fault() check in __unsafe_put_user_goto(), but that is >> dangerous as it potentially calls lots of code while user access is >> enabled. >> >> It also triggers the check Alexey added to the irq restor

Re: [PATCH v4 1/3] powerpc/book3s64/radix/tlb: tlbie primitives for process-scoped invalidations from guests

On Mon, Feb 15, 2021 at 12:05:40PM +0530, Bharata B Rao wrote: > H_RPT_INVALIDATE hcall needs to perform process scoped tlbie > invalidations of L1 and nested guests from L0. This needs RS register > for TLBIE instruction to contain both PID and LPID. Introduce > primitives that execute tlbie instr

Re: [PATCH kernel 2/2] powerpc/iommu: Do not immediately panic when failed IOMMU table allocation

On Tue, Feb 16, 2021 at 02:33:07PM +1100, Alexey Kardashevskiy wrote: > Most platforms allocate IOMMU table structures (specifically it_map) > at the boot time and when this fails - it is a valid reason for panic(). > > However the powernv platform allocates it_map after a device is returned > to

Re: [PATCH v4 2/3] KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE

On Mon, Feb 15, 2021 at 12:05:41PM +0530, Bharata B Rao wrote: > Implement H_RPT_INVALIDATE hcall and add KVM capability > KVM_CAP_PPC_RPT_INVALIDATE to indicate the support for the same. > > This hcall does two types of TLB invalidations: > > 1. Process-scoped invalidations for guests with LPCR[

Re: [PATCH kernel 1/2] powerpc/iommu: Allocate it_map by vmalloc

On Tue, Feb 16, 2021 at 02:33:06PM +1100, Alexey Kardashevskiy wrote: > The IOMMU table uses the it_map bitmap to keep track of allocated DMA > pages. This has always been a contiguous array allocated at either > the boot time or when a passed through device is returned to the host OS. > The it_map

Re: [PATCH 1/4] add generic builtin command line

On Tue, 2021-02-16 at 18:42 +0100, Christophe Leroy wrote: > I'd suggest also to find the good arguments to convince us that this > series has a real added value, not just "cisco use it in its kernels > so it is good". Well, IIRC, this series was endorsed by the device tree maintainers as the

Re: [PATCH 4/4] ibmvfc: store return code of H_FREE_SUB_CRQ during cleanup

On 2/16/21 6:58 AM, Brian King wrote: > On 2/11/21 12:57 PM, Tyrel Datwyler wrote: >> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c >> index ba6fcf9cbc57..23b803ac4a13 100644 >> --- a/drivers/scsi/ibmvscsi/ibmvfc.c >> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c >> @@ -5670,7

Re: [PATCH 1/4] add generic builtin command line

On Mon, Feb 15, 2021 at 11:32:01AM -0800, Daniel Gimpelevich wrote: > On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote: > > On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker wrote: > > > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote: > > > > The patches (or some version of the

Re: [PATCH 1/4] add generic builtin command line

Daniel Gimpelevich a écrit : On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote: On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker wrote: > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote: > > The patches (or some version of them) are already in linux-next, > > which messes m

Re: [PATCH 4/4] ibmvfc: store return code of H_FREE_SUB_CRQ during cleanup

On 2/11/21 12:57 PM, Tyrel Datwyler wrote: > diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c > index ba6fcf9cbc57..23b803ac4a13 100644 > --- a/drivers/scsi/ibmvscsi/ibmvfc.c > +++ b/drivers/scsi/ibmvscsi/ibmvfc.c > @@ -5670,7 +5670,7 @@ static int ibmvfc_register_scsi_c

Re: [PATCH 3/4] ibmvfc: treat H_CLOSED as success during sub-CRQ registration

Reviewed-by: Brian King -- Brian King Power Linux I/O IBM Linux Technology Center

Re: [PATCH 2/4] ibmvfc: fix invalid sub-CRQ handles after hard reset

Reviewed-by: Brian King -- Brian King Power Linux I/O IBM Linux Technology Center