[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [v4][PATCH 04/19] xen/passthrough: extend hypercall to support rdm reservation policy
On 07/06/2015 11:34 AM, Jan Beulich wrote: >>>> On 01.07.15 at 12:47, <tiejun.chen@xxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |