[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, 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). > > 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). It's hard to believe this isn't a bug... It's probably worth asking the Linux maintainers about this. On first glance it seems to me that the is_reserve_region check ought to be before the is_normal_ram one, not vice versa. But what do I know... > At the same time, having WB set for a region that should be read-only > looks like wrong to me. it does seem a bit meaningless at least, if not wrong. > > Regards, > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |