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

[Nicholas Piggin <npiggin@gmail.com>]

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?

> 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@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).

> 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.

> +	 */
> +	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
> 
> 
>