From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756014AbcDGKd3 (ORCPT ); Thu, 7 Apr 2016 06:33:29 -0400 Received: from foss.arm.com ([217.140.101.70]:33105 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932077AbcDGKcy (ORCPT ); Thu, 7 Apr 2016 06:32:54 -0400 Subject: Re: [PATCH v10 06/17] Xen: ARM: Add support for mapping platform device mmio To: Shannon Zhao , Shannon Zhao , linux-arm-kernel@lists.infradead.org, sstabellini@kernel.org References: <1459525755-36968-1-git-send-email-shannon.zhao@linaro.org> <1459525755-36968-7-git-send-email-shannon.zhao@linaro.org> <5704FE2C.5000902@arm.com> <5705B9BD.1020403@huawei.com> Cc: david.vrabel@citrix.com, devicetree@vger.kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, peter.huangpeng@huawei.com, xen-devel@lists.xen.org From: Julien Grall Message-ID: <57063752.4020805@arm.com> Date: Thu, 7 Apr 2016 11:32:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5705B9BD.1020403@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Shannon, On 07/04/16 02:37, Shannon Zhao wrote: > > > On 2016/4/6 20:16, Julien Grall wrote: >>> + gpfns[j] = XEN_PFN_DOWN(r->start) + j; >>> + idxs[j] = XEN_PFN_DOWN(r->start) + j; >>> + } >>> + >>> + xatp.domid = DOMID_SELF; >>> + xatp.size = nr; >>> + xatp.space = XENMAPSPACE_dev_mmio; >>> + >>> + set_xen_guest_handle(xatp.gpfns, gpfns); >>> + set_xen_guest_handle(xatp.idxs, idxs); >>> + set_xen_guest_handle(xatp.errs, errs); >>> + >>> + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); >>> + kfree(gpfns); >>> + kfree(idxs); >>> + kfree(errs); >>> + if (rc) >>> + return rc; >> >> Shouldn't we redo the mapping if the hypercall fails? > Hmm, why? If it fails again when we redo the mapping, what should we do > then? Redo again? Because the device MMIO region is left half mapped in DOM0 address space. After having another look to your patch, if an error occurs, the notifier will still return NOTIFY_OK. This will lead to random data abort when the driver is accessing the MMIO regions as the device will be considered fully functional. However, even if the notifier return NOTIFY_BAD, the function device_add doesn't care about the return value of blocking_notifier_call_chain. I think this need to be fixed. > I think if it fails at the first time it will always fail no matter how > many times we do. I was speaking about the mappings that succeeded. They will unlikely fail during removal. If they ever fail you can just ignore the error. Regards, -- Julien Grall From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v10 06/17] Xen: ARM: Add support for mapping platform device mmio Date: Thu, 7 Apr 2016 11:32:50 +0100 Message-ID: <57063752.4020805@arm.com> References: <1459525755-36968-1-git-send-email-shannon.zhao@linaro.org> <1459525755-36968-7-git-send-email-shannon.zhao@linaro.org> <5704FE2C.5000902@arm.com> <5705B9BD.1020403@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5705B9BD.1020403@huawei.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Shannon Zhao , Shannon Zhao , linux-arm-kernel@lists.infradead.org, sstabellini@kernel.org Cc: devicetree@vger.kernel.org, linux-efi@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, peter.huangpeng@huawei.com, david.vrabel@citrix.com, xen-devel@lists.xen.org List-Id: devicetree@vger.kernel.org Hi Shannon, On 07/04/16 02:37, Shannon Zhao wrote: > > > On 2016/4/6 20:16, Julien Grall wrote: >>> + gpfns[j] = XEN_PFN_DOWN(r->start) + j; >>> + idxs[j] = XEN_PFN_DOWN(r->start) + j; >>> + } >>> + >>> + xatp.domid = DOMID_SELF; >>> + xatp.size = nr; >>> + xatp.space = XENMAPSPACE_dev_mmio; >>> + >>> + set_xen_guest_handle(xatp.gpfns, gpfns); >>> + set_xen_guest_handle(xatp.idxs, idxs); >>> + set_xen_guest_handle(xatp.errs, errs); >>> + >>> + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); >>> + kfree(gpfns); >>> + kfree(idxs); >>> + kfree(errs); >>> + if (rc) >>> + return rc; >> >> Shouldn't we redo the mapping if the hypercall fails? > Hmm, why? If it fails again when we redo the mapping, what should we do > then? Redo again? Because the device MMIO region is left half mapped in DOM0 address space. After having another look to your patch, if an error occurs, the notifier will still return NOTIFY_OK. This will lead to random data abort when the driver is accessing the MMIO regions as the device will be considered fully functional. However, even if the notifier return NOTIFY_BAD, the function device_add doesn't care about the return value of blocking_notifier_call_chain. I think this need to be fixed. > I think if it fails at the first time it will always fail no matter how > many times we do. I was speaking about the mappings that succeeded. They will unlikely fail during removal. If they ever fail you can just ignore the error. Regards, -- Julien Grall From mboxrd@z Thu Jan 1 00:00:00 1970 From: julien.grall@arm.com (Julien Grall) Date: Thu, 7 Apr 2016 11:32:50 +0100 Subject: [PATCH v10 06/17] Xen: ARM: Add support for mapping platform device mmio In-Reply-To: <5705B9BD.1020403@huawei.com> References: <1459525755-36968-1-git-send-email-shannon.zhao@linaro.org> <1459525755-36968-7-git-send-email-shannon.zhao@linaro.org> <5704FE2C.5000902@arm.com> <5705B9BD.1020403@huawei.com> Message-ID: <57063752.4020805@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Shannon, On 07/04/16 02:37, Shannon Zhao wrote: > > > On 2016/4/6 20:16, Julien Grall wrote: >>> + gpfns[j] = XEN_PFN_DOWN(r->start) + j; >>> + idxs[j] = XEN_PFN_DOWN(r->start) + j; >>> + } >>> + >>> + xatp.domid = DOMID_SELF; >>> + xatp.size = nr; >>> + xatp.space = XENMAPSPACE_dev_mmio; >>> + >>> + set_xen_guest_handle(xatp.gpfns, gpfns); >>> + set_xen_guest_handle(xatp.idxs, idxs); >>> + set_xen_guest_handle(xatp.errs, errs); >>> + >>> + rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp); >>> + kfree(gpfns); >>> + kfree(idxs); >>> + kfree(errs); >>> + if (rc) >>> + return rc; >> >> Shouldn't we redo the mapping if the hypercall fails? > Hmm, why? If it fails again when we redo the mapping, what should we do > then? Redo again? Because the device MMIO region is left half mapped in DOM0 address space. After having another look to your patch, if an error occurs, the notifier will still return NOTIFY_OK. This will lead to random data abort when the driver is accessing the MMIO regions as the device will be considered fully functional. However, even if the notifier return NOTIFY_BAD, the function device_add doesn't care about the return value of blocking_notifier_call_chain. I think this need to be fixed. > I think if it fails at the first time it will always fail no matter how > many times we do. I was speaking about the mappings that succeeded. They will unlikely fail during removal. If they ever fail you can just ignore the error. Regards, -- Julien Grall