[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.