Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [Xen-devel] ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to
 valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79!
To:     Craig Bergstrom <craigb@google.com>
CC:     Sander Eikelenboom <linux@eikelenboom.it>,
        Ingo Molnar <mingo@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        <linux-kernel@vger.kernel.org>,
        Xen-devel <xen-devel@lists.xen.org>, <wfg@linux.intel.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>,
        Juergen Gross <JGross@suse.com>
References: <20171024024439.u3ywfgvi67fe4mbg@wfg-t540p.sh.intel.com>
 <c5082661-99a4-1b11-c8a1-8b31e9ab8d95@oracle.com>
 <CAOJUGyfTM2J-P29yPhUx2A2SDjA0rv972SE0hmbMHonthMd_bQ@mail.gmail.com>
 <440615a7-6cc0-a607-ce7c-22a34b69e8fe@eikelenboom.it>
 <1d203c07-0595-a33a-620b-c51eea9721d1@eikelenboom.it>
 <8721eeac-a644-e815-55e9-5f01956dd22a@eikelenboom.it>
 <CAOJUGye8nXL-J9oArLLMFz-RPRdKFe6EgqtYPSr5kcWoH2EodQ@mail.gmail.com>
 <20171026163911.dnovh4zaik5qumtt@gmail.com>
 <CAOJUGycO494NcvJk89MMub9Tbrj6FUoSNN4SOci7NgJRKq7v=A@mail.gmail.com>
 <207b6a75-2eff-8e92-d50c-ec2022fddbf9@eikelenboom.it>
From:   Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <19584771-c653-5327-b126-3f494ad5717f@citrix.com>
Date:   Thu, 26 Oct 2017 21:01:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <207b6a75-2eff-8e92-d50c-ec2022fddbf9@eikelenboom.it>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 26/10/17 20:29, Sander Eikelenboom wrote:
> On 26/10/17 19:49, Craig Bergstrom wrote:
>> Sander, thanks for the details, they've been very useful.
>>
>> I suspect that your host system's mem=2048M parameter is causing the
>> problem.  Any chance you can confirm by removing the parameter and
>> running the guest code path?
> I removed it, but kept the hypervisor limiting dom0 memory to 2046M intact (in grub using the xen bootcmd: 
> "multiboot       /xen-4.10.gz  dom0_mem=2048M,max:2048M ....."
>
> Unfortunately that doesn't change anything, the guest still fails to start with the same errors.
>
>> More specifically, since you're telling the kernel that it's high
>> memory address is at 2048M and your device is at 0xfe1fe000 (~4G), the
>> new mmap() limits are preventing you from mapping addresses that are
>> explicitly disallowed by the parameter.
>>
> Which would probably mean the current patch prohibits hard limiting the dom0 memory to a certain value (below 4G)
> at least in combination with PCI-passthrough. So the only thing left would be to have no hard memory restriction on dom0
> and rely on auto-ballooning, but I'm not a great fan of that.
>
> I don't know how KVM handles setting memory limits for the host system, but perhaps it suffers from the same issue.
>
> I also tried the patch from one of your last mails to make the check "less strict", 
> but still get the same errors (when using the hard memory limits).

dom0_mem=2048M,max:2048M is used to describe how much RAM the guest has,
not its maximum address.  (Whether this is how PVops actually interprets
the information and passes it into Linux is a different matter.  I will
have to defer to Boris/Juergen on that side of things.)

For RAM, PV guests will get a scattering of frames wherever Xen chooses
to allocate them, and are likely to not be contiguous or adjacent.

For devices, PV guests do get mappings to the real system BARs, which
will be the real low and high MMIO holes.

~Andrew

From 1582350977146157131@xxx Thu Oct 26 19:51:26 +0000 2017
X-GM-THRID: 1582105239086831553
X-Gmail-Labels: Inbox,Category Forums