xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [v5][PATCH 10/16] tools: introduce some new parameters to set rdm policy
Date: Tue, 07 Jul 2015 20:03:54 +0800	[thread overview]
Message-ID: <559BC02A.6090604@intel.com> (raw)
In-Reply-To: <21915.48185.41230.587033@mariner.uk.xensource.com>

>> Global RDM parameter, "type", allows user to specify reserved regions
>> explicitly, e.g. using 'host' to include all reserved regions reported
>
> As I understand this feature, I don't think the name `type' is right.
> This is a method for handling or overriding/ignoring the RDM problem.
>
> Perhaps `handling=' or `strategy=' ?

Okay, I prefer to use 'strategy='.

>
> And `none' seems quite an innocuous name for such a dangerous
> setting.  How about `ignore' ?
>
>> 'strict/relaxed' policy decides how to handle conflict when reserving RDM
>> regions in pfn space. If conflict exists, 'strict' means an immediate error
>> so VM can't keep running, while 'relaxed' allows moving forward with a
>> warning message thrown out.
>>
>> Default per-device RDM policy is 'strict', while default global RDM policy
>> is 'relaxed'. And the per-device policy would override the global policy like
>> others.
>
> I don't think these two sentences can both be true.  If the per-device
> policy overrides the global policy, then the per-device policy must
> have at least three values: `strict', `relaxed', and `not set'
> (implicitly using global policy).

Yeah. The per-device policy is first set as the global policy. This 
behavior is same as other pci option. Please see the last patch,

@@ -1937,6 +1945,11 @@ skip_vfb:
              pcidev->power_mgmt = pci_power_mgmt;
              pcidev->permissive = pci_permissive;
              pcidev->seize = pci_seize;
+            /*
+             * Like other pci option, the per-device policy always follows
+             * the global policy by default.
+             */
+            pcidev->rdm_reserve = b_info->u.hvm.rdm.reserve;
              if (!xlu_pci_parse_bdf(config, pcidev, buf))
                  d_config->num_pcidevs++;
          }

>
> Perhaps I have misunderstood.
>
>> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
>> index a3e0e2e..a2dc343 100644
>> --- a/docs/man/xl.cfg.pod.5
>> +++ b/docs/man/xl.cfg.pod.5
>> @@ -655,6 +655,83 @@ assigned slave device.
> ...
>> +=item B<type="STRING">
>
> The documentation on this is rather vague about what the default is.
> But you do say:
>
>> +In this conflict case,
>> +
>> +#1. If the type options is set with "none",
>> +
>> +rdm = "type=none,reserve=strict" or rdm = "type=none,reserve=relaxed"
>> +
>> +mean we don't handle any conflict just to make VM keep running as before.
>> +Note this is our default behavior.
>
> This suggests that the default is "do the dangerous thing".  That
> doesn't seem right.

As I discussed with Campbell we'd like not to expose "none" in xl level 
since this is equivalent to that case we don't set anything.

>
>> +#2. If the type options is set with "host",
>> +
>> +rdm = "type=host,reserve=strict" or rdm = "type=host,reserve=relaxed"
> ...
>> +"relaxed" allows a VM to be created to keep running with a warning message
>> +thrown out. But this may crash this VM if this device accesses RDM. For example,
>> +Windows IGD GFX driver always access these regions so this lead to a blue screen
>> +to crash VM in such a case.
>
> The difference between
>     type=host,reserve=relaxed
> and
>     type=none
> is simply whether a warning is printed ?
>

"none" means we have a chance to work as before since not all devices 
own RDM. But as I said above this is same as !rdm.

Thanks
Tiejun

  reply	other threads:[~2015-07-07 12:03 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07  6:17 [v5][PATCH 00/16] Fix RMRR Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 01/16] xen: introduce XENMEM_reserved_device_memory_map Tiejun Chen
2015-07-07 11:17   ` Ian Jackson
2015-07-07 12:46     ` Jan Beulich
2015-07-07 13:23       ` Ian Jackson
2015-07-07 14:05         ` Jan Beulich
2015-07-07 21:32           ` Chen, Tiejun
2015-07-08  6:25             ` Jan Beulich
2015-07-07  6:17 ` [v5][PATCH 02/16] xen/vtd: create RMRR mapping Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 03/16] xen/passthrough: extend hypercall to support rdm reservation policy Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 04/16] xen: enable XENMEM_memory_map in hvm Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 05/16] hvmloader: get guest memory map into memory_map[] Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 06/16] hvmloader/pci: skip reserved ranges Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 07/16] hvmloader/e820: construct guest e820 table Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 08/16] tools/libxc: Expose new hypercall xc_reserved_device_memory_map Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 09/16] tools: extend xc_assign_device() to support rdm reservation policy Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 10/16] tools: introduce some new parameters to set rdm policy Tiejun Chen
2015-07-07 10:21   ` Wei Liu
2015-07-08  0:54     ` Chen, Tiejun
2015-07-08  8:32       ` Ian Campbell
2015-07-08  9:06         ` Chen, Tiejun
2015-07-08  9:17           ` Ian Campbell
2015-07-07 11:47   ` Ian Jackson
2015-07-07 12:03     ` Chen, Tiejun [this message]
2015-07-07 12:14       ` Ian Jackson
2015-07-07 12:31         ` Chen, Tiejun
2015-07-07 13:26           ` Ian Jackson
2015-07-07 13:53             ` Chen, Tiejun
2015-07-07 14:16               ` Ian Jackson
2015-07-07 14:40               ` Ian Jackson
2015-07-07 15:16                 ` Chen, Tiejun
2015-07-07 15:39                   ` Chen, Tiejun
2015-07-07 17:08                   ` Ian Jackson
2015-07-07 21:45                     ` Chen, Tiejun
2015-07-07  6:17 ` [v5][PATCH 11/16] tools/libxl: detect and avoid conflicts with RDM Tiejun Chen
2015-07-07 11:20   ` Wei Liu
2015-07-07 11:51   ` Ian Jackson
2015-07-07 12:08     ` Wei Liu
2015-07-07 12:16       ` Ian Jackson
2015-07-07 11:57   ` Ian Jackson
2015-07-07 14:52     ` Chen, Tiejun
2015-07-07 14:57       ` Ian Jackson
2015-07-07 15:27         ` Chen, Tiejun
2015-07-07 16:01           ` Ian Jackson
2015-07-07  6:17 ` [v5][PATCH 12/16] tools: introduce a new parameter to set a predefined rdm boundary Tiejun Chen
2015-07-07 11:22   ` Wei Liu
2015-07-07  6:17 ` [v5][PATCH 13/16] libxl: construct e820 map with RDM information for HVM guest Tiejun Chen
2015-07-07  9:03   ` Wei Liu
2015-07-07  6:17 ` [v5][PATCH 14/16] xen/vtd: enable USB device assignment Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 15/16] xen/vtd: prevent from assign the device with shared rmrr Tiejun Chen
2015-07-07  6:17 ` [v5][PATCH 16/16] tools: parse to enable new rdm policy parameters Tiejun Chen

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=559BC02A.6090604@intel.com \
    --to=tiejun.chen@intel.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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).