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

Re: Hand over of the Xen shared info page

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Thu, 20 May 2021 05:21:07 +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=DZBvgqB7Vhd+FeUtcnz5ilvqhUOlcnvgkCl4OvW/oNA=; b=ZXi2TwHTuE4IUxIEC/lvN5xnn2F+NrpKkoF49gwo6czuNk/i0yz1Anz2Y4c9AYxwGk2fsk/LIjzDcSSOf/vryS3yTyOh9kIaFobWG4M4ttnRtuYXTI5cYr6/jOr4mnIpOjh2SN5jwlKJiAs9r1RrtALpeOiY3b35k7bURwAbUjA090Q3PD9rrsu9UpkXAdsC3Qu7DZWmuIWLFcT8cDTMqRV8m+CdXsNSFZJgbeN+UbKcPsUERQ/q8lw7QPDq7h9nxU88efVEkT/C2CHVlahEzrpnLw7AYwP24NDhJuTDEaTMWrXrWaqycdgNj55MIRl+PvjG8pYn/B5IUKNAQBL6Qg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TOi7XQjODKaEs61Z+COwJ17Q5Ibzksfrmw/B1kQvJ+4GAw78gQftNv/bnklcbJHPK6imicOABJP/7CnISKW6KQLZaCvJyaWPO4jgnlxIFwo7yCQfiM3w830z13ZwEnfoW4nnDDj6vHu7j2BMP4eP1bRX7dXOpl5VgehiKocMqwEgh7Z6sSU284C9x/imZzLsQEfDkKMckTkTvrUM/FErR0zjkY8boojv0XKmfJRbHoS0fiM8pYDYpjC2IDAeZh5I6L2uzZ9vvgruH73Zam3610UL8u2Qa9gf5umvrjBBzEWucKGWm4koLsBHI2ccffs9rG5C1i8ofS3+yjSdVmDqZw==
  • Authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com;
  • Cc: Anastasiia Lukianenko <Anastasiia_Lukianenko@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrii Chepurnyi <Andrii_Chepurnyi@xxxxxxxx>
  • Delivery-date: Thu, 20 May 2021 05:21:29 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXR86B8dxtD5lx60CgXee9ciHSoarhFtmAgAGmygCACItDgIAAMAgAgABnUwA=
  • Thread-topic: Hand over of the Xen shared info page

Hi, all!

On 5/20/21 2:11 AM, Stefano Stabellini wrote:
> On Wed, 19 May 2021, Julien Grall wrote:
>> On 14/05/2021 10:50, Anastasiia Lukianenko wrote:
>>> Hi Julien!
>> Hello,
>>> On Thu, 2021-05-13 at 09:37 +0100, Julien Grall wrote:
>>>> On 13/05/2021 09:03, Anastasiia Lukianenko wrote:
>>>> The alternative is for U-boot to go through the DT and infer which
>>>> regions are free (IOW any region not described).
>>> Thank you for interest in the problem and advice on how to solve it.
>>> Could you please clarify how we could find free regions using DT in U-
>>> boot?
>> I don't know U-boot code, so I can't tell whether what I suggest would work.
>> In theory, the device-tree should described every region allocated in address
>> space. So if you parse the device-tree and create a list (or any
>> datastructure) with the regions, then any range not present in the list would
>> be free region you could use.
> Yes, any "empty" memory region which is neither memory nor MMIO should
> work.

You need to account on many things while creating the list of regions:

device register mappings, reserved nodes, memory nodes, device tree

overlays parsing etc. It all seem to be a not-that-trivial task and after

all if implemented it only lives in U-boot and you have to maintain that

code. So, if some other entity needs the same you need to implement

that as well. And also you can imagine a system without device tree at all...

So, I am not saying it is not possible to implement, but I just question if

such an implementation is really a good way forward.

>> However, I realized a few days ago that the magic pages are not described in
>> the DT. We probably want to fix it by marking the page as "reserved" or 
>> create
>> a specific bindings.
>> So you will need a specific quirk for them.
> It should also be possible to keep the shared info page allocated and
> simply pass the address to the kernel by adding the right node to device
> tree.
And then you need to modify your OS and this is not only Linux...
> To do that, we would have to add a description of the magic pages
> to device tree, which I think would be good to have in any case. In that
> case it would be best to add a proper binding for it under the "xen,xen"
> node.

I would say that querying Xen for such a memory page seems much

more cleaner and allows the guest OS either to continue using the existing

method with memory allocation or using the page provided by Xen.



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