From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy Date: Mon, 6 Jul 2015 11:56:12 +0100 Message-ID: <559A5ECC.30703@eu.citrix.com> References: <1435053450-25131-1-git-send-email-tiejun.chen@intel.com> <1435053450-25131-5-git-send-email-tiejun.chen@intel.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" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <559A75DF020000780008C9D9@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Tiejun Chen Cc: Kevin Tian , Keir Fraser , Ian Campbell , Andrew Cooper , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , Suravee Suthikulpanit , Yang Zhang , Aravind Gopalakrishnan List-Id: xen-devel@lists.xenproject.org On 07/06/2015 11:34 AM, Jan Beulich wrote: >>>> On 01.07.15 at 12:47, wrote: >> On 2015/7/1 18:02, George Dunlap wrote: >>> On 07/01/2015 02:11 AM, Chen, Tiejun wrote: >>>> /* XEN_DOMCTL_createdomain */ >>>> struct xen_domctl_createdomain { >>>> /* IN parameters */ >>>> uint32_t ssidref; >>>> xen_domain_handle_t handle; >>>> /* Is this an HVM guest (as opposed to a PVH or PV guest)? */ >>>> #define _XEN_DOMCTL_CDF_hvm_guest 0 >>>> #define XEN_DOMCTL_CDF_hvm_guest (1U<<_XEN_DOMCTL_CDF_hvm_guest) >>>> /* Use hardware-assisted paging if available? */ >>>> #define _XEN_DOMCTL_CDF_hap 1 >>>> #define XEN_DOMCTL_CDF_hap (1U<<_XEN_DOMCTL_CDF_hap) >>>> /* Should domain memory integrity be verifed by tboot during Sx? */ >>>> #define _XEN_DOMCTL_CDF_s3_integrity 2 >>>> #define XEN_DOMCTL_CDF_s3_integrity (1U<<_XEN_DOMCTL_CDF_s3_integrity) >>>> /* Disable out-of-sync shadow page tables? */ >>>> #define _XEN_DOMCTL_CDF_oos_off 3 >>>> #define XEN_DOMCTL_CDF_oos_off (1U<<_XEN_DOMCTL_CDF_oos_off) >>>> /* Is this a PVH guest (as opposed to an HVM or PV guest)? */ >>>> #define _XEN_DOMCTL_CDF_pvh_guest 4 >>>> #define XEN_DOMCTL_CDF_pvh_guest (1U<<_XEN_DOMCTL_CDF_pvh_guest) >>>> uint32_t flags; >>> >>> 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). Actually, further on in the discussion it turns out that NO_RDM was based on a misunderstanding of what this patch series was doing. So there are really only two options needed. I have suggested just using a single-bit flag, XEN_DOMCTL_DEV_RDM_RELAXED. If it's not set, it's strict. Julien was OK with that approach as well. -George