From: m.smarduch@samsung•com (Mario Smarduch)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v9 2/4] arm: ARMv7 dirty page logging inital mem region write protect (w/no huge PUD support)
Date: Tue, 12 Aug 2014 14:08:17 -0700 [thread overview]
Message-ID: <53EA8241.5070805@samsung.com> (raw)
In-Reply-To: <20140812093618.GM10550@cbox>
On 08/12/2014 02:36 AM, Christoffer Dall wrote:
> On Mon, Aug 11, 2014 at 06:36:14PM -0700, Mario Smarduch wrote:
>> On 08/11/2014 12:12 PM, Christoffer Dall wrote:
>
> [...]
>
>>>> +/**
>>>> + * stage2_wp_range() - write protect stage2 memory region range
>>>> + * @kvm: The KVM pointer
>>>> + * @start: Start address of range
>>>> + * &end: End address of range
>>>> + */
>>>> +static void stage2_wp_range(struct kvm *kvm, phys_addr_t addr, phys_addr_t end)
>>>> +{
>>>> + pgd_t *pgd;
>>>> + phys_addr_t next;
>>>> +
>>>> + pgd = kvm->arch.pgd + pgd_index(addr);
>>>> + do {
>>>> + /*
>>>> + * Release kvm_mmu_lock periodically if the memory region is
>>>> + * large features like detect hung task, lock detector or lock
>>> large. Otherwise, we may see panics due to..
>>>> + * dep may panic. In addition holding the lock this long will
>>> extra white space ^^ Additionally, holding the lock for a
>>> long timer will
>>>> + * also starve other vCPUs. Applies to huge VM memory regions.
>>> ^^^ I don't understand this
>>> last remark.
>> Sorry overlooked this.
>>
>> While testing - VM regions that were small (~1GB) holding the mmu_lock
>> caused not problems, but when I was running memory regions around 2GB large
>> some kernel lockup detection/lock contention options (some selected by default)
>> caused deadlock warnings/panics in host kernel.
>>
>> This was in one my previous review comments sometime ago, I can go back
>> and find the options.
>>
>
> Just drop the last part of the comment, so the whole thing reads:
>
> /*
> * Release kvm_mmu_lock periodically if the memory region is
> * large. Otherwise, we may see kernel panics from debugging features
> * such as "detect hung task", "lock detector" or "lock dep checks".
> * Additionally, holding the lock too long will also starve other vCPUs.
> */
>
> And check the actual names of those debugging features or use the
> CONFIG_<WHATEVER> names and say "we may see kernel panics with CONFIG_X,
> CONFIG_Y, and CONFIG_Z.
>
> Makes sense?
Yep sure does.
>
> -Christoffer
>
next prev parent reply other threads:[~2014-08-12 21:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-25 0:56 [PATCH v9 0/4] arm: dirty page logging support for ARMv7 Mario Smarduch
2014-07-25 0:56 ` [PATCH v9 1/4] arm: add ARMv7 HYP API to flush VM TLBs, change generic TLB flush to support arch flush Mario Smarduch
2014-07-25 6:12 ` Alexander Graf
2014-07-25 17:37 ` Mario Smarduch
2014-08-08 17:50 ` [PATCH v9 1/4] arm: add ARMv7 HYP API to flush VM TLBs ... - looking for comments Mario Smarduch
2014-08-11 19:12 ` [PATCH v9 1/4] arm: add ARMv7 HYP API to flush VM TLBs, change generic TLB flush to support arch flush Christoffer Dall
2014-08-11 23:54 ` Mario Smarduch
2014-07-25 0:56 ` [PATCH v9 2/4] arm: ARMv7 dirty page logging inital mem region write protect (w/no huge PUD support) Mario Smarduch
2014-07-25 6:16 ` Alexander Graf
2014-07-25 17:45 ` Mario Smarduch
2014-08-11 19:12 ` Christoffer Dall
2014-08-12 0:16 ` Mario Smarduch
2014-08-12 9:32 ` Christoffer Dall
2014-08-12 23:17 ` Mario Smarduch
2014-08-12 1:36 ` Mario Smarduch
2014-08-12 9:36 ` Christoffer Dall
2014-08-12 21:08 ` Mario Smarduch [this message]
2014-07-25 0:56 ` [PATCH v9 3/4] arm: dirty log write protect mgmt. Moved x86, armv7 to generic, set armv8 ia64 mips powerpc s390 arch specific Mario Smarduch
2014-08-11 19:13 ` Christoffer Dall
2014-08-12 0:24 ` Mario Smarduch
2014-07-25 0:56 ` [PATCH v9 4/4] arm: ARMv7 dirty page logging 2nd stage page fault handling support Mario Smarduch
2014-08-11 19:13 ` Christoffer Dall
2014-08-12 1:25 ` Mario Smarduch
2014-08-12 9:50 ` Christoffer Dall
2014-08-13 1:27 ` Mario Smarduch
2014-08-13 7:30 ` Christoffer Dall
2014-08-14 1:20 ` Mario Smarduch
2014-08-15 0:01 ` Mario Smarduch
2014-08-18 12:51 ` Christoffer Dall
2014-08-18 17:42 ` 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=53EA8241.5070805@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