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: Mon, 06 Jul 2015 18:56:45 +0800
Message-ID: <559A5EED.2010904@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>
	<55927C78.10301@intel.com> <5592A598.60001@eu.citrix.com>
	<55933E4D.4030405@intel.com> <5593BAAB.20801@eu.citrix.com>
	<5593C544.2030009@intel.com>
	<559A75DF020000780008C9D9@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: <559A75DF020000780008C9D9@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: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, George Dunlap <george.dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>, Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>, Yang Zhang <yang.z.zhang@intel.com>, Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
List-Id: xen-devel@lists.xenproject.org

>>> Yes, this demonstrates my point.  Each of these is a single-bit boolean
>>> value that takes up a single bit -- either on or off.  But here you have
>>> three values -- NO_DRM, RELAXED, and STRICT, that take up two bits.  If
>>
>> Is this fine to you?
>>
>> #define _XEN_DOMCTL_DEV_NO_RDM          0
>> #define XEN_DOMCTL_DEV_NO_RDM           (1U<<_XEN_DOMCTL_DEV_NO_RDM)
>> #define _XEN_DOMCTL_DEV_RDM_RELAXED     1
>> #define XEN_DOMCTL_DEV_RDM_RELAXED      (1U<<_XEN_DOMCTL_DEV_RDM_RELAXED)
>> #define _XEN_DOMCTL_DEV_RDM_STRICT      2
>> #define XEN_DOMCTL_DEV_RDM_STRICT       (1U<<_XEN_DOMCTL_DEV_RDM_STRICT)
>
> AIUI these aren't individual flags, but kind of an enumeration. I.e.
> you should keep the original definitions and add - as suggested by
> George - a mask (two bits wide right now).
>

Okay but George also thought NO_RDM may be pointless since we can just 
ignore this flag field simply for DT device, and he also thought one bit 
may be fine enough to cover two cases, strict and relaxed. So maybe 
finally, here is,

#define XEN_DOMCTL_DEV_RDM_RELAXED	1
#define XEN_DOMCTL_DEV_RDM_FLAGS_MASK	(0x1)

Thanks
Tiejun