On Tue, Jun 23, 2015 at 10:57 AM, Tiejun Chen <tiejun.c...@intel.com> wrote:
> This patch parses to enable user configurable parameters to specify
> RDM resource and according policies,
>
> Global RDM parameter:
>     rdm = "type=none/host,reserve=strict/relaxed"
> Per-device RDM parameter:
>     pci = [ 'sbdf, rdm_reserve=strict/relaxed' ]x

Oh, right -- I see you did add this here.  In which case I think you
don't need the extra xl parameter you added in patch 12/19, right?  As
I said, that's how we're handling permissive, msi_translate, and the
other per-device flags.

> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index c7a12b1..85d74fd 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1923,6 +1923,14 @@ skip_vfb:
>          xlu_cfg_get_defbool(config, "e820_host", &b_info->u.pv.e820_host, 0);
>      }
>
> +    if (!xlu_cfg_get_string(config, "rdm", &buf, 0)) {
> +        libxl_rdm_reserve rdm;
> +        if (!xlu_rdm_parse(config, &rdm, buf)) {
> +            b_info->rdm.type = rdm.type;
> +            b_info->rdm.reserve = rdm.reserve;
> +        }
> +    }
> +
>      if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
>          d_config->num_pcidevs = 0;
>          d_config->pcidevs = NULL;
> @@ -1937,6 +1945,8 @@ skip_vfb:
>              pcidev->power_mgmt = pci_power_mgmt;
>              pcidev->permissive = pci_permissive;
>              pcidev->seize = pci_seize;
> +            /* We'd like to force reserve rdm specific to a device by 
> default.*/
> +            pcidev->rdm_reserve = LIBXL_RDM_RESERVE_FLAG_STRICT;

Won't this mean that even with a domain default policy of "relaxed",
that individual pci devices will still default to "strict"?

It looks to me like your global policy isn't so much "default to
relaxed unless specified strict" vs "default to strict unless
specified to relaxed", but is effectively "allow to be relaxed if
specified" vs "force to be strict no matter what the per-device config
says".  That's much less expected, and I think less useful.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Reply via email to