On 26/11/2019 11:30, Paul Durrant wrote:
> On Wed, 13 Nov 2019 at 13:55, Paul Durrant <pdurr...@amazon.com> wrote:
>> ...when their values are larger than the per-domain configured limits.
>>
>> Signed-off-by: Paul Durrant <pdurr...@amazon.com>
>> ---
>> Cc: Andrew Cooper <andrew.coop...@citrix.com>
>> Cc: George Dunlap <george.dun...@eu.citrix.com>
>> Cc: Ian Jackson <ian.jack...@eu.citrix.com>
>> Cc: Jan Beulich <jbeul...@suse.com>
>> Cc: Julien Grall <jul...@xen.org>
>> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
>> Cc: Stefano Stabellini <sstabell...@kernel.org>
>> Cc: Wei Liu <w...@xen.org>
>>
>> After mining through commits it is still unclear to me exactly when Xen
>> stopped honouring the global values, but I really think this commit should
>> be back-ported to stable trees as it was a behavioural change that can
>> cause domUs to fail in non-obvious ways.
> Any other opinions on this? AFAICT questions is still open:
>
> - Do we consider not honouring the command line values to be a
> regression (since domUs that would have worked before will no longer
> work after a basic upgrade of Xen)?

I think I've been very clear on my opinion of this patch, and what I
would consider an acceptable way forward.

This patch breaks things in exactly the (opposite) way you are
complaining about having happened when the Xen command line options were
replaced with xl.conf options for domU.

Yes - it wasn't great to have done things like this.  No - its not
acceptable to do the same again and break people now relying on the per
domain settings to take effect.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to