All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, maz@kernel.org, corbet@lwn.net,
	james.morse@arm.com, suzuki.poulose@arm.com,
	oliver.upton@linux.dev, yuzenghui@huawei.com,
	catalin.marinas@arm.com, will@kernel.org, ricarkol@google.com,
	eric.auger@redhat.com, yuzhe@nfschina.com, renzhengeek@gmail.com,
	ardb@kernel.org, peterx@redhat.com, shan.gavin@gmail.com
Subject: Re: [PATCH 4/4] KVM: Improve warning report in mark_page_dirty_in_slot()
Date: Fri, 20 Jan 2023 10:06:52 +1100	[thread overview]
Message-ID: <4bc6857d-662c-cee4-01af-c441fb4ed623@redhat.com> (raw)
In-Reply-To: <Y8lfdgcjLvtgII2a@google.com>

Hi Sean,

On 1/20/23 2:19 AM, Sean Christopherson wrote:
> On Thu, Jan 19, 2023, Gavin Shan wrote:
>> On 1/18/23 2:42 AM, Sean Christopherson wrote:
>>> On Mon, Jan 16, 2023, Gavin Shan wrote:
>>>> There are two warning reports about the dirty ring in the function.
>>>> We have the wrong assumption that the dirty ring is always enabled when
>>>> CONFIG_HAVE_KVM_DIRTY_RING is selected.
>>>
>>> No, it's not a wrong assumption, becuase it's not an assumption.  The intent is
>>> to warn irrespective of dirty ring/log enabling.  The orignal code actually warned
>>> irrespective of dirty ring support[1], again intentionally.  The
>>> CONFIG_HAVE_KVM_DIRTY_RING check was added because s390 can mark pages dirty from
>>> an worker thread[2] and s390 has no plans to support the dirty ring.
>>>
>>> The reason for warning even if dirty ring isn't enabled is so that bots can catch
>>> potential KVM bugs without having to set up a dirty ring or enable dirty logging.
>>>
>>> [1] 2efd61a608b0 ("KVM: Warn if mark_page_dirty() is called without an active vCPU")
>>> [2] e09fccb5435d ("KVM: avoid warning on s390 in mark_page_dirty")
>>>
>>
>> Thanks for the linker. I was confused when looking at the code, but now it's clear to
>> me. Thanks for your explanation. How about to add a comment there?
>>
>>    /*
>>     * The warning is expected when the dirty ring is configured,
>>     * but not enabled.
>>     */
> 
> That's not correct either.  By design, the warning can also fire if the dirty ring
> is enabled.  KVM's rule is that writes to guest memory always need to be done in
> the context of a running vCPU, with the recently added exception of
> kvm_arch_allow_write_without_running_vcpu().  That intent of the warning is to
> enforce that rule regardless of the state of the VM.
> 
> Concretely, I think you can just drop patches 3 and 4, and just fix the arm64 issues.
> 

Right, the warning report is still expected when dirty ring is enabled. My attempt
was to have comment for the confused case. Anyway, it's not a big deal. I will drop
PATCH[3] and PATCH[4] in v2.

Thanks,
Gavin


      reply	other threads:[~2023-01-19 23:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-16  4:04 [PATCH 0/4] Improve dirty ring warning report Gavin Shan
2023-01-16  4:04 ` [PATCH 1/4] KVM: arm64: Allow saving vgic3 LPI pending status in no running vcpu context Gavin Shan
2023-01-17 20:51   ` Oliver Upton
2023-01-19  1:11     ` Gavin Shan
2023-01-19 15:47       ` Marc Zyngier
2023-01-19 23:04         ` Gavin Shan
2023-01-16  4:04 ` [PATCH 2/4] KVM: arm64: Allow saving vgic3 pending tables " Gavin Shan
2023-01-16  4:04 ` [PATCH 3/4] KVM: Refactor mark_page_dirty_in_slot() Gavin Shan
2023-01-16  4:04 ` [PATCH 4/4] KVM: Improve warning report in mark_page_dirty_in_slot() Gavin Shan
2023-01-17 15:42   ` Sean Christopherson
2023-01-19  1:15     ` Gavin Shan
2023-01-19 15:19       ` Sean Christopherson
2023-01-19 23:06         ` Gavin Shan [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=4bc6857d-662c-cee4-01af-c441fb4ed623@redhat.com \
    --to=gshan@redhat.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=eric.auger@redhat.com \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=renzhengeek@gmail.com \
    --cc=ricarkol@google.com \
    --cc=seanjc@google.com \
    --cc=shan.gavin@gmail.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    --cc=yuzhe@nfschina.com \
    /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.