From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755758AbcDGL0N (ORCPT ); Thu, 7 Apr 2016 07:26:13 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:12651 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755460AbcDGL0K (ORCPT ); Thu, 7 Apr 2016 07:26:10 -0400 Message-ID: <570643B4.3070502@huawei.com> Date: Thu, 7 Apr 2016 19:25:40 +0800 From: Shannon Zhao User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Julien Grall , Shannon Zhao , , CC: , , , , , , , Subject: Re: [PATCH v10 06/17] Xen: ARM: Add support for mapping platform device mmio 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> <57063752.4020805@arm.com> In-Reply-To: <57063752.4020805@arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.16.142] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.570643C5.019F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: db5b1e2b3ccfc664302def632b7518a3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/4/7 18:32, Julien Grall wrote: > 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. Ok, I see. I thought you mean that it needs to map the regions again. But what you really mean is undoing the mappings. Thanks, -- Shannon