From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [v7][RFC][PATCH 08/13] xen/x86/p2m: set
 p2m_access_n for reserved device memory mapping
Date: Mon, 03 Nov 2014 19:48:43 +0800
Message-ID: <54576B9B.1060601@intel.com>
References: <1414136077-18599-1-git-send-email-tiejun.chen@intel.com>
	<1414136077-18599-9-git-send-email-tiejun.chen@intel.com>
	<544A88560200007800042056@mail.emea.novell.com>
	<544E0ACA.8050201@intel.com>
	<544E2D8002000078000425A9@mail.emea.novell.com>
	<544F531C.7060401@intel.com>
	<544F7A310200007800042BAC@mail.emea.novell.com>
	<5450A330.6020102@intel.com>
	<5450BF63020000780004305E@mail.emea.novell.com>
	<5451EB48.9010103@intel.com>
	<545211DA0200007800043645@mail.emea.novell.com>
	<5452F8D8.9050009@intel.com>
	<545355720200007800043D97@mail.emea.novell.com>
	<54571E91.4030903@intel.com>
	<5457523A02000078000443C7@mail.emea.novell.com>
	<54575013.50702@intel.com>
	<545760FD0200007800044474@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <545760FD0200007800044474@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, tim@xen.org, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 2014/11/3 18:03, Jan Beulich wrote:
>>>> On 03.11.14 at 10:51, <tiejun.chen@intel.com> wrote:
>> On 2014/11/3 17:00, Jan Beulich wrote:
>>>>>> On 03.11.14 at 07:20, <tiejun.chen@intel.com> wrote:
>>>> #2 the error handling
>>>>
>>>> In an error case what should I do? Currently we still create these
>>>> mapping as normal. This means these mfns will be valid so later we can't
>>>> set them again then device can't be assigned as passthrough. I think
>>>> this makes sense. Or we should just stop them from setting 1:1 mapping?
>>>
>>> You should, with very few exceptions, not ignore errors (which
>>> includes "handling" them by just logging a message. Instead, you
>>> should propagate the error back up the call chain.
>>>
>>
>> Do you mean in your patch,
>>
>> +int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
>> +{
>> +    const struct iommu_ops *ops = iommu_get_ops();
>> +
>> +    if ( !iommu_enabled || !ops->get_reserved_device_memory )
>> +        return 0;
>> +
>> +    return ops->get_reserved_device_memory(func, ctxt);
>> +}
>> +
>>
>> I shouldn't return that directly. Then instead, we should handle all
>> error scenarios here?
>
> No. All error scenarios are already being handled here (by
> propagating the error code to the caller).

Sorry, how to propagate the error code?

Thanks
Tiejun