[PATCH v3 07/10] powerpc/vas: Add paste address mmap fault handler

[Haren Myneni]

On Mon, 2022-02-14 at 13:37 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of January 22, 2022 5:59 am:
> > The user space opens VAS windows and issues NX requests by pasting
> > CRB on the corresponding paste address mmap. When the system looses
> 
> s/loose/lose/g throughout the series.
> 
> > credits due to core removal, the kernel has to close the window in
> > the hypervisor
> 
> By the way what if the kernel does not close the window and we try
> to access the memory? The hypervisor will inject faults?

The requests on the already opened windows will be successful even the
LPAR lost credits (due to core removal). But the hypervisor expects the
LPAR to behave like good citizen and give up resources with core
removal. So we do not see any issue with current upstream code for
DLPAR removal.

But we will have an issue with the migration. The hypervisor knows the
actulal number of credits assigned to the source LPAR before migration.
So assigns the same number on the destination. 

> 
> > and make the window inactive by unmapping this paste
> > address. Also the OS has to handle NX request page faults if the
> > user
> > space issue NX requests.
> > 
> > This handler remap the new paste address with the same VMA when the
> > window is active again (due to core add with DLPAR). Otherwise
> > returns paste failure.
> 
> This patch should come before (or combined with) the patch that zaps 
> PTEs. Putting it afterwards is logically backward. Even if you don't
> really expect the series to half work in a half bisected state, it
> just makes the changes easier to follow.
> 
> Thanks,
> Nick
> 
> > Signed-off-by: Haren Myneni <haren at linux.ibm.com>
> > ---
> >  arch/powerpc/platforms/book3s/vas-api.c | 60
> > +++++++++++++++++++++++++
> >  1 file changed, 60 insertions(+)
> > 
> > diff --git a/arch/powerpc/platforms/book3s/vas-api.c
> > b/arch/powerpc/platforms/book3s/vas-api.c
> > index 2d06bd1b1935..5ceba75c13eb 100644
> > --- a/arch/powerpc/platforms/book3s/vas-api.c
> > +++ b/arch/powerpc/platforms/book3s/vas-api.c
> > @@ -351,6 +351,65 @@ static int coproc_release(struct inode *inode,
> > struct file *fp)
> >  	return 0;
> >  }
> >  
> > +/*
> > + * This fault handler is invoked when the VAS/NX generates page
> > fault on
> > + * the paste address.
> 
> The core generates the page fault here, right? paste destination is 
> translated by the core MMU (the instruction is executed in the core,
> afterall).

correct. Will update. 
> 
> > Happens if the kernel closes window in hypervisor
> > + * (on PowerVM) due to lost credit or the paste address is not
> > mapped.
> 
> Call it pseries everywhere if you're talking about the API and Linux
> code, rather than some specific quirk or issue of of the PowerVM
> implementation.
> 
> > + */
> > +static vm_fault_t vas_mmap_fault(struct vm_fault *vmf)
> > +{
> > +	struct vm_area_struct *vma = vmf->vma;
> > +	struct file *fp = vma->vm_file;
> > +	struct coproc_instance *cp_inst = fp->private_data;
> > +	struct vas_window *txwin;
> > +	u64 paste_addr;
> > +	int ret;
> > +
> > +	/*
> > +	 * window is not opened. Shouldn't expect this error.
> > +	 */
> > +	if (!cp_inst || !cp_inst->txwin) {
> > +		pr_err("%s(): No send window open?\n", __func__);
> 
> Probably don't put PR_ERROR logs with question marks in them. The
> administrator knows less than you to answer the question.
> 
> "Unexpected fault on paste address with TX window closed" etc.
> 
> Then you don't need the comment either because the message explains
> it.
> 
> > +		return VM_FAULT_SIGBUS;
> > +	}
> > +
> > +	txwin = cp_inst->txwin;
> > +	/*
> > +	 * Fault is coming due to missing from the original mmap.
> 
> Rather than a vague comment like this (which we already know a fault 
> comes from a missing or insufficient PTE), you could point to exactly
> the code which zaps the PTEs.
> 
> > +	 * Can happen only when the window is closed due to lost
> > +	 * credit before mmap() or the user space issued NX request
> > +	 * without mapping.
> > +	 */
> > +	if (txwin->task_ref.vma != vmf->vma) {
> > +		pr_err("%s(): No previous mapping with paste
> > address\n",
> > +			__func__);
> > +		return VM_FAULT_SIGBUS;
> > +	}
> > +
> > +	mutex_lock(&txwin->task_ref.mmap_mutex);
> > +	/*
> > +	 * The window may be inactive due to lost credit (Ex: core
> > +	 * removal with DLPAR). When the window is active again when
> > +	 * the credit is available, remap with the new paste address.
> 
> Remap also typically means mapping the same physical memory at a 
> different virtual address. So when you say remap with the new paste
> address, in Linux mm terms that means you're mapping the same window
> at a different virtual address.
> 
> But you're faulting a different physical address into the same
> virtual.

Yes, we get different physical address and this handler maps the this
paste address at the existing virtual address. will update this
comment.
> 
> > +	 */
> > +	if (txwin->status == VAS_WIN_ACTIVE) {
> > +		paste_addr = cp_inst->coproc->vops->paste_addr(txwin);
> > +		if (paste_addr) {
> > +			ret = vmf_insert_pfn(vma, vma->vm_start,
> > +					(paste_addr >> PAGE_SHIFT));
> > +			mutex_unlock(&txwin->task_ref.mmap_mutex);
> > +			return ret;
> > +		}
> > +	}
> > +	mutex_unlock(&txwin->task_ref.mmap_mutex);
> 
> Here a comment about how userspace is supposed to handle the
> window-closed condition might be appropriate.
> 
> Thanks,
> Nick
> 
> > +
> > +	return VM_FAULT_SIGBUS;
> > +
> > +}
> > +static const struct vm_operations_struct vas_vm_ops = {
> > +	.fault = vas_mmap_fault,
> > +};
> > +
> >  static int coproc_mmap(struct file *fp, struct vm_area_struct
> > *vma)
> >  {
> >  	struct coproc_instance *cp_inst = fp->private_data;
> > @@ -417,6 +476,7 @@ static int coproc_mmap(struct file *fp, struct
> > vm_area_struct *vma)
> >  			paste_addr, vma->vm_start, rc);
> >  
> >  	txwin->task_ref.vma = vma;
> > +	vma->vm_ops = &vas_vm_ops;
> >  
> >  out:
> >  	mutex_unlock(&txwin->task_ref.mmap_mutex);
> > -- 
> > 2.27.0
> > 
> > 
> >