From: m.smarduch@samsung•com (Mario Smarduch)
To: linux-arm-kernel@lists•infradead.org
Subject: [RESEND PATCH v15 07/11] KVM: arm: page logging 2nd stage fault handling
Date: Fri, 09 Jan 2015 20:38:38 -0800 [thread overview]
Message-ID: <54B0ACCE.4040109@samsung.com> (raw)
In-Reply-To: <20150109102458.GN21092@cbox>
On 01/09/2015 02:24 AM, Christoffer Dall wrote:
> On Thu, Jan 08, 2015 at 08:28:46AM -0800, Mario Smarduch wrote:
>> On 01/08/2015 02:45 AM, Christoffer Dall wrote:
>>> On Wed, Jan 07, 2015 at 05:43:18PM -0800, Mario Smarduch wrote:
>>>> Hi Christoffer,
>>>> before going through your comments, I discovered that
>>>> in 3.18.0-rc2 - a generic __get_user_pages_fast()
>>>> was implemented, now ARM picks this up. This causes
>>>> gfn_to_pfn_prot() to return meaningful 'writable'
>>>> value for a read fault, provided the region is writable.
>>>>
>>>> Prior to that the weak version returned 0 and 'writable'
>>>> had no optimization effect to set pte/pmd - RW on
>>>> a read fault.
>>>>
>>>> As a consequence dirty logging broke in 3.18, I was seeing
>> Correction on this, proper __get_user_pages_fast()
>> behavior exposed a bug in page logging code.
>>
>>>> weird but very intermittent issues. I just put in the
>>>> additional few lines to fix it, prevent pte RW (only R) on
>>>> read faults while logging writable region.
>>>>
>>>> On 01/07/2015 04:38 AM, Christoffer Dall wrote:
>>>>> On Wed, Dec 17, 2014 at 06:07:29PM -0800, Mario Smarduch wrote:
>>>>>> This patch is a followup to v15 patch series, with following changes:
>>>>>> - When clearing/dissolving a huge, PMD mark huge page range dirty, since
>>>>>> the state of whole range is unknown. After the huge page is dissolved
>>>>>> dirty page logging is at page granularity.
>>>>>
>>>>> What is the sequence of events where you could have dirtied another page
>>>>> within the PMD range after the user initially requested dirty page
>>>>> logging?
>>>>
>>>> No there is none. My issue was the start point for tracking dirty pages
>>>> and that would be second call to dirty log read. Not first
>>>> call after initial write protect where any page in range can
>>>> be assumed dirty. I'll remove this, not sure if there would be any
>>>> use case to call dirty log only once.
>>>>
>>>
>>> Calling dirty log once can not give you anything meaningful, right? You
>>> must assume all memory is 'dirty' at this point, no?
>>
>> There is the interval between KVM_MEM_LOG_DIRTY_PAGES and first
>> call to KVM_GET_DIRTY_LOG. Not sure of any use case, maybe enable
>> logging, wait a while do a dirty log read, disable logging.
>> Get an accumulated snapshot of dirty page activity.
>>
> ok, so from the time the user calls KVM_MEM_LOG_DIRTY_PAGES, then any
> fault on any huge page will dissolve that huge page into pages, and each
> dirty page will be logged accordingly for the first call to
> KVM_GET_DIRTY_LOG, right? What am I missing here?
Yes that's correct, this may or may not be meaningful in itself.
The original point was first time access to a huge page (on
first or some later call) and do we consider whole range dirty.
Keeping track at page granularity + original image provides
everything needed to reconstruct the source so it should
not matter.
I think I convoluted this issue a bit.
- Mario
>
> -Christoffer
>
prev parent reply other threads:[~2015-01-10 4:38 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 7:27 [PATCH v15 00/11] KVM//x86/arm/arm64: dirty page logging for ARMv7/8 (3.18.0-rc2) Mario Smarduch
2014-12-15 7:27 ` [PATCH v15 01/11] KVM: Add architecture-defined TLB flush support Mario Smarduch
2014-12-15 7:27 ` [PATCH v15 02/11] KVM: Add generic support for dirty page logging Mario Smarduch
2014-12-15 7:28 ` [PATCH v15 03/11] KVM: x86: switch to kvm_get_dirty_log_protect Mario Smarduch
2014-12-15 7:28 ` [PATCH v15 04/11] KVM: arm: Add ARMv7 API to flush TLBs Mario Smarduch
2014-12-15 7:28 ` [PATCH v15 05/11] KVM: arm: Add initial dirty page locking support Mario Smarduch
2015-01-07 13:05 ` Christoffer Dall
2014-12-15 7:28 ` [PATCH v15 06/11] KVM: arm: dirty logging write protect support Mario Smarduch
2015-01-07 13:05 ` Christoffer Dall
2014-12-15 7:28 ` [PATCH v15 07/11] KVM: arm: page logging 2nd stage fault handling Mario Smarduch
2014-12-15 7:28 ` [PATCH v15 08/11] KVM: arm64: ARMv8 header changes for page logging Mario Smarduch
2014-12-15 7:28 ` [PATCH v15 09/11] KVM: arm64: Add HYP interface to flush VM Stage 1/2 TLB entires Mario Smarduch
2014-12-15 7:28 ` [PATCH v15 10/11] KVM: arm/arm64: Enable Dirty Page logging for ARMv8 Mario Smarduch
2015-01-07 12:47 ` Christoffer Dall
2015-01-08 1:51 ` Mario Smarduch
2015-01-08 10:56 ` Christoffer Dall
2015-01-08 16:30 ` Mario Smarduch
2014-12-15 7:28 ` [PATCH v15 11/11] KVM: arm/arm64: Add support to dissolve huge PUD Mario Smarduch
2015-01-07 13:05 ` Christoffer Dall
2015-01-08 3:01 ` Mario Smarduch
2015-01-08 11:32 ` Christoffer Dall
2015-01-08 16:41 ` Mario Smarduch
2015-01-09 10:23 ` Christoffer Dall
2015-01-08 16:42 ` Mario Smarduch
2014-12-18 2:07 ` [RESEND PATCH v15 07/11] KVM: arm: page logging 2nd stage fault handling Mario Smarduch
2015-01-07 12:38 ` Christoffer Dall
2015-01-08 1:43 ` Mario Smarduch
2015-01-08 10:45 ` Christoffer Dall
2015-01-08 16:28 ` Mario Smarduch
2015-01-09 10:24 ` Christoffer Dall
2015-01-10 4:38 ` Mario Smarduch [this message]
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=54B0ACCE.4040109@samsung.com \
--to=m.smarduch@samsung$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox