From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Chen, Tiejun" <tiejun.chen@intel.com>
Subject: Re: [v4][PATCH 04/19] xen/passthrough: extend hypercall
 to support rdm reservation policy
Date: Tue, 30 Jun 2015 19:24:40 +0800
Message-ID: <55927C78.10301@intel.com>
References: <1435053450-25131-1-git-send-email-tiejun.chen@intel.com>	<1435053450-25131-5-git-send-email-tiejun.chen@intel.com>
	<CAFLBxZYshUu4NWmVU2yMeoR+-QoidkL2KjuuW3ZtS5hHPe0WSA@mail.gmail.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: <CAFLBxZYshUu4NWmVU2yMeoR+-QoidkL2KjuuW3ZtS5hHPe0WSA@mail.gmail.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: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>, Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>, Jan Beulich <jbeulich@suse.com>, Yang Zhang <yang.z.zhang@intel.com>, Stefano Stabellini <stefano.stabellini@citrix.com>, Ian Campbell <ian.campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

>> +#define XEN_DOMCTL_DEV_NO_RDM           0
>> +#define XEN_DOMCTL_DEV_RDM_RELAXED      1
>> +#define XEN_DOMCTL_DEV_RDM_STRICT       2
>> +    uint32_t  flag;   /* flag of assigned device */
>
> Normally flags would be bit fields, not values like this.
>
> Also, what's the distinction between RDM and RMRR, and is there a good
> reason to use the first here rather than the second?
>
> It's also not clear to me what NO_RDM is meant to be for -- is it
> meant to be an assertion that the caller expects the device to have no
> RMRRs associated with it?
>

All concerns what you're raising above just make me realized you're 
missing all background info and history changes. So I think if you 
really would like to review this series, at least you should take a look 
at our previous design and some basic change log, which are mentioned 
inside patch #00.

Thanks
Tiejun