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

RE: Discussion of Xenheap problems on AArch64


  • To: Julien Grall <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Tue, 27 Apr 2021 06:29:25 +0000
  • Accept-language: zh-CN, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=Jb2FS5OzopljNYnTWSRHtMTkg6OcRK5aJZQwsHUkLK4=; b=ToZNZFamBCVlJXratRqptaQRnglpA0pXH8w/p0LRiOUi0oAbsSSxF1TI7jZUM4r56IoPmKoBxWtRxx5gvHKhMvPoPT6xvVPMYYS9CKUWryF45f+V+OoIjKZElcvfPFESHRNVZP1MygtmtrxpbhFEMghGXOGEPPGG2awJGAfPgs+t4a2rqmycGOYZ53m2098PVOcrGafrfh7KqJ3ib4BUD+OOUgcfSR8SBsaN9oQazWLDYJspYgTzZbRSkQJBSOXqbBQljzjlhioDVrGvsBxQ5tL3qblWn1Yp/EOPR5mHUw572G0POqvxFqRXooq53sFJXWR/yfX6o7y/OXyfBRFbVg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h9dYftoizxSnHzsQvhjkUgwCWg0HDEVMAzqicsqUrxbUa7bvJ/PpNDri5Jb/Ov6WAOwfQhrICOC56nzRs4A/Bt9d95fsDYpwPuc0ZMFInGkUORiA+fGtQO9Bhz9ihoMmxr6xJrrjJCooUHeZ17UKypu5QT2u+q85fYuR/v0Hef7LI9rApUR2SendcFER3Yfucz//CR2oAdB5ycDF3p4Cmj0fOwHwfQ+bK7JCfKF5HCRdJvECNzZaVULGPtcNwnylZYmaDTfZwi1zZ4L339CcY6Z6d+xd6KypZKz8fnR2DOWAGso6NiIWzHSMNJSK8f1DGLA5X+jkshbu0SwjrwP09Q==
  • Authentication-results-original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Cc: Wei Chen <Wei.Chen@xxxxxxx>, Penny Zheng <Penny.Zheng@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Delivery-date: Tue, 27 Apr 2021 06:30:01 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Thread-index: Adc2dyA8lkZGRqbyRiSglHolanVkwQAFhaqAAACgy/AA4CfqgABHcHyA
  • Thread-topic: Discussion of Xenheap problems on AArch64

Hi Julien,

Sorry for the late reply, I kinda missed this email somehow....

Please see my inline reply ^^

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of
> Julien Grall
> Sent: Monday, April 26, 2021 4:20 AM
> To: Henry Wang <Henry.Wang@xxxxxxx>; sstabellini@xxxxxxxxxx; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Wei Chen <Wei.Chen@xxxxxxx>; Penny Zheng
> <Penny.Zheng@xxxxxxx>; Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
> Subject: Re: Discussion of Xenheap problems on AArch64
> 
> 
> 
> On 21/04/2021 10:32, Henry Wang wrote:
> > Hi Julien,
> 
> Hi Henry,
> 
> >> -----Original Message-----
> >> From: Julien Grall <julien@xxxxxxx>
> >> Sent: Wednesday, April 21, 2021 5:04 PM
> >> To: Henry Wang <Henry.Wang@xxxxxxx>; sstabellini@xxxxxxxxxx; xen-
> >> devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Wei Chen <Wei.Chen@xxxxxxx>; Penny Zheng
> >> <Penny.Zheng@xxxxxxx>; Bertrand Marquis
> <Bertrand.Marquis@xxxxxxx>
> >> Subject: Re: Discussion of Xenheap problems on AArch64
> >>
> >>
> >>
> >> On 21/04/2021 07:28, Henry Wang wrote:
> >>> Hi,
> >>
> >> Hi Henry,
> >>
> >>>
> >>> We are trying to implement the static memory allocation on AArch64.
> Part
> >> of
> >>> this feature is the reserved heap memory allocation, where a specific
> range
> >> of
> >>> memory is reserved only for heap. In the development process, we
> found a
> >>> pitfall in current AArch64 setup_xenheap_mappings() function.
> >>>
> >>> According to a previous discussion in community
> >>> https://lore.kernel.org/xen-devel/20190216134456.10681-1-
> >> peng.fan@xxxxxxx/,
> >>> on AArch64, bootmem is initialized after setup_xenheap_mappings(),
> >>> setup_xenheap_mappings() may try to allocate memory before memory
> >> has been
> >>> handed over to the boot allocator. If the reserved heap memory
> allocation
> >> is
> >>> introduced, either of below 2 cases will trigger a crash:
> >>>
> >>> 1. If the reserved heap memory is at the end of the memory block list
> and
> >> the
> >>> gap between reserved and unreserved memory is bigger than 512GB,
> when
> >> we setup
> >>> mappings from the beginning of the memory block list, we will get OOM
> >> caused
> >>> by lack of pages in boot allocator. This is because the memory that is
> >> reserved
> >>> for heap has not been mapped and added to the boot allocator.
> >>>
> >>> 2. If we add the memory that is reserved for heap to boot allocator first,
> >> and
> >>> then setup mappings for banks in the memory block list, we may get a
> page
> >> which
> >>> has not been setup mapping, causing a data abort.
> >>
> >> There are a few issues with setup_xenheap_mappings(). I have been
> >> reworking the code on my spare time and started to upstream bits of it.
> >> A PoC can be found here:
> >>
> >> https://xenbits.xen.org/gitweb/?p=people/julieng/xen-
> >> unstable.git;a=shortlog;h=refs/heads/pt/dev
> >>
> >
> > Really great news! Thanks you very much for the information and your
> hard
> > work on the PoC :) I will start to go through your PoC code then.
> 
> I spent sometimes today to clean-up the PoC and sent a series on the ML
> (see [1]). This has been lightly tested so far.
> 
> Would you be able to give a try and let me know if it helps your problem?

Yes of course! I will start to test this series ^^ Thank you for your work!

> 
> For convenience, I have pushed a branch with the series applied here:
> 
> https://xenbits.xen.org/gitweb/?p=people/julieng/xen-
> unstable.git;a=shortlog;h=refs/heads/pt/rfc-v2
> 

Great, thanks!

> Cheers,
> 
> [1] https://lore.kernel.org/xen-devel/20210425201318.15447-1-
> julien@xxxxxxx/
> 
> --
> Julien Grall


 


Rackspace

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