[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.