|
[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 |