[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC][PATCH 01/13] tools: introduce some new parameters to set rdm policy



On 2015/5/20 16:36, Wei Liu wrote:
On Wed, May 20, 2015 at 01:27:56PM +0800, Chen, Tiejun wrote:
[...]
We have this definition,

+libxl_rdm_reserve_type = Enumeration("rdm_reserve_type", [
+    (0, "none"),
+    (1, "host"),
+    ])

If we set 'type=none', this means we would do nothing actually since we
don't expose any rdms to guest. This behavior will ensue we go back the
existing scenario without our patch.


But this only works with global configuration and individual
configuration in PCI spec trumps this, right?

You're right.


Think about how an old configuration migrated to newer version of Xen
should work. For example, I don't have rdm= but have pci=['xxxx']. Do we
need to make sure this still work? I guess the answer is if it already

Definitely.

works before RDM it should continue to work as there is really no
conflict before. In this case whether  we enable RDM or not doesn't make
a difference to a guest that's already working before. Am I right?


You haven't answered this question...  I'm trying to determine what
should be a sensible default value.

I think I should say 'no' here. RDM (RMRR) already exists and its also being enabled before I'm trying to introduce this series of patch. But we have some legacy or potential problems to really work well with RMRR.


If the answer to that question is "yes", then we should enable RDM by
default, because it does no harm to guests that are already working and
fix problem for the guests that are not working; if the answer is "no"
or "not sure", we should use "none". Don't worry, we can change the
default value later if necessary.


So we're going to the latter :)

Using "none" as default leaves us on the safe side but it would make it
less nicer to use Xen. But well, safety comes first.

Actually RMRR doesn't matter in most cases unless you're trying to do pass through with a device which owns RMRR and also really use RMRR indeed. So from my point of view, I agree "NONE" should be default since we really should make sure we have a way to approach our original behavior in accordance with your concern.

Thanks
Tiejun


Wei.

I think we can set the default 'type' to NONE,

libxl__rdm_setdefault()
{
     b_info->rdm.type = LIBXL_RDM_RESERVE_TYPE_NONE;

and then,

libxl__domain_device_construct_rdm()
{
     ...
     /* Might not expose rdm. */
     if (type == LIBXL_RDM_RESERVE_TYPE_NONE)
        return 0;

This means we don't expose any rdm so we would never concern any policy
anymore.


Thanks
Tiejun




_______________________________________________
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®.