linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	maz@kernel.org, will@kernel.org, james.morse@arm.com,
	julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
	jean-philippe@linaro.org, Alexandru.Elisei@arm.com,
	qperret@google.com, jonathan.cameron@huawei.com,
	linuxarm@huawei.com
Subject: Re: [PATCH v4 0/4] kvm/arm: New VMID allocator based on asid
Date: Tue, 18 Jan 2022 12:32:55 +0000	[thread overview]
Message-ID: <Yeazd1lLuYm4k3lH@arm.com> (raw)
In-Reply-To: <20211122121844.867-1-shameerali.kolothum.thodi@huawei.com>

Hi Shameer,

On Mon, Nov 22, 2021 at 12:18:40PM +0000, Shameer Kolothum wrote:
>  -TLA+ model. Modified the asidalloc model to incorporate the new
>   VMID algo. The main differences are,
>   -flush_tlb_all() instead of local_tlb_flush_all() on rollover.
>   -Introduced INVALID_VMID and vCPU Sched Out logic.
>   -No CnP (Removed UniqueASIDAllCPUs & UniqueASIDActiveTask invariants).
>   -Removed  UniqueVMIDPerCPU invariant for now as it looks like
>    because of the speculative fetching with flush_tlb_all() there
>    is a small window where this gets triggered. If I change the
>    logic back to local_flush_tlb_all(), UniqueVMIDPerCPU seems to
>    be fine. With my limited knowledge on TLA+ model, it is not
>    clear to me whether this is a problem with the above logic
>    or the VMID model implementation. Really appreciate any help
>    with the model.
>    The initial VMID TLA+ model is here,
>    https://github.com/shamiali2008/kernel-tla/tree/private-vmidalloc-v1

I only had a brief look at the TLA+ model and I don't understand why you
have a separate 'shed_out' process. It would run in parallel with the
'sched' but AFAICT you can't really schedule a guest out while you are
in the middle of scheduling it in. I'd rather use the same 'sched'
process and either schedule in an inactive task or schedule out an
active one for a given CPU.

Also active_vmids[] for example is defined on the CPUS domain but you
call vcpu_sched_out() from a process that's not in the CPUS domain but
the SCHED_OUT one.

Regarding UniqueVMIDPerCPU, I think we need to figure out why it
happens. The fact that flush_tlb_all() was made to simulate the
speculative TLB loads is not relevant. In a different spec I have,
arm64kpti.tla, I just used another process that invokes an update_tlbs()
macro so that it can happen at any time. I didn't bother to update the
ASID spec in a similar way but it may be useful. The corresponding
UniqueASIDPerCPU meant that for any two TLB entries on a single CPU, if
they correspond to different tasks (pgd), they should have different
ASIDs. That's a strong requirement, otherwise we end up with the wrong
translation.

Why did you remove the CnP? Do we have this disabled for KVM guests?

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-01-18 12:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-22 12:18 [PATCH v4 0/4] kvm/arm: New VMID allocator based on asid Shameer Kolothum
2021-11-22 12:18 ` [PATCH v4 1/4] KVM: arm64: Introduce a new VMID allocator for KVM Shameer Kolothum
2022-01-21  7:35   ` Reiji Watanabe
2022-01-21  8:44     ` Shameerali Kolothum Thodi
2021-11-22 12:18 ` [PATCH v4 2/4] KVM: arm64: Make VMID bits accessible outside of allocator Shameer Kolothum
2021-11-22 12:18 ` [PATCH v4 3/4] KVM: arm64: Align the VMID allocation with the arm64 ASID Shameer Kolothum
2021-11-22 12:18 ` [PATCH v4 4/4] KVM: arm64: Make active_vmids invalid on vCPU schedule out Shameer Kolothum
2022-01-05 13:25 ` [PATCH v4 0/4] kvm/arm: New VMID allocator based on asid Shameerali Kolothum Thodi
2022-01-18 12:32 ` Catalin Marinas [this message]
2022-01-19  9:23   ` Shameerali Kolothum Thodi
2022-01-19 11:49     ` Catalin Marinas
2022-01-19 12:30       ` Shameerali Kolothum Thodi
2022-02-08 17:37 ` Marc Zyngier

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=Yeazd1lLuYm4k3lH@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Alexandru.Elisei@arm.com \
    --cc=james.morse@arm.com \
    --cc=jean-philippe@linaro.org \
    --cc=jonathan.cameron@huawei.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=maz@kernel.org \
    --cc=qperret@google.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).