All of lore.kernel.org
 help / color / mirror / Atom feed
From: m.smarduch@samsung.com (Mario Smarduch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 4/4] add 2nd stage page fault handling during live migration
Date: Thu, 29 May 2014 10:08:07 -0700	[thread overview]
Message-ID: <53876977.1040502@samsung.com> (raw)
In-Reply-To: <20140529085134.GB61607@lvm>


>> So this needs to be cleared up given this is key to logging.
>> Cases this code handles during migration -
>> 1. huge page fault described above - write protect fault so you breakup
>>    the huge page.
>> 2. All other faults - first time access, pte write protect you again wind up in
>>    stage2_set_pte().
>>
>> Am I missing something here?
>>
> 
> no, I forgot about the fact that we can take the permission fault now.
> Hmm, ok, so either we need to use the original approach of always
> splitting up huge pages or we need to just follow the regular huge page
> path here and just mark all 512 4K pages dirty in the log, or handle it
> in stage2_set_pte().
> 
> I would say go with the most simple appraoch for now (which may be going
> back to splitting all pmd_huge() into regular pte's), and we can take a
> more careful look in the next patch iteration.
> 

Looking at the overall memslot update architecture and various
fail scenarios - user_mem_abort() appears to be the most
optimal and reliable place. First Write Protect huge pages after
memslots are committed and deal with rest in user_mem_abort().

Still need some feedback on the pud_huge() before revising for
next iteration?

- Mario

WARNING: multiple messages have this Message-ID (diff)
From: Mario Smarduch <m.smarduch@samsung.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com,
	steve.capper@arm.com, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, gavin.guo@canonical.com,
	peter.maydell@linaro.org, jays.lee@samsung.com,
	sungjinn.chung@samsung.com
Subject: Re: [PATCH v6 4/4] add 2nd stage page fault handling during live migration
Date: Thu, 29 May 2014 10:08:07 -0700	[thread overview]
Message-ID: <53876977.1040502@samsung.com> (raw)
In-Reply-To: <20140529085134.GB61607@lvm>


>> So this needs to be cleared up given this is key to logging.
>> Cases this code handles during migration -
>> 1. huge page fault described above - write protect fault so you breakup
>>    the huge page.
>> 2. All other faults - first time access, pte write protect you again wind up in
>>    stage2_set_pte().
>>
>> Am I missing something here?
>>
> 
> no, I forgot about the fact that we can take the permission fault now.
> Hmm, ok, so either we need to use the original approach of always
> splitting up huge pages or we need to just follow the regular huge page
> path here and just mark all 512 4K pages dirty in the log, or handle it
> in stage2_set_pte().
> 
> I would say go with the most simple appraoch for now (which may be going
> back to splitting all pmd_huge() into regular pte's), and we can take a
> more careful look in the next patch iteration.
> 

Looking at the overall memslot update architecture and various
fail scenarios - user_mem_abort() appears to be the most
optimal and reliable place. First Write Protect huge pages after
memslots are committed and deal with rest in user_mem_abort().

Still need some feedback on the pud_huge() before revising for
next iteration?

- Mario


  reply	other threads:[~2014-05-29 17:08 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15 18:27 [PATCH v6 0/4] live migration dirty bitmap support for ARMv7 Mario Smarduch
2014-05-15 18:27 ` Mario Smarduch
2014-05-15 18:27 ` [PATCH v6 1/4] add ARMv7 HYP API to flush VM TLBs without address param Mario Smarduch
2014-05-15 18:27   ` Mario Smarduch
2014-05-27 19:51   ` Christoffer Dall
2014-05-27 19:51     ` Christoffer Dall
2014-05-15 18:27 ` [PATCH v6 2/4] live migration support for initial write protect of VM Mario Smarduch
2014-05-15 18:27   ` Mario Smarduch
2014-05-27 19:58   ` Christoffer Dall
2014-05-27 19:58     ` Christoffer Dall
2014-05-27 20:15     ` Mario Smarduch
2014-05-27 20:15       ` Mario Smarduch
2014-05-27 20:20       ` Christoffer Dall
2014-05-27 20:20         ` Christoffer Dall
2014-05-15 18:27 ` [PATCH v6 3/4] live migration support for VM dirty log management Mario Smarduch
2014-05-15 18:27   ` Mario Smarduch
2014-05-27 20:12   ` Christoffer Dall
2014-05-27 20:12     ` Christoffer Dall
2014-05-27 21:55     ` Mario Smarduch
2014-05-27 21:55       ` Mario Smarduch
2014-05-28  9:08       ` Christoffer Dall
2014-05-28  9:08         ` Christoffer Dall
2014-05-28 17:59         ` Mario Smarduch
2014-05-28 17:59           ` Mario Smarduch
2014-05-15 18:27 ` [PATCH v6 4/4] add 2nd stage page fault handling during live migration Mario Smarduch
2014-05-15 18:27   ` Mario Smarduch
2014-05-27 20:19   ` Christoffer Dall
2014-05-27 20:19     ` Christoffer Dall
2014-05-28  1:30     ` Mario Smarduch
2014-05-28  1:30       ` Mario Smarduch
2014-05-28  8:09       ` Christoffer Dall
2014-05-28  8:09         ` Christoffer Dall
2014-05-28 17:55         ` Mario Smarduch
2014-05-28 17:55           ` Mario Smarduch
2014-05-28 18:42           ` Mario Smarduch
2014-05-28 18:42             ` Mario Smarduch
2014-05-29  2:02             ` Mario Smarduch
2014-05-29  2:02               ` Mario Smarduch
2014-05-29  8:42             ` Christoffer Dall
2014-05-29  8:42               ` Christoffer Dall
2014-05-29  8:51           ` Christoffer Dall
2014-05-29  8:51             ` Christoffer Dall
2014-05-29 17:08             ` Mario Smarduch [this message]
2014-05-29 17:08               ` Mario Smarduch
2014-05-29 17:57               ` Christoffer Dall
2014-05-29 17:57                 ` Christoffer Dall
2014-05-29 19:10                 ` Mario Smarduch
2014-05-29 19:10                   ` Mario Smarduch
2014-05-15 18:51 ` [PATCH v6 0/4] live migration dirty bitmap support for ARMv7 Christoffer Dall
2014-05-15 18:51   ` Christoffer Dall
2014-05-15 22:53   ` Mario Smarduch
2014-05-15 22:53     ` Mario Smarduch

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=53876977.1040502@samsung.com \
    --to=m.smarduch@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.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: link
Be 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.