From: zhenwei pi <pizhenwei@bytedance.com> To: Naoya Horiguchi <naoya.horiguchi@linux.dev> Cc: David Hildenbrand <david@redhat.com>, akpm@linux-foundation.org, naoya.horiguchi@nec.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Wu Fengguang <fengguang.wu@intel.com>, "Michael S. Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, "virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org> Subject: Re: Re: Re: [PATCH 3/4] mm/memofy-failure.c: optimize hwpoison_filter Date: Sat, 7 May 2022 17:19:09 +0800 [thread overview] Message-ID: <23e06fc6-84fe-122e-fc07-02c5bfa7d50b@bytedance.com> (raw) In-Reply-To: <20220507082045.GA1716199@u2004> On 5/7/22 16:20, Naoya Horiguchi wrote: > On Sat, May 07, 2022 at 08:28:05AM +0800, zhenwei pi wrote: >> >> On 5/7/22 00:28, David Hildenbrand wrote: >>> On 06.05.22 15:38, zhenwei pi wrote: >>>> >>>> >>>> On 5/6/22 16:59, Naoya Horiguchi wrote: >>>>> On Fri, Apr 29, 2022 at 10:22:05PM +0800, zhenwei pi wrote: >>>>>> In the memory failure procedure, hwpoison_filter has higher priority, >>>>>> if memory_filter() filters the error event, there is no need to do >>>>>> the further work. >>>>> >>>>> Could you clarify what problem you are trying to solve (what does >>>>> "optimize" mean in this context or what is the benefit)? >>>>> >>>> >>>> OK. The background of this work: >>>> As well known, the memory failure mechanism handles memory corrupted >>>> event, and try to send SIGBUS to the user process which uses this >>>> corrupted page. >>>> >>>> For the virtualization case, QEMU catches SIGBUS and tries to inject MCE >>>> into the guest, and the guest handles memory failure again. Thus the >>>> guest gets the minimal effect from hardware memory corruption. >>>> >>>> The further step I'm working on: >>>> 1, try to modify code to decrease poisoned pages in a single place >>>> (mm/memofy-failure.c: simplify num_poisoned_pages_dec in this series). > > This is fine to me. > >>>> >>>> 2, try to use page_handle_poison() to handle SetPageHWPoison() and >>>> num_poisoned_pages_inc() together. It would be best to call >>>> num_poisoned_pages_inc() in a single place too. I'm not sure if this is >>>> possible or not, please correct me if I misunderstand. > > SetPageHWPoison() can be cancelled in memory_failure(), so simply bundling > it with num_poisoned_pages_inc() might not be optimal. I think that > action_result() is supposed to be called when memory error handling is > effective (not filtered, not cancelled). So moving num_poisoned_pages_inc() > (and notification code in your plan) into this function might be good. > OK, I'll remove this patch(mm/memofy-failure.c: optimize hwpoison_filter) from this series, and fix the other 3 patches in the v2 version. Then try to implement/test as your suggestion in another series. >>>> >>>> 3, introduce memory failure notifier list in memory-failure.c: notify >>>> the corrupted PFN to someone who registers this list. >>>> If I can complete [1] and [2] part, [3] will be quite easy(just call >>>> notifier list after increasing poisoned page). >>>> >>>> 4, introduce memory recover VQ for memory balloon device, and registers >>>> memory failure notifier list. During the guest kernel handles memory >>>> failure, balloon device gets notified by memory failure notifier list, >>>> and tells the host to recover the corrupted PFN(GPA) by the new VQ. >>> >>> Most probably you might want to do that asynchronously, and once the >>> callback succeeds, un-poison the page. >>> >> Yes! >> >>>> >>>> 5, host side remaps the corrupted page(HVA), and tells the guest side to >>>> unpoison the PFN(GPA). Then the guest fixes the corrupted page(GPA) >>>> dynamically. >>> >>> I think QEMU already does that during reboots. Now it would be triggered >>> by the guest for individual pages. >>> >> Yes, currently QEMU supports to un-poison corrupted pages during >> reset/reboot. We can reuse some code to do the work in this case, this >> allows a VM to fix corrupted pages as soon as possible(also no need to >> reset/reboot). > > So this finally allows to replace broken page mapped to guest with > a healthy page without rebooting the guest. That sounds helpful. > > Thanks, > Naoya Horiguchi > Yes, it's my plan. Thanks for your suggestions! >> >>>> >>>> Because [4] and [5] are related to balloon device, also CC Michael, >>>> David and Jason. >>> >>> Doesn't sound too crazy for me, although it's a shame that we always >>> have to use virtio-balloon for such fairly balloon-unrelated things. >>> >> Thanks! >> >> -- >> zhenwei pi -- zhenwei pi
WARNING: multiple messages have this Message-ID (diff)
From: zhenwei pi <pizhenwei@bytedance.com> To: Naoya Horiguchi <naoya.horiguchi@linux.dev> Cc: "Michael S. Tsirkin" <mst@redhat.com>, naoya.horiguchi@nec.com, linux-kernel@vger.kernel.org, "virtualization@lists.linux-foundation.org" <virtualization@lists.linux-foundation.org>, linux-mm@kvack.org, akpm@linux-foundation.org, Wu Fengguang <fengguang.wu@intel.com> Subject: Re: Re: Re: [PATCH 3/4] mm/memofy-failure.c: optimize hwpoison_filter Date: Sat, 7 May 2022 17:19:09 +0800 [thread overview] Message-ID: <23e06fc6-84fe-122e-fc07-02c5bfa7d50b@bytedance.com> (raw) In-Reply-To: <20220507082045.GA1716199@u2004> On 5/7/22 16:20, Naoya Horiguchi wrote: > On Sat, May 07, 2022 at 08:28:05AM +0800, zhenwei pi wrote: >> >> On 5/7/22 00:28, David Hildenbrand wrote: >>> On 06.05.22 15:38, zhenwei pi wrote: >>>> >>>> >>>> On 5/6/22 16:59, Naoya Horiguchi wrote: >>>>> On Fri, Apr 29, 2022 at 10:22:05PM +0800, zhenwei pi wrote: >>>>>> In the memory failure procedure, hwpoison_filter has higher priority, >>>>>> if memory_filter() filters the error event, there is no need to do >>>>>> the further work. >>>>> >>>>> Could you clarify what problem you are trying to solve (what does >>>>> "optimize" mean in this context or what is the benefit)? >>>>> >>>> >>>> OK. The background of this work: >>>> As well known, the memory failure mechanism handles memory corrupted >>>> event, and try to send SIGBUS to the user process which uses this >>>> corrupted page. >>>> >>>> For the virtualization case, QEMU catches SIGBUS and tries to inject MCE >>>> into the guest, and the guest handles memory failure again. Thus the >>>> guest gets the minimal effect from hardware memory corruption. >>>> >>>> The further step I'm working on: >>>> 1, try to modify code to decrease poisoned pages in a single place >>>> (mm/memofy-failure.c: simplify num_poisoned_pages_dec in this series). > > This is fine to me. > >>>> >>>> 2, try to use page_handle_poison() to handle SetPageHWPoison() and >>>> num_poisoned_pages_inc() together. It would be best to call >>>> num_poisoned_pages_inc() in a single place too. I'm not sure if this is >>>> possible or not, please correct me if I misunderstand. > > SetPageHWPoison() can be cancelled in memory_failure(), so simply bundling > it with num_poisoned_pages_inc() might not be optimal. I think that > action_result() is supposed to be called when memory error handling is > effective (not filtered, not cancelled). So moving num_poisoned_pages_inc() > (and notification code in your plan) into this function might be good. > OK, I'll remove this patch(mm/memofy-failure.c: optimize hwpoison_filter) from this series, and fix the other 3 patches in the v2 version. Then try to implement/test as your suggestion in another series. >>>> >>>> 3, introduce memory failure notifier list in memory-failure.c: notify >>>> the corrupted PFN to someone who registers this list. >>>> If I can complete [1] and [2] part, [3] will be quite easy(just call >>>> notifier list after increasing poisoned page). >>>> >>>> 4, introduce memory recover VQ for memory balloon device, and registers >>>> memory failure notifier list. During the guest kernel handles memory >>>> failure, balloon device gets notified by memory failure notifier list, >>>> and tells the host to recover the corrupted PFN(GPA) by the new VQ. >>> >>> Most probably you might want to do that asynchronously, and once the >>> callback succeeds, un-poison the page. >>> >> Yes! >> >>>> >>>> 5, host side remaps the corrupted page(HVA), and tells the guest side to >>>> unpoison the PFN(GPA). Then the guest fixes the corrupted page(GPA) >>>> dynamically. >>> >>> I think QEMU already does that during reboots. Now it would be triggered >>> by the guest for individual pages. >>> >> Yes, currently QEMU supports to un-poison corrupted pages during >> reset/reboot. We can reuse some code to do the work in this case, this >> allows a VM to fix corrupted pages as soon as possible(also no need to >> reset/reboot). > > So this finally allows to replace broken page mapped to guest with > a healthy page without rebooting the guest. That sounds helpful. > > Thanks, > Naoya Horiguchi > Yes, it's my plan. Thanks for your suggestions! >> >>>> >>>> Because [4] and [5] are related to balloon device, also CC Michael, >>>> David and Jason. >>> >>> Doesn't sound too crazy for me, although it's a shame that we always >>> have to use virtio-balloon for such fairly balloon-unrelated things. >>> >> Thanks! >> >> -- >> zhenwei pi -- zhenwei pi _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2022-05-07 9:23 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-29 14:22 [PATCH 0/4] memory-failure: fix hwpoison_filter zhenwei pi 2022-04-29 14:22 ` [PATCH 1/4] mm/memory-failure.c: move clear_hwpoisoned_pages zhenwei pi 2022-05-06 8:55 ` Naoya Horiguchi 2022-04-29 14:22 ` [PATCH 2/4] mm/memofy-failure.c:: simplify num_poisoned_pages_dec zhenwei pi 2022-05-06 8:55 ` Naoya Horiguchi 2022-04-29 14:22 ` [PATCH 3/4] mm/memofy-failure.c: optimize hwpoison_filter zhenwei pi 2022-05-06 8:59 ` Naoya Horiguchi 2022-05-06 13:38 ` zhenwei pi 2022-05-06 13:38 ` zhenwei pi 2022-05-06 16:28 ` David Hildenbrand 2022-05-06 16:28 ` David Hildenbrand 2022-05-07 0:28 ` zhenwei pi 2022-05-07 0:28 ` zhenwei pi 2022-05-07 8:20 ` Naoya Horiguchi 2022-05-07 9:19 ` zhenwei pi [this message] 2022-05-07 9:19 ` zhenwei pi 2022-04-29 14:22 ` [PATCH 4/4] mm/memofy-failure.c: add hwpoison_filter for soft offline zhenwei pi 2022-05-06 8:59 ` Naoya Horiguchi
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=23e06fc6-84fe-122e-fc07-02c5bfa7d50b@bytedance.com \ --to=pizhenwei@bytedance.com \ --cc=akpm@linux-foundation.org \ --cc=david@redhat.com \ --cc=fengguang.wu@intel.com \ --cc=jasowang@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mst@redhat.com \ --cc=naoya.horiguchi@linux.dev \ --cc=naoya.horiguchi@nec.com \ --cc=virtualization@lists.linux-foundation.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.