Xen-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Julien Grall <julien@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, alex.bennee@linaro.org,
	masami.hiramatsu@linaro.org, ehem+xen@m5p.com,
	bertrand.marquis@arm.com, andre.przywara@arm.com,
	Julien Grall <jgrall@amazon.com>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	Wei Xu <xuwei5@hisilicon.com>
Subject: Re: [PATCH 2/4] xen/arm: acpi: The fixmap area should always be cleared during failure/unmap
Date: Thu, 1 Oct 2020 16:14:45 +0100
Message-ID: <15c30bad-0a01-bd89-325d-cf2a90a3070b@xen.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2009301711190.10908@sstabellini-ThinkPad-T480s>

Hi Stefano,

On 01/10/2020 01:30, Stefano Stabellini wrote:
> On Sat, 26 Sep 2020, Julien Grall wrote:
>> From: Julien Grall <jgrall@amazon.com>
>>
>> Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
>> {set, clear}_fixmap()" enforced that each set_fixmap() should be
>> paired with a clear_fixmap(). Any failure to follow the model would
>> result to a platform crash.
>>
>> Unfortunately, the use of fixmap in the ACPI code was overlooked as it
>> is calling set_fixmap() but not clear_fixmap().
>>
>> The function __acpi_os_map_table() is reworked so:
>>      - We know before the mapping whether the fixmap region is big
>>      enough for the mapping.
>>      - It will fail if the fixmap is always inuse.
> 
> I take you mean "it will fail if the fixmap is *already* in use"?

Yes.

> 
> If so, can it be a problem? Or the expectation is that in practice
> __acpi_os_map_table() will only get called once before SYS_STATE_boot?
> 
> Looking at the code it would seem that even before this patch
> __acpi_os_map_table() wasn't able to handle multiple calls before
> SYS_STATE_boot.

Correct, I am not changing any expectation here. It is only making 
clearer because before commit 022387ee1ad3 we would just overwrite the 
existing mapping with no warning.

After commit 022387ee1ad3, we would just hit the BUG_ON() in set_fixmap().

I will clarify it in the commit message.

[...]

>>   bool __acpi_unmap_table(void *ptr, unsigned long size)
>>   {
>> -    return ( vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) &&
>> -             vaddr < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE) );
>> +    vaddr_t vaddr = (vaddr_t)ptr;
>> +    unsigned int idx;
>> +
>> +    /* We are only handling fixmap address in the arch code */
>> +    if ( vaddr < FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) ||
>> +         vaddr >= FIXMAP_ADDR(FIXMAP_ACPI_END) )
> 
> The "+ PAGE_SIZE" got lost

Hmmm yes.

> 
> 
>> +        return false;
>> +
>> +    /*
>> +     * __acpi_map_table() will always return a pointer in the first page
>> +     * for the ACPI fixmap region. The caller is expected to free with
>> +     * the same address.
>> +     */
>> +    ASSERT((vaddr & PAGE_MASK) == FIXMAP_ADDR(FIXMAP_ACPI_BEGIN));
>> +
>> +    /* The region allocated fit in the ACPI fixmap region. */
>> +    ASSERT(size < (FIXMAP_ADDR(FIXMAP_ACPI_END) + PAGE_SIZE - vaddr));
>> +    ASSERT(fixmap_inuse);
>> +
>> +    fixmap_inuse = false;
>> +
>> +    size += FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) - vaddr;
> 
> Sorry I got confused.. Shouldn't this be:
> 
>    size += vaddr - FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
> 
> ?

It should be. :) I guess this was unoticed because vaddr == 
FIXMAP_ADDR(FIXMAP_ACPI_BEGIN) in my testing.

I will fix it.

> 
> 
>> +    idx = FIXMAP_ACPI_BEGIN;
>> +
>> +    do
>> +    {
>> +        clear_fixmap(idx);
>> +        size -= min(size, (unsigned long)PAGE_SIZE);
>> +        idx++;
>> +    } while ( size > 0 );
>> +
>> +    return true;
>>   }
>>   
>>   /* True to indicate PSCI 0.2+ is implemented */
>> -- 
>> 2.17.1
>>

Cheers,

