On Wed, Mar 10, 2021 at 05:57:30PM +, Quentin Perret wrote:
> Introduce the infrastructure in KVM enabling to copy CPU feature
> registers into EL2-owned data-structures, to allow reading sanitised
> values directly at EL2 in nVHE.
>
> Given that only a subset of these features are being read
On Wed, Mar 10, 2021 at 05:57:51PM +, Quentin Perret wrote:
> When KVM runs in nVHE protected mode, use the host stage 2 to unmap the
> hypervisor sections by marking them as owned by the hypervisor itself.
> The long-term goal is to ensure the EL2 code can remain robust
> regardless of the
On Wed, Mar 10, 2021 at 05:57:48PM +, Quentin Perret wrote:
> When KVM runs in protected nVHE mode, make use of a stage 2 page-table
> to give the hypervisor some control over the host memory accesses. The
> host stage 2 is created lazily using large block mappings if possible,
> and will
On Wed, Mar 10, 2021 at 05:57:47PM +, Quentin Perret wrote:
> Since the host stage 2 will be identity mapped, and since it will own
> most of memory, it would preferable for performance to try and use large
> block mappings whenever that is possible. To ease this, introduce a new
> helper in
On Wed, Mar 10, 2021 at 05:57:46PM +, Quentin Perret wrote:
> In order to ease its re-use in other code paths, refactor
> stage2_map_set_prot_attr() to not depend on a stage2_map_data struct.
> No functional change intended.
>
> Signed-off-by: Quentin Perret
> ---
>
On Wed, Mar 10, 2021 at 05:57:45PM +, Quentin Perret wrote:
> As the host stage 2 will be identity mapped, all the .hyp memory regions
> and/or memory pages donated to protected guestis will have to marked
> invalid in the host stage 2 page-table. At the same time, the hypervisor
> will need a
On Wed, Mar 10, 2021 at 05:57:44PM +, Quentin Perret wrote:
> kvm_set_invalid_pte() currently only clears bit 0 from a PTE because
> stage2_map_walk_table_post() needs to be able to follow the anchor. In
> preparation for re-using bits 63-02 from invalid PTEs, make sure to zero
Why do you
On Wed, Mar 10, 2021 at 05:57:34PM +, Quentin Perret wrote:
> Previous commits have introduced infrastructure to enable the EL2 code
> to manage its own stage 1 mappings. However, this was preliminary work,
> and none of it is currently in use.
>
> Put all of this together by elevating the
On Wed, Mar 10, 2021 at 05:57:32PM +, Quentin Perret wrote:
> We will soon need to turn the EL2 stage 1 MMU on and off in nVHE
> protected mode, so refactor the set_sctlr_el1 macro to make it usable
> for that purpose.
>
> Signed-off-by: Quentin Perret
> ---
>
On Wed, Mar 10, 2021 at 05:57:33PM +, Quentin Perret wrote:
> When memory protection is enabled, the EL2 code needs the ability to
> create and manage its own page-table. To do so, introduce a new set of
> hypercalls to bootstrap a memory management system at EL2.
>
> This leads to the
On Wed, Mar 10, 2021 at 05:57:29PM +, Quentin Perret wrote:
> When memory protection is enabled, the hyp code will require a basic
> form of memory management in order to allocate and free memory pages at
> EL2. This is needed for various use-cases, including the creation of hyp
> mappings or
On Wed, Mar 10, 2021 at 05:57:28PM +, Quentin Perret wrote:
> In order to use the kernel list library at EL2, introduce stubs for the
> CONFIG_DEBUG_LIST out-of-lines calls.
>
> Signed-off-by: Quentin Perret
> ---
> arch/arm64/kvm/hyp/nvhe/Makefile | 2 +-
> arch/arm64/kvm/hyp/nvhe/stub.c
On Wed, Mar 10, 2021 at 05:57:23PM +, Quentin Perret wrote:
> In preparation for enabling the creation of page-tables at EL2, factor
> all memory allocation out of the page-table code, hence making it
> re-usable with any compatible memory allocator.
>
> No functional changes intended.
>
>
On Thursday 11 Mar 2021 at 10:37:28 (+), Quentin Perret wrote:
> On Thursday 04 Mar 2021 at 11:54:48 (+), 'Andrew Scull' via kernel-team
> wrote:
> > Keep track of the cpu that a vcpu's FP state was last loaded onto. This
> > information is needed in order to tell whether a vcpu's latest
On Thursday 04 Mar 2021 at 11:54:48 (+), 'Andrew Scull' via kernel-team
wrote:
> Keep track of the cpu that a vcpu's FP state was last loaded onto. This
> information is needed in order to tell whether a vcpu's latest FP state
> is already loaded on a cpu to avoid unnecessary reloading.
>
>
On Thursday 04 Mar 2021 at 11:54:47 (+), 'Andrew Scull' via kernel-team
wrote:
> smp_procesor_id() works off of the cpu_number per-cpu variable. Create
> an nVHE hyp version of cpu_number and initialize it to the same value as
> the host when creating the hyp per-cpu regions.
>
>
Hi Marc,
On 2021/3/11 16:43, Marc Zyngier wrote:
> Digging this patch back from my Inbox...
Yeah, thanks ;-)
>
> On Fri, 22 Jan 2021 08:36:50 +,
> Keqian Zhu wrote:
>>
>> The MMIO region of a device maybe huge (GB level), try to use block
>> mapping in stage2 to speedup both map and unmap.
Hi Marc,
On 3/11/21 11:00 AM, Marc Zyngier wrote:
> KVM/arm64 has forever used a 40bit default IPA space, partially
> due to its 32bit heritage (where the only choice is 40bit).
>
> However, there are implementations in the wild that have a *cough*
> much smaller *cough* IPA space, which leads
On 09/03/2021 11:01, Peter Maydell wrote:
On Mon, 1 Mar 2021 at 14:23, Steven Price wrote:
A new capability (KVM_CAP_ARM_MTE) identifies that the kernel supports
granting a guest access to the tags, and provides a mechanism for the
VMM to enable it.
A new ioctl (KVM_ARM_MTE_COPY_TAGS)
On 2021/3/11 17:14, Marc Zyngier wrote:
> On Wed, 27 Jan 2021 12:13:36 +,
> Shenming Lu wrote:
>>
>> From: Zenghui Yu
>>
>> When setting the forwarding path of a VLPI (switch to the HW mode),
>> we could also transfer the pending state from irq->pending_latch to
>> VPT (especially in
On 2021/3/11 17:09, Marc Zyngier wrote:
> On Wed, 27 Jan 2021 12:13:35 +,
> Shenming Lu wrote:
>>
>> After pausing all vCPUs and devices capable of interrupting, in order
>> to save the information of all interrupts, besides flushing the pending
>> states in kvm’s vgic, we also try to flush
On 2021/3/11 16:57, Marc Zyngier wrote:
> On Wed, 27 Jan 2021 12:13:34 +,
> Shenming Lu wrote:
>>
>> With GICv4.1 and the vPE unmapped, which indicates the invalidation
>> of any VPT caches associated with the vPE, we can get the VLPI state
>> by peeking at the VPT. So we add a function for
On Thu, Mar 11, 2021 at 11:35:29AM +, Mark Rutland wrote:
> Acked-by: Mark Rutland
Upon reflection, maybe I should spell my own name correctly:
Acked-by: Mark Rutland
... lest you decide to add a Mocked-by tag instead ;)
Mark.
___
kvmarm
On Wed, Mar 10, 2021 at 06:20:22PM +, Will Deacon wrote:
> On Wed, Mar 10, 2021 at 05:49:17PM +, Marc Zyngier wrote:
> > On Wed, 10 Mar 2021 16:15:47 +,
> > Will Deacon wrote:
> > > On Wed, Mar 10, 2021 at 04:05:17PM +, Marc Zyngier wrote:
> > > > On Wed, 10 Mar 2021 15:46:26
On Thu, Mar 11, 2021 at 10:00:16AM +, Marc Zyngier wrote:
> When registering a memslot, we check the size and location of that
> memslot against the IPA size to ensure that we can provide guest
> access to the whole of the memory.
>
> Unfortunately, this check rejects memslot that end-up at
On Thu, Mar 11, 2021 at 10:00:15AM +, Marc Zyngier wrote:
> KVM/arm64 has forever used a 40bit default IPA space, partially
> due to its 32bit heritage (where the only choice is 40bit).
>
> However, there are implementations in the wild that have a *cough*
> much smaller *cough* IPA space,
KVM/arm64 has forever used a 40bit default IPA space, partially
due to its 32bit heritage (where the only choice is 40bit).
However, there are implementations in the wild that have a *cough*
much smaller *cough* IPA space, which leads to a misprogramming of
VTCR_EL2, and a guest that is stuck on
When registering a memslot, we check the size and location of that
memslot against the IPA size to ensure that we can provide guest
access to the whole of the memory.
Unfortunately, this check rejects memslot that end-up at the exact
limit of the addressing capability for a given IPA size. For
This is a rework of an initial patch posted a couple of days back[1]
While working on enabling KVM on "reduced IPA size" systems, I realise
we have a couple of issues, some of while do impact userspace.
The first issue is that we accept the creation of a "default IPA size"
VM (40 bits) even when
On Thu, 11 Mar 2021 07:03:21 +,
Shenming Lu wrote:
>
> Hi,
>
> Sorry to bother again, I am really hoping a response for this series. :-)
Done, and sorry for the delay. There are a number of issues that need
fixing, I'm afraid.
Thanks,
M.
--
Without deviation from the norm,
On Wed, 27 Jan 2021 12:13:36 +,
Shenming Lu wrote:
>
> From: Zenghui Yu
>
> When setting the forwarding path of a VLPI (switch to the HW mode),
> we could also transfer the pending state from irq->pending_latch to
> VPT (especially in migration, the pending states of VLPIs are restored
>
On Wed, 27 Jan 2021 12:13:35 +,
Shenming Lu wrote:
>
> After pausing all vCPUs and devices capable of interrupting, in order
> to save the information of all interrupts, besides flushing the pending
> states in kvm’s vgic, we also try to flush the states of VLPIs in the
> virtual pending
On Wed, 27 Jan 2021 12:13:34 +,
Shenming Lu wrote:
>
> With GICv4.1 and the vPE unmapped, which indicates the invalidation
> of any VPT caches associated with the vPE, we can get the VLPI state
> by peeking at the VPT. So we add a function for this.
>
> Signed-off-by: Shenming Lu
> ---
>
Digging this patch back from my Inbox...
On Fri, 22 Jan 2021 08:36:50 +,
Keqian Zhu wrote:
>
> The MMIO region of a device maybe huge (GB level), try to use block
> mapping in stage2 to speedup both map and unmap.
>
> Especially for unmap, it performs TLBI right after each invalidation
>
34 matches
Mail list logo
