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

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions


  • To: Julien Grall <julien.grall@xxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Tue, 13 Aug 2019 15:14:06 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PoeR34J1BfbOETQxh+OBF3IQcf0Tk/VfJesjq8Oncu8=; b=MhYHyWBYCMPOMBDz0vwqeAfvTr9VO8AICARvCd7y7zlycLM6EX5bAJzhiYC+V/qbikwX4MN/7EGLijH8SUOKokLsNwz2wZDOWr200/qw1LdNRHgNd0y8wwv9jqMC0RfPfoRJ2xTz1Wftxe6ZPO2b6wMG8NtSnD+o7fi+77mwibWIeQpmPElRfaCPkxc/3WNVi/wRbD7ZdQ95lJ4lwJklMV1PFsqw1pMiDwX8FtDifZ4zqLQA9y0NPnbpLHXeek2p9mQNBxi/1+NpxuwARzQCj5JuchmG/6ziMKR4zQBaJEEi5Ja+R3EqpqNIPpQUkZ7Yvo/aMoX27BiiigUomAuXjw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K7fi5Az4bbKMWYn28nmlbZTQMJbbuLjK/qKqO8RnEMP5kkDdN3NgcQCJ+YqUJAz/mLO/T7iusA94VMxQz1CgAuc47CUw8YVxwt+xorQEXXdJFKBd1BpJzbEsD9QubrvUH3mfteoQcwhkKOCWhA2KjzondqQyExwvQAFISq+W5KS8ZUmpze7P8JhZbjZDzVO/qbDlh6JrJLpWMDmzepNI7K++epGDF775VaU4x67c2gb8FYy7BX03TygQuX7vOQK3kdFjvsYjiX9Im12l4bWakWlHrUT9BQBtpG8/1h80oII1SGrCDyRX0zg7orZ+AWD06qleSbsb6drpkexZjkEhTg==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Volodymyr_Babchuk@xxxxxxxx;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Stefano Stabellini <stefanos@xxxxxxxxxx>
  • Delivery-date: Tue, 13 Aug 2019 15:14:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVUV1QMNfXhdMZzkSWk2vkeQwkS6b5IrWAgAAGPwCAAAfPgA==
  • Thread-topic: [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions

Hi Julien,

Julien Grall writes:

> Hi,
>
> On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:
>>
>> Stefano Stabellini writes:
>>
>>> As we parse the device tree in Xen, keep track of the reserved-memory
>>> regions as they need special treatment (follow-up patches will make use
>>> of the stored information.)
>>>
>>> Reuse process_memory_node to add reserved-memory regions to the
>>> bootinfo.reserved_mem array.
>>>
>>> Refuse to continue once we reach the max number of reserved memory
>>> regions to avoid accidentally mapping any portions of them into a VM.
>>>
>>> Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
>>>
>>> ---
>>> Changes in v5:
>>> - remove unneeded cast
>>> - remove unneeded strlen check
>>> - don't pass address_cells, size_cells, depth to device_tree_for_each_node
>>>
>>> Changes in v4:
>>> - depth + 1 in process_reserved_memory_node
>>> - pass address_cells and size_cells to device_tree_for_each_node
>>> - pass struct meminfo * instead of a boolean to process_memory_node
>>> - improve in-code comment
>>> - use a separate process_reserved_memory_node (separate from
>>>    process_memory_node) function wrapper to have different error handling
>>>
>>> Changes in v3:
>>> - match only /reserved-memory
>>> - put the warning back in place for reg not present on a normal memory
>>>    region
>>> - refuse to continue once we reach the max number of reserved memory
>>>    regions
>>>
>>> Changes in v2:
>>> - call process_memory_node from process_reserved_memory_node to avoid
>>>    duplication
>>> ---
>>>   xen/arch/arm/bootfdt.c      | 41 +++++++++++++++++++++++++++++++------
>>>   xen/include/asm-arm/setup.h |  1 +
>>>   2 files changed, 36 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
>>> index 590b14304c..0b0e22a3d0 100644
>>> --- a/xen/arch/arm/bootfdt.c
>>> +++ b/xen/arch/arm/bootfdt.c
>>> @@ -136,6 +136,7 @@ static int __init process_memory_node(const void *fdt, 
>>> int node,
>>>       const __be32 *cell;
>>>       paddr_t start, size;
>>>       u32 reg_cells = address_cells + size_cells;
>>> +    struct meminfo *mem = data;
>>>
>>>       if ( address_cells < 1 || size_cells < 1 )
>>>           return -ENOENT;
>>> @@ -147,21 +148,46 @@ static int __init process_memory_node(const void 
>>> *fdt, int node,
>>>       cell = (const __be32 *)prop->data;
>>>       banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
>>>
>>> -    for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
>>> +    for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
>> What is logic behind the second part of the loop condition?
>>
>> You know that if (banks > NR_MEM_BANKS) then you will exit with error. Do
>> you really need to iterate over loop in this case?
>
> Well, the error is ignored in the case of memory banks. So iterating
> over the first banks allows you to fill up bootinfo with as much as
> possible as RAM. The rest of the RAM will not be used by Xen.
Fair enough.

>>
>>>       {
>>>           device_tree_get_reg(&cell, address_cells, size_cells, &start, 
>>> &size);
>>>           if ( !size )
>>>               continue;
>>> -        bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
>>> -        bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
>>> -        bootinfo.mem.nr_banks++;
>>> +        mem->bank[mem->nr_banks].start = start;
>>> +        mem->bank[mem->nr_banks].size = size;
>>> +        mem->nr_banks++;
>>>       }
>>>
>>> -    if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
>>> +    if ( mem->nr_banks == NR_MEM_BANKS )
>> Looks like you have the same off-by-one error, as in previous patch.
>> I can see that it was there earlier. But it is good time to fix it.
>
> I don't think there was an off-by-one error before this series. So
> what do you mean?
I explained this in patch #2. Imagine that NR_MEM_BANKS = 1 and you have
one memory node in the dtb. You'll fill the first element of the array
and mem->nr_banks will become 1. This is absolutely normal. But check
above will fail, which is not right.

-- 
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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