Re: [PATCH v2 1/2] x86/dom0: rename paging function

From: "Jan Beulich" <JBeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	andrei.semenov@bertin.fr, Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 1/2] x86/dom0: rename paging function
Date: Tue, 29 Jan 2019 08:38:08 -0700	[thread overview]
Message-ID: <5C507360020000780021216D@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <812B19D1020000B00063616D@prv1-mh.provo.novell.com>

>>> On 29.01.19 at 16:02, <roger.pau@citrix.com> wrote:
> On Thu, Dec 13, 2018 at 07:47:59AM -0700, Jan Beulich wrote:
>> >>> On 13.12.18 at 15:20, <roger.pau@citrix.com> wrote:
>> > On Thu, Dec 13, 2018 at 03:17:05AM -0700, Jan Beulich wrote:
>> >> >>> On 13.12.18 at 10:14, <roger.pau@citrix.com> wrote:
>> >> > On Thu, Dec 13, 2018 at 12:45:07AM -0700, Jan Beulich wrote:
>> >> >> >>> On 12.12.18 at 18:05, <roger.pau@citrix.com> wrote:
>> >> >> > On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beulich wrote:
>> >> >> >> The MMIO side of things of course still remains unclear.
>> >> >> > 
>> >> >> > Right, for the MMIO and the handling of grant and foreign mappings it's
>> >> >> > not clear how we want to proceed.
>> >> >> > 
>> >> >> > Maybe account for all host RAM (total_pages) plus MMIO BARs?
>> >> >> 
>> >> >> Well, I thought we've already settled on it being impossible to
>> >> >> account for all MMIO BARs at this point.
>> >> > 
>> >> > Well, I could iterate over all the registered PCI devices and size
>> >> > the BARs (without VF BARs at least initially). This is quite
>> >> > cumbersome, my other option would be using max_page and hope that
>> >> > there are enough holes to make up for BAR MMIO regions.
>> >> 
>> >> Well, maybe we could live with this for now. I certainly would
>> >> prefer to have a 3rd opinion though, as I continue to feel uneasy
>> >> with this rather imprecise estimation (i.e. I'd much prefer a more
>> >> dynamic / on-demand approach).
>> > 
>> > I agree it's not a perfect solution, but I think what's currently done
>> > is even worse, and we already had bug reports of users seeing Xen
>> > panic at PVH Dom0 build time if no dom0_mem parameter is specified.
>> > 
>> > Would you be OK with using max_page then?
>> 
>> I'm not going to say yes or no here without having seen a (qualified)
>> 3rd opinion.
> 
> I would like to get this fixed. The current code for accounting the
> memory required for the paging structures is wrong, I've received
> several reports (most of them privately) of the dom0 builder running
> out of memory, thus leading to a panic.
> 
> I'm open to suggestions.

I'm afraid I'm the wrong addressee: I can't provide the asked
for 3rd opinion. And if others think going from one often
breaking solution to another, less often (but still) breaking
one is a good idea, I won't block a change along those lines
from going in. But it is kind of hard for me to understand why
we would do such, instead of eliminating the problem
altogether. Granted this may involve more intrusive a change.

In any event PVH Dom0 is still experimental, and hence
requiring people to use dom0_mem= for the time being does
not seem overly unfriendly to me.

Jan

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