[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 Wed, May 20, 2015 at 04:51:44PM +0800, Chen, Tiejun wrote:
> 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.

Makes sense. Thanks for your reply.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.