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

Re: Hand over of the Xen shared info page

  • To: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Thu, 20 May 2021 12:37:25 +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=8zDKcSm7p+DfaZQ1ZIrsz7KAPlrbPwXHx3x5bBdujwQ=; b=Eabb3bktBUisNzeTK7tl8MaqE06GsARM+WuoJ5jW2d7isd7QGe4SSKFhglt8XnFeQoegy2sZ7yembxL1AFyi/IQV2SiXw7CmnSRkRsalRlsnkKvL4b88Hr/uY6Bbxb1WxlcNHVgW4Xk0B29ZClqyZaONEholBAiQBRxBipUJ+mBX84fQcGvjs5ugKuoUlfmF6U/RfL1fIPTycRgaor7jKNQF9baT6wtXIFxklH4b4OOyxUPmR+lPFWkFzYPcRg9grQrSSKrNvQxNCkVelJMO5Cwg3oTsKl6/6qACek4aMACErK0poHBdagiLtgXAbxHDvHiwn4R0vA+MIZdmQjJK3g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nALrMstIlogndlm7C7UlsWHBldekZd8SXOfHQf7Xf6PX5AulIwtbk5uvbk3D1zZqMay/FyndD78+KgdKf5BTBOtgcx9+PRRgjYVVU4vMQVBV8BikEQDv/LN3ZSpiOGQXvoWb+ofd5vXavJQKirVRBF1iHmdOOSFGrf6GY7Lh6kC8toZT09aOUw3NW4v9h/x+gBJVqTiwqhoos6esBv66BxCLAG2RYHrlMK0f432Xgj2XO5o16KhELRWgIM6OqyU5BbjdXLyWAyJ7TvM2rs7UFTWe7JShx4Et/DQYY0HKkJZzMSzK3TqQQtHT77lwLbzgJH5SHCccojXEvCoSWDyaig==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.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 12:37:32 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXR86B8dxtD5lx60CgXee9ciHSoarhFtmAgAGmygCACItDgIAAMAgAgABnUwCAAEoLgIAAL9yA
  • Thread-topic: Hand over of the Xen shared info page


On 5/20/21 12:46 PM, Julien Grall wrote:
> On 20/05/2021 06:21, Oleksandr Andrushchenko wrote:
>> Hi, all!
> Hi,
>> 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.
> Yes, there are some complexity. I have suggested other approach in a separate 
> thread. Did you look at them?

Yes, so probably we can re-use the solution from that thread when it comes to 
some conclusion

and implementation.

>> And also you can imagine a system without device tree at all...
> Xen doesn't provide a stable guest layout. Such system would have to be 
> tailored to a given guest configuration, Xen version (can be custom)...
> Therefore, hardcoding the value in the system (not in Xen headers!) is not 
> going to make it much worse.
Agree to some extent
>> 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.
> IIUC your proposal, you are asking to add an hypercall to query which guest 
> physical region can be used for the shared info page.
> This may solve the problem you have at hand, but this is not scalable. There 
> are a few other regions which regions unallocated memory (e.g. grant table, 
> grant mapping, foreign memory map,....).
> So if we were going to involve Xen, then I think it is better to have a 
> generic way to ask Xen for unallocated space.
> Cheers,
Thank you,




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