From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: kevin.tian@intel.com, ian.campbell@citrix.com,
andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org,
stefano.stabellini@citrix.com, JBeulich@suse.com,
yang.z.zhang@intel.com, Ian.Jackson@eu.citrix.com
Subject: Re: [RFC][PATCH 01/13] tools: introduce some new parameters to set rdm policy
Date: Mon, 18 May 2015 09:06:29 +0800 [thread overview]
Message-ID: <55593B15.6050600@intel.com> (raw)
In-Reply-To: <55555157.3000604@intel.com>
Wei,
Ping... :)
Thanks
Tiejun
On 2015/5/15 9:52, Chen, Tiejun wrote:
> On 2015/5/11 22:54, Wei Liu wrote:
>> On Mon, May 11, 2015 at 01:35:06PM +0800, Chen, Tiejun wrote:
>>> On 2015/5/8 21:04, Wei Liu wrote:
>>>> Sorry for the late review.
>>>>
>>>
>>> Really thanks for taking your time :)
>>>
>>>> On Fri, Apr 10, 2015 at 05:21:52PM +0800, Tiejun Chen wrote:
>>>>> This patch introduces user configurable parameters to specify RDM
>>>>> resource and according policies,
>>>>>
>>>>> Global RDM parameter:
>>>>> rdm = [ 'host, reserve=force/try' ]
>>>>> Per-device RDM parameter:
>>>>> pci = [ 'sbdf, rdm_reserve=force/try' ]
>>>>>
>>>>> Global RDM parameter allows user to specify reserved regions
>>>>> explicitly,
>>>>> e.g. using 'host' to include all reserved regions reported on this
>>>>> platform
>>>>> which is good to handle hotplug scenario. In the future this parameter
>>>>> may be further extended to allow specifying random regions, e.g. even
>>>>> those belonging to another platform as a preparation for live
>>>>> migration
>>>>> with passthrough devices.
>>>>>
>>>>> 'force/try' policy decides how to handle conflict when reserving RDM
>>>>> regions in pfn space. If conflict exists, 'force' means an
>>>>> immediate error
>>>>> so VM will be killed, while 'try' allows moving forward with a warning
>>>>> message thrown out.
>>>>>
>>>>> Default per-device RDM policy is 'force', while default global RDM
>>>>> policy
>>>>> is 'try'. When both policies are specified on a given region,
>>>>> 'force' is
>>>>> always preferred.
>>>>>
>>>>> Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
>>>>> ---
>>>>> docs/man/xl.cfg.pod.5 | 44 +++++++++++++++++++++++++
>>>>> docs/misc/vtd.txt | 34 ++++++++++++++++++++
>>>>> tools/libxl/libxl_create.c | 5 +++
>>>>> tools/libxl/libxl_types.idl | 18 +++++++++++
>>>>> tools/libxl/libxlu_pci.c | 78
>>>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>>> tools/libxl/libxlutil.h | 4 +++
>>>>> tools/libxl/xl_cmdimpl.c | 21 +++++++++++-
>>>>> 7 files changed, 203 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>>>>> index 408653f..9ed3055 100644
>>>>> --- a/docs/man/xl.cfg.pod.5
>>>>> +++ b/docs/man/xl.cfg.pod.5
>>>>> @@ -583,6 +583,36 @@ assigned slave device.
>>>>>
>>>>> =back
>>>>>
>>>>> +=item B<rdm=[ "TYPE", "RDM_RESERVE_STRING", ... ]>
>>>>> +
>>>>
>>>> Shouldn't this be "TYPE,RDM_RESERVE_STRIGN" according to your commit
>>>> message? If the only available config is just one string, you probably
>>>> don't need a list for this?
>>>
>>> Yes, based on that design we don't need a list. So
>>>
>>> =item B<rdm=[ "RDM_RESERVE_STRING" ]>
>>>
>>
>> Note that this is still a list (enclosed by "[]"). Maybe you mean
>>
>> rdm = "RDM_RESERVE_STRING"
>>
>> ?
>
> Yes, I'll do this.
>
>>
>>>>
>>>>> +(HVM/x86 only) Specifies the information about Reserved Device
>>>>> Memory (RDM),
>>>>> +which is necessary to enable robust device passthrough usage. One
>>>>> example of
>>>>> +RDM is reported through ACPI Reserved Memory Region Reporting (RMRR)
>>>>> +structure on x86 platform.
>>>>> +Each B<RDM_CHECK_STRING> has the form
>>>>> C<["TYPE",KEY=VALUE,KEY=VALUE,...> where:
>>>>> +
>>>>
>>>> RDM_CHECK_STRING?
>>>
>>> And here should be corrected like this,
>>>
>>> B<RDM_RESERVE_STRING> has the form ...
>>>
>>>>
>>>>> +=over 4
>>>>> +
>>>>> +=item B<"TYPE">
>>>>> +
>>>>> +Currently we just have one type. 'host' means all reserved device
>>>>> memory on
>>>>> +this platform should be reserved in this VM's pfn space.
>>>>> +
>>>>
>>>> What are other possible types? If there is only one type then we can
>>>
>>> Currently we just have one type and looks that design doesn't make this
>>> clear.
>>>
>>>> simply ignore the type?
>>>
>>> I just think we may introduce something else specific to live
>>> migration in
>>> the future... But I'm really not sure right now.
>>>
>>
>> Fair enough. I was just wondering if there would be any other types. If
>> so we do need provisioning.
>>
>> In any case, the "type" argument you proposed is a positional argument
>> (you require it to be the first element of the spec string").
>> I think you can just make it a key-value pair to make parsing easier.
>
> Do you mean this statement?
>
> =item B<rdm= "RDM_RESERVE_STRING" >
>
> ...
>
> B<RDM_RESERVE_STRING> has the form C<[KEY=VALUE,KEY=VALUE,...> where:
>
> =over 4
>
> =item B<KEY=VALUE>
>
> Possible B<KEY>s are:
>
> =over 4
>
> =item B<type="STRING">
>
> Currently we just have one type. "host" means all reserved device memory on
> this platform should be reserved in this VM's pfn space.
>
> =over 4
>
> =item B<reserve="STRING">
> ...
>
>
>>
>>>>
>>>>> +=item B<KEY=VALUE>
>>>>> +
>>>>> +Possible B<KEY>s are:
>>>>> +
>>>>> +=over 4
>>>>> +
>>>>> +=item B<reserve="STRING">
>>>>> +
>>>>> +Conflict may be detected when reserving reserved device memory in
>>>>> gfn space.
>>>>> +'force' means an unsolved conflict leads to immediate VM destroy,
>>>>> while
>>>>
>>>> Do you mean "immediate VM crash"?
>>>
>>> Yes. So I guess I should replace this.
>>>
>>>>
>>>>> +'try' allows VM moving forward with a warning message thrown out.
>>>>> 'try'
>>>>> +is default.
>>>>
>>>> Can you please your double quotes for "force", "try" etc.
>>>
>>> Sure. Just note we'd like to use "strict"/"relaxed" to replace
>>> "force"/"try"
>>> from next revision according to Jan's suggestion.
>>>
>>
>> No problem.
>>
>>>>
>>>>> +
>>>>> +Note this may be overrided by another sub item, rdm_reserve, in
>>>>> pci device.
>>>>> +
>>>>> =item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
>>>>>
>>>>> Specifies the host PCI devices to passthrough to this guest. Each
>>>>> B<PCI_SPEC_STRING>
>>>>> @@ -645,6 +675,20 @@ dom0 without confirmation. Please use with care.
>>>>> D0-D3hot power management states for the PCI device. False (0) by
>>>>> default.
>>>>>
>>>>> +=item B<rdm_check="STRING">
>>>>> +
>>>>> +(HVM/x86 only) Specifies the information about Reserved Device
>>>>> Memory (RDM),
>>>>> +which is necessary to enable robust device passthrough usage. One
>>>>> example of
>>>>> +RDM is reported through ACPI Reserved Memory Region Reporting (RMRR)
>>>>> +structure on x86 platform.
>>>>> +
>>>>> +Conflict may be detected when reserving reserved device memory in
>>>>> gfn space.
>>>>> +'force' means an unsolved conflict leads to immediate VM destroy,
>>>>> while
>>>>> +'try' allows VM moving forward with a warning message thrown out.
>>>>> 'force'
>>>>> +is default.
>>>>> +
>>>>> +Note this would override another global item, rdm = [''].
>>>>> +
>>>>
>>>> Note this would override global B<rdm> option.
>>>
>>> Fixed.
>>>
>>>>
>>>>> =back
>>>>>
>>>>> =back
>>>>> diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt
>>>>> index 9af0e99..d7434d6 100644
>>>>> --- a/docs/misc/vtd.txt
>>>>> +++ b/docs/misc/vtd.txt
>>>>> @@ -111,6 +111,40 @@ in the config file:
>>>>> To override for a specific device:
>>>>> pci = [ '01:00.0,msitranslate=0', '03:00.0' ]
>>>>>
>>>>> +RDM, 'reserved device memory', for PCI Device Passthrough
>>>>> +---------------------------------------------------------
>>>>> +
>>>>> +There are some devices the BIOS controls, for e.g. USB devices to
>>>>> perform
>>>>> +PS2 emulation. The regions of memory used for these devices are
>>>>> marked
>>>>> +reserved in the e820 map. When we turn on DMA translation, DMA to
>>>>> those
>>>>> +regions will fail. Hence BIOS uses RMRR to specify these regions
>>>>> along with
>>>>> +devices that need to access these regions. OS is expected to setup
>>>>> +identity mappings for these regions for these devices to access
>>>>> these regions.
>>>>> +
>>>>> +While creating a VM we should reserve them in advance, and avoid
>>>>> any conflicts.
>>>>> +So we introduce user configurable parameters to specify RDM
>>>>> resource and
>>>>> +according policies,
>>>>> +
>>>>> +To enable this globally, add "rdm" in the config file:
>>>>> +
>>>>> + rdm = [ 'host, reserve=force/try' ]
>>>>> +
>>>>
>>>> The "force/try" should be called "policy". And then you explain what
>>>> policies we have.
>>>
>>> Do you mean we should rename this?
>>>
>>> rdm = [ 'host, policy=force/try' ]
>>>
>>
>> No, I didn't ask you to rename that.
>>
>> The above line is an example which should reflect the correct syntax.
>> "force/try" is not the *actual syntax*, i.e. you won't write that in
>> your config file.
>>
>> I meant to changes it to "reserve=POLICY". Then you explain the possible
>> values of POLICY.
>>
>
> Understood so what about this,
>
> To enable this globally, add "rdm" in the config file:
>
> rdm = [ 'host, reserve=<POLICY>' ]
>
> Or just for a specific device:
>
> pci = [ '01:00.0,rdm_reserve=<POLICY>', '03:00.0' ]
>
> Global RDM parameter allows user to specify reserved regions explicitly.
> Using "host" to include all reserved regions reported on this platform
> which is good to handle hotplug scenario. In the future this parameter
> may be further extended to allow specifying random regions, e.g. even
> those belonging to another platform as a preparation for live migration
> with passthrough devices.
>
> Currently "POLICY" includes two options, "strict" and "relaxed". It
> decides how to handle conflict when reserving RDM regions in pfn space.
> If conflict ...
>
>>> This is really a policy but 'reserve' may can reflect our action
>>> explicitly,
>>> right?
>>>
>>>>
>>>>> +Or just for a specific device:
>>>>> +
>>>>> + pci = [ '01:00.0,rdm_reserve=force/try', '03:00.0' ]
>>>
>>> And you also can see this.
>>>
>>> But anyway, if you're really stick to rename this, I'm going to be
>>> fine as
>>> well but we should ping every one to check this point since this name is
>>> from our previous discussion.
>>>
>>>>> +
>>>>> +Global RDM parameter allows user to specify reserved regions
>>>>> explicitly.
>>>>> +Using 'host' to include all reserved regions reported on this
>>>>> platform
>>>>> +which is good to handle hotplug scenario. In the future this
>>>>> parameter
>>>>> +may be further extended to allow specifying random regions, e.g. even
>>>>> +those belonging to another platform as a preparation for live
>>>>> migration
>>>>> +with passthrough devices.
>>>>> +
>>>>> +'force/try' policy decides how to handle conflict when reserving RDM
>>>>> +regions in pfn space. If conflict exists, 'force' means an
>>>>> immediate error
>>>>> +so VM will be killed, while 'try' allows moving forward with a
>>>>> warning
>>>>
>>>> Be killed by whom? I think it's hvmloader crashes voluntarily, right?
>>>
>>> s/VM will be kille/hvmloader crashes voluntarily
>>>
>>>>
>>>>> +message thrown out.
>>>>> +
>>>>>
>>>>> Caveat on Conventional PCI Device Passthrough
>>>>> ---------------------------------------------
>>>>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>>>>> index 98687bd..9ed40d4 100644
>>>>> --- a/tools/libxl/libxl_create.c
>>>>> +++ b/tools/libxl/libxl_create.c
>>>>> @@ -1407,6 +1407,11 @@ static void domcreate_attach_pci(libxl__egc
>>>>> *egc, libxl__multidev *multidev,
>>>>> }
>>>>>
>>>>> for (i = 0; i < d_config->num_pcidevs; i++) {
>>>>> + /*
>>>>> + * If the rdm global policy is 'force' we should override
>>>>> each device.
>>>>> + */
>>>>> + if (d_config->b_info.rdm.reserve ==
>>>>> LIBXL_RDM_RESERVE_FLAG_FORCE)
>>>>> + d_config->pcidevs[i].rdm_reserve =
>>>>> LIBXL_RDM_RESERVE_FLAG_FORCE;
>>>>> ret = libxl__device_pci_add(gc, domid,
>>>>> &d_config->pcidevs[i], 1);
>>>>> if (ret < 0) {
>>>>> LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>>>>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>>>>> index 47af340..5786455 100644
>>>>> --- a/tools/libxl/libxl_types.idl
>>>>> +++ b/tools/libxl/libxl_types.idl
>>>>> @@ -71,6 +71,17 @@ libxl_domain_type = Enumeration("domain_type", [
>>>>> (2, "PV"),
>>>>> ], init_val = "LIBXL_DOMAIN_TYPE_INVALID")
>>>>>
>>>>> +libxl_rdm_reserve_type = Enumeration("rdm_reserve_type", [
>>>>> + (0, "none"),
>>>>> + (1, "host"),
>>>>> + ])
>>>>> +
>>>>> +libxl_rdm_reserve_flag = Enumeration("rdm_reserve_flag", [
>>>>> + (-1, "invalid"),
>>>>> + (0, "force"),
>>>>> + (1, "try"),
>>>>> + ])
>>>>
>>>> If you don't set init_val, the default value would be "force" (0),
>>>> is this
>>>
>>> Yes.
>>>
>>>> want you want?
>>>
>>> We have a little bit of complexity here,
>>>
>>> "Default per-device RDM policy is 'force', while default global RDM
>>> policy
>>> is 'try'. When both policies are specified on a given region, 'force' is
>>> always preferred."
>>>
>>
>> This is going to be done in actual code anyway.
>>
>> This type is used both in global and per-device setting, so I envisage
>
> Yes.
>
>> this to have an invalid value to start with. Appropriate default values
>
> Sounds I should set this,
>
> +libxl_rdm_reserve_flag = Enumeration("rdm_reserve_flag", [
> + (-1, "invalid"),
> + (0, "strict"),
> + (1, "relaxed"),
> + ], init_val = "LIBXL_RDM_RESERVE_FLAG_INVALID")
> +
>
>
>> should be done in libxl_TYPE_setdefault functions. And the logic to
>> detect conflict and preferences done in your construct function.
>>
>> What do you think?
>>
>>>>
>>>>> +
>>>>> libxl_channel_connection = Enumeration("channel_connection", [
>>>>> (0, "UNKNOWN"),
>>>>> (1, "PTY"),
>>>>> @@ -356,6 +367,11 @@ libxl_domain_sched_params =
>>>>> Struct("domain_sched_params",[
>>>>> ("budget", integer, {'init_val':
>>>>> 'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
>>>>> ])
>>>>>
>>>>> +libxl_rdm_reserve = Struct("rdm_reserve", [
>>>>> + ("type", libxl_rdm_reserve_type),
>>>>> + ("reserve", libxl_rdm_reserve_flag),
>>>>> + ])
>>>>> +
>>>>> libxl_domain_build_info = Struct("domain_build_info",[
>>>>> ("max_vcpus", integer),
>>>>> ("avail_vcpus", libxl_bitmap),
>>>>> @@ -401,6 +417,7 @@ libxl_domain_build_info =
>>>>> Struct("domain_build_info",[
>>>>> ("kernel", string),
>>>>> ("cmdline", string),
>>>>> ("ramdisk", string),
>>>>> + ("rdm", libxl_rdm_reserve),
>>>>> ("u", KeyedUnion(None, libxl_domain_type, "type",
>>>>> [("hvm", Struct(None, [("firmware", string),
>>>>> ("bios",
>>>>> libxl_bios_type),
>>>>> @@ -521,6 +538,7 @@ libxl_device_pci = Struct("device_pci", [
>>>>> ("power_mgmt", bool),
>>>>> ("permissive", bool),
>>>>> ("seize", bool),
>>>>> + ("rdm_reserve", libxl_rdm_reserve_flag),
>>>>> ])
>>>>>
>>>>> libxl_device_vtpm = Struct("device_vtpm", [
>>>>> diff --git a/tools/libxl/libxlu_pci.c b/tools/libxl/libxlu_pci.c
>>>>> index 26fb143..45be0d9 100644
>>>>> --- a/tools/libxl/libxlu_pci.c
>>>>> +++ b/tools/libxl/libxlu_pci.c
>>>>> @@ -42,6 +42,8 @@ static int pcidev_struct_fill(libxl_device_pci
>>>>> *pcidev, unsigned int domain,
>>>>> #define STATE_OPTIONS_K 6
>>>>> #define STATE_OPTIONS_V 7
>>>>> #define STATE_TERMINAL 8
>>>>> +#define STATE_TYPE 9
>>>>> +#define STATE_CHECK_FLAG 10
>>>>> int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev,
>>>>> const char *str)
>>>>> {
>>>>> unsigned state = STATE_DOMAIN;
>>>>> @@ -143,6 +145,17 @@ int xlu_pci_parse_bdf(XLU_Config *cfg,
>>>>> libxl_device_pci *pcidev, const char *str
>>>>> pcidev->permissive = atoi(tok);
>>>>> }else if ( !strcmp(optkey, "seize") ) {
>>>>> pcidev->seize = atoi(tok);
>>>>> + }else if ( !strcmp(optkey, "rdm_reserve") ) {
>>>>> + if ( !strcmp(tok, "force") ) {
>>>>> + pcidev->rdm_reserve =
>>>>> LIBXL_RDM_RESERVE_FLAG_FORCE;
>>>>> + } else if ( !strcmp(tok, "try") ) {
>>>>> + pcidev->rdm_reserve =
>>>>> LIBXL_RDM_RESERVE_FLAG_TRY;
>>>>> + } else {
>>>>> + pcidev->rdm_reserve =
>>>>> LIBXL_RDM_RESERVE_FLAG_FORCE;
>>>>> + XLU__PCI_ERR(cfg, "Unknown PCI RDM
>>>>> property flag value:"
>>>>> + " %s, so goes 'force' by
>>>>> default.",
>>>>
>>>> If this is not an error, you don't need XLU__PCI_ERR.
>>>>
>>>> But I would say we should just treat this as an error and
>>>> abort/exit/report (whatever the parser should do in this case).
>>>
>>> In our case we just want to post a message to set a appropriate flag to
>>> recover this behavior like we write here,
>>>
>>> XLU__PCI_ERR(cfg, "Unknown PCI RDM property
>>> flag
>>> value:"
>>> " %s, so goes 'strict' by
>>> default.",
>>> tok);
>>
>> I suggest we just abort in this case and not second guess what the admin
>> wants.
>
> Okay,
> } else {
> XLU__PCI_ERR(cfg, "%s is not an valid PCI RDM
> property"
> " flag: 'strict' or 'relaxed'.",
> tok);
> abort();
>
>
>>
>>>
>>> This may just be a warning? But I don't we have this sort of definition,
>>> XLU__PCI_WARN, ...
>>>
>>> So what LOG format can be adopted here?
>>
>> Feel free to introduce XLU__PCI_WARN if it turns out to be necessary.
>
> If it goes to abort(), I think XLU__PCI_ERR() should be good.
>
>>
>>>
>>>>
>>>>> + tok);
>>>>> + }
>>>>> }else{
>>>>> XLU__PCI_ERR(cfg, "Unknown PCI BDF option:
>>>>> %s", optkey);
>>>>> }
>>>>> @@ -167,6 +180,71 @@ parse_error:
>>>>> return ERROR_INVAL;
>>>>> }
>>>>>
>>>>> +int xlu_rdm_parse(XLU_Config *cfg, libxl_rdm_reserve *rdm, const
>>>>> char *str)
>>>>> +{
>>>>> + unsigned state = STATE_TYPE;
>>>>> + char *buf2, *tok, *ptr, *end;
>>>>> +
>>>>> + if ( NULL == (buf2 = ptr = strdup(str)) )
>>>>> + return ERROR_NOMEM;
>>>>> +
>>>>> + for(tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++) {
>>>>> + switch(state) {
>>
>> Coding style. I haven't checked what actual style this file uses, but
>> there is inconsistency in this function by itself.
>
> I just refer to xlu_pci_parse_bdf() to generate xlu_rdm_parse(), and
> they are in the same file...
>
> Anyway, I should change this line,
>
> for ( tok = ptr, end = ptr + strlen(ptr) + 1; ptr < end; ptr++ ) {
>
>>
>>>>> + case STATE_TYPE:
>>>>> + if ( *ptr == '\0' || *ptr == ',' ) {
>>>>> + state = STATE_CHECK_FLAG;
>>>>> + *ptr = '\0';
>>>>> + if ( !strcmp(tok, "host") ) {
>>>>> + rdm->type = LIBXL_RDM_RESERVE_TYPE_HOST;
>>>>> + } else {
>>>>> + XLU__PCI_ERR(cfg, "Unknown RDM state option:
>>>>> %s", tok);
>>>>> + goto parse_error;
>>>>> + }
>>>>> + tok = ptr + 1;
>>>>> + }
>>>>> + break;
>>>>> + case STATE_CHECK_FLAG:
>>>>> + if ( *ptr == '=' ) {
>>>>> + state = STATE_OPTIONS_V;
>>>>> + *ptr = '\0';
>>>>> + if ( strcmp(tok, "reserve") ) {
>>>>> + XLU__PCI_ERR(cfg, "Unknown RDM property value:
>>>>> %s", tok);
>>>>> + goto parse_error;
>>>>> + }
>>>>> + tok = ptr + 1;
>>>>> + }
>>>>> + break;
>>>>> + case STATE_OPTIONS_V:
>>>>> + if ( *ptr == ',' || *ptr == '\0' ) {
>>>>> + state = STATE_TERMINAL;
>>>>> + *ptr = '\0';
>>>>> + if ( !strcmp(tok, "force") ) {
>>>>> + rdm->reserve = LIBXL_RDM_RESERVE_FLAG_FORCE;
>>>>> + } else if ( !strcmp(tok, "try") ) {
>>>>> + rdm->reserve = LIBXL_RDM_RESERVE_FLAG_TRY;
>>>>> + } else {
>>>>> + XLU__PCI_ERR(cfg, "Unknown RDM property flag
>>>>> value: %s",
>>>>> + tok);
>>>>> + goto parse_error;
>>>>> + }
>>>>> + tok = ptr + 1;
>>>>> + }
>>>>> + default:
>>>>> + break;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + free(buf2);
>>>>> +
>>>>> + if ( tok != ptr || state != STATE_TERMINAL )
>>>>> + goto parse_error;
>>>>> +
>>>>> + return 0;
>>>>> +
>>>>> +parse_error:
>>>>> + return ERROR_INVAL;
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * Local variables:
>>>>> * mode: C
>>>>> diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
>>>>> index 0333e55..80497f8 100644
>>>>> --- a/tools/libxl/libxlutil.h
>>>>> +++ b/tools/libxl/libxlutil.h
>>>>> @@ -93,6 +93,10 @@ int xlu_disk_parse(XLU_Config *cfg, int nspecs,
>>>>> const char *const *specs,
>>>>> */
>>>>> int xlu_pci_parse_bdf(XLU_Config *cfg, libxl_device_pci *pcidev,
>>>>> const char *str);
>>>>>
>>>>> +/*
>>>>> + * RDM parsing
>>>>> + */
>>>>> +int xlu_rdm_parse(XLU_Config *cfg, libxl_rdm_reserve *rdm, const
>>>>> char *str);
>>>>>
>>>>> /*
>>>>> * Vif rate parsing.
>>>>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>>>>> index 04faf98..9a58464 100644
>>>>> --- a/tools/libxl/xl_cmdimpl.c
>>>>> +++ b/tools/libxl/xl_cmdimpl.c
>>>>> @@ -988,7 +988,7 @@ static void parse_config_data(const char
>>>>> *config_source,
>>>>> const char *buf;
>>>>> long l;
>>>>> XLU_Config *config;
>>>>> - XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids,
>>>>> *vtpms;
>>>>> + XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids,
>>>>> *vtpms, *rdms;
>>>>> XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian;
>>>>> int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian;
>>>>> int pci_power_mgmt = 0;
>>>>> @@ -1727,6 +1727,23 @@ skip_vfb:
>>>>> xlu_cfg_get_defbool(config, "e820_host",
>>>>> &b_info->u.pv.e820_host, 0);
>>>>> }
>>>>>
>>>>> + /*
>>>>> + * By default our global policy is to query all rdm entries, and
>>>>> + * force reserve them.
>>>>> + */
>>>>> + b_info->rdm.type = LIBXL_RDM_RESERVE_TYPE_HOST;
>>>>> + b_info->rdm.reserve = LIBXL_RDM_RESERVE_FLAG_TRY;
>>>>
>>>> This should probably to into the _setdefault function of
>>>> libxl_domain_build_info.
>>>
>>> Sorry, I just see this
>>>
>>> libxl_domain_build_info_init()
>>> |
>>> + libxl_rdm_reserve_init(&p->rdm);
>>> |
>>> + memset(p, '\0', sizeof(*p));
>>>
>>> But this should be generated automatically, right? So how to
>>> implement your
>>> idea? Could you give me a show?
>>>
>>
>> Check libxl_domain_build_info_setdefault.
>>
>> To use libxl types. You normally do:
>>
>> libxl_TYPE_init
>> libxl_TYPE_setdefault
>>
>> DO STUFF
>>
>> libxl_TYPE_dispose
>>
>> _init and _dispose are auto-generated. _setdefault is not.
>
> So in our case, maybe we can do this,
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f0da7dc..461606c 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -100,6 +100,17 @@ static int sched_params_valid(libxl__gc *gc,
> return 1;
> }
>
> +void libxl__device_rdm_setdefault(libxl__gc *gc,
> + libxl_domain_build_info *b_info)
> +{
> + /*
> + * By default our global policy is to query all rdm entries, and
> + * force reserve them.
> + */
> + b_info->rdm.type = LIBXL_RDM_RESERVE_TYPE_HOST;
> + b_info->rdm.reserve = LIBXL_RDM_RESERVE_FLAG_STRICT;
> +}
> +
> int libxl__domain_build_info_setdefault(libxl__gc *gc,
> libxl_domain_build_info *b_info)
> {
> @@ -410,6 +421,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
> libxl_domain_type_to_string(b_info->type));
> return ERROR_INVAL;
> }
> +
> + libxl__device_rdm_setdefault(gc, b_info);
> return 0;
> }
>
>
>>
>>>>
>>>>> + if (!xlu_cfg_get_list (config, "rdm", &rdms, 0, 0)) {
>>>>> + if ((buf = xlu_cfg_get_listitem (rdms, 0)) != NULL ) {
>>>>> + libxl_rdm_reserve rdm;
>>>>> + if (!xlu_rdm_parse(config, &rdm, buf))
>>>>> + {
>>>>> + b_info->rdm.type = rdm.type;
>>>>> + b_info->rdm.reserve = rdm.reserve;
>>>>> + }
>>>>
>>>> You only have one rdm in b_info, so there is no need to use a list for
>>>> it in config file.
>>>>
>>>
>>> Is this fine?
>>>
>>> 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;
>>>
>>> }
>>> }
>>>
>>
>> I think it is fine. But you'd better wait a little bit for other people
>> to voice their opinions.
>>
>
> Sure.
>
> Thanks
> Tiejun
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>
next prev parent reply other threads:[~2015-05-18 1:06 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 9:21 [RFC][PATCH 00/13] Fix RMRR Tiejun Chen
2015-04-10 9:21 ` [RFC][PATCH 01/13] tools: introduce some new parameters to set rdm policy Tiejun Chen
2015-05-08 13:04 ` Wei Liu
2015-05-11 5:35 ` Chen, Tiejun
2015-05-11 14:54 ` Wei Liu
2015-05-15 1:52 ` Chen, Tiejun
2015-05-18 1:06 ` Chen, Tiejun [this message]
2015-05-18 19:17 ` Wei Liu
2015-05-19 3:16 ` Chen, Tiejun
2015-05-19 9:42 ` Wei Liu
2015-05-19 10:50 ` Chen, Tiejun
2015-05-19 11:00 ` Wei Liu
2015-05-20 5:27 ` Chen, Tiejun
2015-05-20 8:36 ` Wei Liu
2015-05-20 8:51 ` Chen, Tiejun
2015-05-20 9:07 ` Wei Liu
2015-04-10 9:21 ` [RFC][PATCH 02/13] introduce XENMEM_reserved_device_memory_map Tiejun Chen
2015-04-16 14:59 ` Tim Deegan
2015-04-16 15:10 ` Jan Beulich
2015-04-16 15:24 ` Tim Deegan
2015-04-16 15:40 ` Tian, Kevin
2015-04-23 12:32 ` Chen, Tiejun
2015-04-23 12:59 ` Jan Beulich
2015-04-24 1:17 ` Chen, Tiejun
2015-04-24 7:21 ` Jan Beulich
2015-04-10 9:21 ` [RFC][PATCH 03/13] tools/libxc: Expose new hypercall xc_reserved_device_memory_map Tiejun Chen
2015-05-08 13:07 ` Wei Liu
2015-05-11 5:36 ` Chen, Tiejun
2015-05-11 9:50 ` Wei Liu
2015-04-10 9:21 ` [RFC][PATCH 04/13] tools/libxl: detect and avoid conflicts with RDM Tiejun Chen
2015-04-15 13:10 ` Ian Jackson
2015-04-15 18:22 ` Tian, Kevin
2015-04-23 12:31 ` Chen, Tiejun
2015-04-20 11:13 ` Jan Beulich
2015-05-06 15:00 ` Chen, Tiejun
2015-05-06 15:34 ` Jan Beulich
2015-05-07 2:22 ` Chen, Tiejun
2015-05-07 6:04 ` Jan Beulich
2015-05-08 1:14 ` Chen, Tiejun
2015-05-08 1:24 ` Chen, Tiejun
2015-05-08 15:13 ` Wei Liu
2015-05-11 6:06 ` Chen, Tiejun
2015-05-08 14:43 ` Wei Liu
2015-05-11 8:09 ` Chen, Tiejun
2015-05-11 11:32 ` Wei Liu
2015-05-14 8:27 ` Chen, Tiejun
2015-05-18 1:06 ` Chen, Tiejun
2015-05-18 20:00 ` Wei Liu
2015-05-19 1:32 ` Tian, Kevin
2015-05-19 10:22 ` Wei Liu
2015-05-19 6:47 ` Chen, Tiejun
2015-04-10 9:21 ` [RFC][PATCH 05/13] xen/x86/p2m: introduce set_identity_p2m_entry Tiejun Chen
2015-04-16 15:05 ` Tim Deegan
2015-04-23 12:33 ` Chen, Tiejun
2015-04-10 9:21 ` [RFC][PATCH 06/13] xen:vtd: create RMRR mapping Tiejun Chen
2015-04-16 15:16 ` Tim Deegan
2015-04-16 15:50 ` Tian, Kevin
2015-04-10 9:21 ` [RFC][PATCH 07/13] xen/passthrough: extend hypercall to support rdm reservation policy Tiejun Chen
2015-04-16 15:40 ` Tim Deegan
2015-04-23 12:32 ` Chen, Tiejun
2015-04-23 13:05 ` Tim Deegan
2015-04-23 13:59 ` Jan Beulich
2015-04-23 14:26 ` Tim Deegan
2015-05-04 8:15 ` Tian, Kevin
2015-04-20 13:36 ` Jan Beulich
2015-05-11 8:37 ` Chen, Tiejun
2015-05-08 16:07 ` Julien Grall
2015-05-11 8:42 ` Chen, Tiejun
2015-05-11 9:51 ` Julien Grall
2015-05-11 10:57 ` Jan Beulich
2015-05-14 5:48 ` Chen, Tiejun
2015-05-14 20:13 ` Jan Beulich
2015-05-14 5:47 ` Chen, Tiejun
2015-05-14 10:19 ` Julien Grall
2015-04-10 9:21 ` [RFC][PATCH 08/13] tools: extend xc_assign_device() " Tiejun Chen
2015-04-20 13:39 ` Jan Beulich
2015-05-11 9:45 ` Chen, Tiejun
2015-05-11 10:53 ` Jan Beulich
2015-05-14 7:04 ` Chen, Tiejun
2015-04-10 9:22 ` [RFC][PATCH 09/13] xen: enable XENMEM_set_memory_map in hvm Tiejun Chen
2015-04-16 15:42 ` Tim Deegan
2015-04-20 13:46 ` Jan Beulich
2015-05-15 2:33 ` Chen, Tiejun
2015-05-15 6:12 ` Jan Beulich
2015-05-15 6:24 ` Chen, Tiejun
2015-05-15 6:35 ` Jan Beulich
2015-05-15 6:59 ` Chen, Tiejun
2015-04-10 9:22 ` [RFC][PATCH 10/13] tools: extend XENMEM_set_memory_map Tiejun Chen
2015-04-10 10:01 ` Wei Liu
2015-04-13 2:09 ` Chen, Tiejun
2015-04-13 11:02 ` Wei Liu
2015-04-14 0:42 ` Chen, Tiejun
2015-05-05 9:32 ` Wei Liu
2015-04-20 13:51 ` Jan Beulich
2015-05-15 2:57 ` Chen, Tiejun
2015-05-15 6:16 ` Jan Beulich
2015-05-15 7:09 ` Chen, Tiejun
2015-05-15 7:32 ` Jan Beulich
2015-05-15 7:51 ` Chen, Tiejun
2015-04-10 9:22 ` [RFC][PATCH 11/13] hvmloader: get guest memory map into memory_map[] Tiejun Chen
2015-04-20 13:57 ` Jan Beulich
2015-05-15 3:10 ` Chen, Tiejun
2015-04-10 9:22 ` [RFC][PATCH 12/13] hvmloader/pci: skip reserved ranges Tiejun Chen
2015-04-20 14:21 ` Jan Beulich
2015-05-15 3:18 ` Chen, Tiejun
2015-05-15 6:19 ` Jan Beulich
2015-05-15 7:34 ` Chen, Tiejun
2015-05-15 7:44 ` Jan Beulich
2015-05-15 8:16 ` Chen, Tiejun
2015-05-15 8:31 ` Jan Beulich
2015-05-15 9:21 ` Chen, Tiejun
2015-05-15 9:32 ` Jan Beulich
2015-04-10 9:22 ` [RFC][PATCH 13/13] hvmloader/e820: construct guest e820 table Tiejun Chen
2015-04-20 14:29 ` Jan Beulich
2015-05-15 6:11 ` Chen, Tiejun
2015-05-15 6:25 ` Jan Beulich
2015-05-15 6:39 ` Chen, Tiejun
2015-05-15 6:56 ` Jan Beulich
2015-05-15 7:11 ` Chen, Tiejun
2015-05-15 7:34 ` Jan Beulich
2015-05-15 8:00 ` Chen, Tiejun
2015-05-15 8:12 ` Jan Beulich
2015-05-15 8:47 ` Chen, Tiejun
2015-05-15 8:54 ` Jan Beulich
2015-05-15 9:18 ` Chen, Tiejun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55593B15.6050600@intel.com \
--to=tiejun.chen@intel.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=kevin.tian@intel.com \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).