From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: kernel-team@android.com, kvm@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
George Cherian <gcherian@marvell.com>,
"Zengtao \(B\)" <prime.zeng@hisilicon.com>,
Andre Przywara <andre.przywara@arm.com>,
Will Deacon <will@kernel.org>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 00/17] KVM: arm64: Preliminary NV patches
Date: Tue, 07 Jul 2020 12:49:21 +0100 [thread overview]
Message-ID: <336e9d1e8d2566d131e4326d71ddd161@kernel.org> (raw)
In-Reply-To: <c5cd34b2-3360-e634-fe0f-9bbb91275235@arm.com>
On 2020-07-07 12:24, Alexandru Elisei wrote:
> Hi,
>
> On 7/6/20 1:54 PM, Marc Zyngier wrote:
>> Hi all,
>>
>> In order not to repeat the 90+ patch series that resulted in a
>> deafening silence last time, I've extracted a smaller set of patches
>> that form the required dependencies that allow the rest of the 65 NV
>> patches to be added on top. Yes, it is that bad.
>>
>> The one real feature here is support for the ARMv8.4-TTL extension at
>> Stage-2 only. The reason to support it is that it helps the hypervisor
>> a lot when it comes to finding out how much to invalidate. It is thus
>> always "supported" with NV.
>>
>> The rest doesn't contain any functionality change. Most of it reworks
>> existing data structures and adds new accessors for the things that
>> get moved around. The reason for this is that:
>>
>> - With NV, we end-up with multiple Stage-2 MMU contexts per VM instead
>> of a single one. This requires we divorce struct kvm from the S2 MMU
>> configuration. Of course, we stick with a single MMU context for
>> now.
>>
>> - With ARMv8.4-NV, a number of system register accesses are turned
>> into memory accesses into the so-called VNCR page. It is thus
>> convenient to make this VNCR page part of the vcpu context and avoid
>> copying data back and forth. For this to work, we need to make sure
>> that all the VNCR-aware sysregs are moved into our per-vcpu sys_regs
>> array instead of leaving in other data structures (the timers, for
>> example). The VNCR page itself isn't introduced with these patches.
>>
>> - As some of these data structures change, we need a way to isolate
>> the userspace ABI from such change.
>>
>> There is also a number of cleanups that were in the full fat series
>> that I decided to move early to get them out of the way.
>>
>> The whole this is a bit of a mix of vaguely unrelated "stuff", but it
>> all comes together if you look at the final series. This applies on
>> top of David Brazdil's series splitting the VHE and nVHE objects.
>>
>> I plan on taking this early into v5.9, and I really mean it this time!
>>
>> Catalin: How do you want to proceed for patches 2, 3, and 4? I could
>> make a stable branch that gets you pull into the arm64 tree, or the
>> other way around. Just let me know.
>>
>> Thanks,
>>
>> M.
>>
>> * From v2:
>> - Rebased on top of David's el2-obj series
>
> I tried to apply the patches on top of v5.8-rc1, but I get a conflict
> on the very
> first patch. I guess it's because I don't have the el2-obj series. Is
> that v4 of
> "Split off nVHE hyp code" patches from David Brazil?
You need the slightly amended version (kvm-arm6/el2-obj-v4.1 from my
tree).
Otherwise, just pick kvmarm/next, which has everything put together
in one scary lot.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
prev parent reply other threads:[~2020-07-07 11:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 12:54 [PATCH v3 00/17] KVM: arm64: Preliminary NV patches Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 01/17] KVM: arm64: Factor out stage 2 page table data from struct kvm Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 02/17] arm64: Detect the ARMv8.4 TTL feature Marc Zyngier
2020-07-06 17:24 ` Catalin Marinas
2020-07-06 12:54 ` [PATCH v3 03/17] arm64: Document SW reserved PTE/PMD bits in Stage-2 descriptors Marc Zyngier
2020-07-06 17:25 ` Catalin Marinas
2020-07-06 12:54 ` [PATCH v3 04/17] arm64: Add level-hinted TLB invalidation helper Marc Zyngier
2020-07-06 17:24 ` Catalin Marinas
2020-07-06 12:54 ` [PATCH v3 05/17] KVM: arm64: Use TTL hint in when invalidating stage-2 translations Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 06/17] KVM: arm64: Introduce accessor for ctxt->sys_reg Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 07/17] KVM: arm64: hyp: Use ctxt_sys_reg/__vcpu_sys_reg instead of raw sys_regs access Marc Zyngier
2020-07-07 12:57 ` Alexandru Elisei
2020-07-06 12:54 ` [PATCH v3 08/17] KVM: arm64: sve: Use __vcpu_sys_reg() " Marc Zyngier
2020-07-07 12:58 ` Alexandru Elisei
2020-07-06 12:54 ` [PATCH v3 09/17] KVM: arm64: pauth: Use ctxt_sys_reg() " Marc Zyngier
2020-07-07 13:05 ` Alexandru Elisei
2020-07-06 12:54 ` [PATCH v3 10/17] KVM: arm64: debug: Drop useless vpcu parameter Marc Zyngier
2020-07-07 13:19 ` Alexandru Elisei
2020-07-06 12:54 ` [PATCH v3 11/17] KVM: arm64: Make struct kvm_regs userspace-only Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 12/17] KVM: arm64: Move ELR_EL1 to the system register array Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 13/17] KVM: arm64: Move SP_EL1 " Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 14/17] KVM: arm64: Disintegrate SPSR array Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 15/17] KVM: arm64: Move SPSR_EL1 to the system register array Marc Zyngier
2020-07-06 12:54 ` [PATCH v3 16/17] KVM: arm64: timers: Rename kvm_timer_sync_hwstate to kvm_timer_sync_user Marc Zyngier
2020-07-07 17:00 ` Alexandru Elisei
2020-07-06 12:54 ` [PATCH v3 17/17] KVM: arm64: timers: Move timer registers to the sys_regs file Marc Zyngier
2020-07-08 16:39 ` Alexandru Elisei
2020-07-06 17:27 ` [PATCH v3 00/17] KVM: arm64: Preliminary NV patches Catalin Marinas
2020-07-07 8:51 ` Marc Zyngier
2020-07-07 11:24 ` Alexandru Elisei
2020-07-07 11:48 ` Alexandru Elisei
2020-07-07 11:49 ` Marc Zyngier [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=336e9d1e8d2566d131e4326d71ddd161@kernel.org \
--to=maz@kernel.org \
--cc=Dave.Martin@arm.com \
--cc=alexandru.elisei@arm.com \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--cc=gcherian@marvell.com \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=prime.zeng@hisilicon.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).