Re: Design doc of adding ACPI support for arm64 on Xen - version 5

From: Ian Campbell <ian.campbell@citrix.com>
To: Julien Grall <julien.grall@citrix.com>,
	Shannon Zhao <shannon.zhao@linaro.org>,
	Shannon Zhao <zhaoshenglong@huawei.com>,
	xen-devel <xen-devel@lists.xen.org>
Cc: Hangaohuai <hangaohuai@huawei.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	andrew@fubar.geek.nz,
	"Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Parth Dixit <parth.dixit@linaro.org>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: Design doc of adding ACPI support for arm64 on Xen - version 5
Date: Wed, 2 Sep 2015 14:26:04 +0100	[thread overview]
Message-ID: <1441200364.26292.190.camel@citrix.com> (raw)
In-Reply-To: <55E6F110.7010704@citrix.com>

On Wed, 2015-09-02 at 13:52 +0100, Julien Grall wrote:
> On 02/09/15 13:02, Shannon Zhao wrote:
> > > Hold on, this is about Linux able to use the memory for his own 
> > > usage.
> > > ACPI table are not part of this memory because they are marked 
> > > reserved
> > > by the firmware.
> > > 
> > > If we follow your logic, all ACPI tables always should be above the
> > > kernel. I don't believe this is the case and it would be buggy on Xen
> > > because of the DOM0 direct RAM mapping (i.e the first RAM bank can be
> > > very high and the kernel too).
> > > 
> > 
> > It looks weird. But from the booting.txt, it says the memory below base
> > address is unusable and from early_init_dt_add_memory_arch in Linux, it
> > really ignores the memblock below the PAGE_OFFSET.
> 
> It's unusable in the sense that Linux can't use them to store its own
> data. Having the ACPI table outside of the System RAM is valid because
> they are marked as reserved and ioremap will be used to map them.

I think a useful way to think of this might be that the the tables are not
stored in something which has, to the OS, RAM semantics.

In that context Linux's statement that "RAM below the kernel image is
unusable" is irrelevant because the tables are not in RAM.

The fact that under the hood the tables may indeed technically be stored in
DRAM, even in the same DIMM as actual "RAM" is somewhat irrelevant, in
theory it could be a ROM, or anything else which can be read by the CPU.

> 
> > 
> > > I think the problem is how you reserved this region in the EFI memory
> > > table. From what I saw, you marked this new memory with EFI_MEMORY_WB
> > > (which means that the region can be usable by Linux).
> > > 
> > Yes, I mark it with EFI_MEMORY_WB. Is this right?
> 
> I would say no, but it's only because I looked at the kernel code 
> quickly.
> 
> You have to looks how ACPI region/UEFI tables are described in the host
> EFI memory map and mimicking for the DOM0 EFI memory map.

Surely it is the type (EfiACPIReclaimMemory, EfiACPIMemoryNVS etc) and not
the mapping attributes which should control whether an OS considers a
region usable? At least until the OS is done parsing tables neither of
those are usable (which implies we want NVS as our type, unless the memory
is intended to be reclaimed by dom0, implying it should own it).

Ian.