[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 05/10] acpi: Refactor acpi_os_map_memory to be architecturally independent



>>> On 16.01.16 at 06:01, <zhaoshenglong@xxxxxxxxxx> wrote:
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -86,17 +86,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
>  void __iomem *
>  acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
>  {
> -     if (system_state >= SYS_STATE_active) {
> -             mfn_t mfn = _mfn(PFN_DOWN(phys));
> -             unsigned int offs = phys & (PAGE_SIZE - 1);
> -
> -             /* The low first Mb is always mapped. */
> -             if ( !((phys + size - 1) >> 20) )
> -                     return __va(phys);
> -             return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
> -                           PAGE_HYPERVISOR_NOCACHE) + offs;
> -     }
> -     return __acpi_map_table(phys, size);
> +     return arch_acpi_os_map_memory(phys, size);
>  }

I'm quite sure I've said before that this goes too far: The __vmap()
part and likely also the early-boot __acpi_map_table() one already
are architecture independent and hence should stay. The factoring
hence should only concern the first Mb handling and maybe the
the mapping attributes passed to __vmap().

Jan


_______________________________________________
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®.