-- 
Julien Grall


  reply index

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-26 20:55 [PATCH 0/4] xen/arm: Unbreak ACPI Julien Grall
2020-09-26 20:55 ` [PATCH 1/4] xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory() Julien Grall
2020-09-28  8:18   ` Jan Beulich
2020-09-28  9:58     ` Julien Grall
2020-09-28 10:09       ` Jan Beulich
2020-09-28 10:39         ` Julien Grall
2020-10-10  9:49           ` Julien Grall
2020-10-10 10:04             ` Julien Grall
2020-09-29 11:10   ` Rahul Singh
2020-10-01  0:06   ` Stefano Stabellini
2020-10-01 15:09     ` Julien Grall
2020-09-26 20:55 ` [PATCH 2/4] xen/arm: acpi: The fixmap area should always be cleared during failure/unmap Julien Grall
2020-09-29 11:13   ` Rahul Singh
2020-10-01  0:30   ` Stefano Stabellini
2020-10-01 15:14     ` Julien Grall [this message]
2020-09-26 20:55 ` [PATCH 3/4] xen/arm: Check if the platform is not using ACPI before initializing Dom0less Julien Grall
2020-09-29 11:17   ` Rahul Singh
2020-09-30 23:26   ` Stefano Stabellini
2020-09-26 20:55 ` [PATCH 4/4] xen/arm: Introduce fw_unreserved_regions() and use it Julien Grall
2020-09-30 23:40   ` Stefano Stabellini
2020-10-01 15:34     ` Julien Grall
2020-09-27  1:47 ` [PATCH 0/4] xen/arm: Unbreak ACPI Elliott Mitchell
2020-09-29 15:28   ` Elliott Mitchell
2020-09-28  6:47 ` Masami Hiramatsu
2020-09-28 13:00   ` Masami Hiramatsu
2020-10-16 22:33     ` Xen-ARM EFI/ACPI problems (was: Re: [PATCH 0/4] xen/arm: Unbreak ACPI) Elliott Mitchell
2020-10-17  5:12       ` Elliott Mitchell
2020-10-08 18:39   ` [PATCH 0/4] xen/arm: Unbreak ACPI Elliott Mitchell
2020-10-09  9:39     ` Julien Grall
2020-10-09 14:22       ` Elliott Mitchell
2020-10-09 18:15         ` Julien Grall
2020-10-09 22:36           ` Elliott Mitchell
2020-10-09 21:49   ` Elliott Mitchell
2020-10-10 11:02   ` Julien Grall
2020-10-12 19:02     ` Stefano Stabellini
2020-10-12 21:34       ` Elliott Mitchell
2020-10-14  1:06         ` Stefano Stabellini
2020-10-14  1:37           ` Elliott Mitchell
2020-10-14 17:47             ` Julien Grall
2020-10-15 18:00               ` Stefano Stabellini
2020-10-14 17:44       ` Julien Grall
2020-09-29 11:10 ` Rahul Singh
2020-09-29 15:29 ` Alex Bennée
2020-09-29 17:07   ` Julien Grall
2020-09-29 21:11     ` Alex Bennée
2020-09-29 23:39       ` André Przywara
2020-09-30  8:51         ` Alex Bennée
2020-09-30 10:35         ` Julien Grall
2020-09-30  9:42       ` Julien Grall
2020-09-30 10:38         ` Alex Bennée
2020-09-30 11:10           ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15c30bad-0a01-bd89-325d-cf2a90a3070b@xen.org \
    --to=julien@xen.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=alex.bennee@linaro.org \
    --cc=andre.przywara@arm.com \
    --cc=bertrand.marquis@arm.com \
    --cc=ehem+xen@m5p.com \
    --cc=jgrall@amazon.com \
    --cc=masami.hiramatsu@linaro.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xuwei5@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Xen-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/xen-devel/0 xen-devel/git/0.git
	git clone --mirror https://lore.kernel.org/xen-devel/1 xen-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 xen-devel xen-devel/ https://lore.kernel.org/xen-devel \
		xen-devel@lists.xenproject.org xen-devel@lists.xen.org
	public-inbox-index xen-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.xenproject.lists.xen-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git