[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 5
On Wed, Sep 02, 2015 at 03:57:51PM +0200, Christoffer Dall wrote: > On Wed, Sep 2, 2015 at 3:54 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote: > > On Wed, 2015-09-02 at 14:48 +0100, Julien Grall wrote: > >> On 02/09/15 14:26, Ian Campbell wrote: > >> > > > > 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). The mapping attributes are checked to see whether a page _could_ be used as generic RAM or not. is_reserve_region() determines whether it should. > >> It looks like that Linux on ARM64 is considering any region with > >> EFI_MEMORY_WB set as normal RAM and will try to add as System RAM (see > >> reserve_regions in arch/arm64/kernel/efi.c). The current state of things ends up being basically: if (EFI_MEMORY_WB) memblock_add() if (EFI_MEMORY_WB && !reclaimable_region) memblock_reserve() That is, apart from counterintuitive, a bug. It should be using memblock_remove() instead. > > It's hard to believe this isn't a bug... It's probably worth asking the > > Linux maintainers about this. > > wasn't this that whole workaround to make sure Linux maps the data as > regular RAM, because otherwise architecture generic code would map it > as IO memory, I hope not. > and generic routines such as memcpy would fault on > unaligned accesses, or am I confusing ACPI with EFI here? Even ACPI tables should need to be in Normal memory in order to work as expected. > Leif (added to the to-field) had some insight on this earlier on. (Adding Ard as well.) Ard wrote a series end of last year to clean much of this up, but it's not been merged: http://thread.gmane.org/gmane.linux.kernel.efi/5133 We should probably push for this to go in as a bugfix, and those interested in seeing this can weigh in in public. / Leif _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |