On 2021/1/5 21:47, Marc Zyngier wrote:
> On 2021-01-05 13:02, Shenming Lu wrote:
>> On 2021/1/5 17:13, Marc Zyngier wrote:
>>> On 2021-01-04 08:16, Shenming Lu wrote:
After pausing all vCPUs and devices capable of interrupting, in order
to save the information of all interrupts, besides f
Hi Marc, Catalin,
I'd like to propose a new dirty tracking solution that combines hardware based
dirty tracking (DBM) and software based dirty tracking (memory abort). Hope to
get your opinions about it.
The core idea is that we do not enable hardware dirty at start (do not add DBM
bit).
When a
On Mon, Jan 4, 2021 at 8:20 AM Marc Zyngier wrote:
>
> In order to be able to override CPU features at boot time,
> let's add a command line parser that matches options of the
> form "cpureg.feature=value", and store the corresponding
> value into the override val/mask pair.
>
> No features are cu
On 2021/1/5 19:40, Marc Zyngier wrote:
> On 2021-01-05 09:13, Marc Zyngier wrote:
>> On 2021-01-04 08:16, 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
On Mon, Jan 4, 2021 at 8:20 AM Marc Zyngier wrote:
>
> For completeness, let's document the HVC_VHE_RESTART stub.
>
> Signed-off-by: Marc Zyngier
> ---
> Documentation/virt/kvm/arm/hyp-abi.rst | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/virt/kvm/arm/hyp-abi.rs
On Mon, Jan 4, 2021 at 8:20 AM Marc Zyngier wrote:
>
> As we want to be able to disable VHE at runtime, let's match
> "id_aa64mmfr1.vh=" from the command line as an override.
> This doesn't have much effect yet as out boot code doesn't look
Typo: out -> our
> at the cpufeature, but only at the HW
On 2021/1/5 17:25, Marc Zyngier wrote:
> On 2021-01-04 08:16, 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
On Mon, Jan 4, 2021 at 7:50 AM Marc Zyngier wrote:
>
> As we are about to change the way a VHE system boots, let's
> provide the core helper, in the form of a stub hypercall that
> enables VHE and replicates the full EL1 context at EL2, thanks
> to EL1 and VHE-EL2 being extremely similar.
>
> On e
On Tue, 05 Jan 2021 20:35:35 +,
Jing Zhang wrote:
>
> On Mon, Jan 4, 2021 at 7:50 AM Marc Zyngier wrote:
> >
> > As we are about to change the way a VHE system boots, let's
> > provide the core helper, in the form of a stub hypercall that
> > enables VHE and replicates the full EL1 context a
On Tue, Jan 05, 2021 at 04:36:51PM +, Andre Przywara wrote:
> @@ -77,10 +117,20 @@ arch_get_random_seed_long_early(unsigned long *v)
> {
> WARN_ON(system_state != SYSTEM_BOOTING);
>
> - if (!__early_cpu_has_rndr())
> - return false;
> + if (__early_cpu_has_rndr())
Hi Marc,
On 1/5/21 4:25 PM, Marc Zyngier wrote:
> Hi Alex,
>
> On 2021-01-05 15:49, Alexandru Elisei wrote:
>> Hi Marc,
>>
>> On 1/4/21 5:27 PM, Marc Zyngier wrote:
>>> KVM_ARM_PMU only existed for the benefit of 32bit ARM hosts,
>>> and makes no sense now that we are 64bit only. Get rid of it.
>>
The ARM architected TRNG firmware interface, described in ARM spec
DEN0098, defines an ARM SMCCC based interface to a true random number
generator, provided by firmware.
This can be discovered via the SMCCC >=v1.1 interface, and provides
up to 192 bits of entropy per call.
Hook this SMC call into
From: Ard Biesheuvel
Provide a hypervisor implementation of the ARM architected TRNG firmware
interface described in ARM spec DEN0098. All function IDs are implemented,
including both 32-bit and 64-bit versions of the TRNG_RND service, which
is the centerpiece of the API.
The API is backed by th
From: Ard Biesheuvel
Implement arch_get_random_seed_*() for ARM based on the firmware
or hypervisor provided entropy source described in ARM DEN0098.
This will make the kernel's random number generator consume entropy
provided by this interface, at early boot, and periodically at
runtime when re
The ARM DEN0098 document describe an SMCCC based firmware service to
deliver hardware generated random numbers. Its existence is advertised
according to the SMCCC v1.1 specification.
Add a (dummy) call to probe functions implemented in each architecture
(ARM and arm64), to determine the existence
From: Ard Biesheuvel
The ARM architected TRNG firmware interface, described in ARM spec
DEN0098, define an ARM SMCCC based interface to a true random number
generator, provided by firmware.
Add the definitions of the SMCCC functions as defined by the spec.
Signed-off-by: Ard Biesheuvel
Signed-
Hi,
a small update to v4, also observing the priority of SMCCC vs. RNDR in
the early version of the function (as reported by broonie).
Plus adding review tags and rebasing on v5.11-rc2. Changelog below.
Will, Catalin: it would be much appreciated if you could consider taking
patch 1/5. This conta
Hi Alex,
On 2021-01-05 15:49, Alexandru Elisei wrote:
Hi Marc,
On 1/4/21 5:27 PM, Marc Zyngier wrote:
KVM_ARM_PMU only existed for the benefit of 32bit ARM hosts,
and makes no sense now that we are 64bit only. Get rid of it.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/Kconfig | 8 --
Hi Marc,
On 1/4/21 5:27 PM, Marc Zyngier wrote:
> KVM_ARM_PMU only existed for the benefit of 32bit ARM hosts,
> and makes no sense now that we are 64bit only. Get rid of it.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/kvm/Kconfig | 8
> arch/arm64/kvm/Makefile | 2 +-
> include
Hi Marc,
On 1/5/21 2:04 PM, Marc Zyngier wrote:
> On 2021-01-05 13:54, Alexandru Elisei wrote:
>> Hi Marc,
>>
>> On 12/31/20 3:09 PM, Marc Zyngier wrote:
>>> Although not a problem right now, it flared up while working
>>> on some other aspects of the code-base. Remove the useless
>>> semicolon.
>
On 2021-01-05 13:54, Alexandru Elisei wrote:
Hi Marc,
On 12/31/20 3:09 PM, Marc Zyngier wrote:
Although not a problem right now, it flared up while working
on some other aspects of the code-base. Remove the useless
semicolon.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/sys_regs.c | 2 +-
Hi Marc,
On 12/31/20 3:09 PM, Marc Zyngier wrote:
> Although not a problem right now, it flared up while working
> on some other aspects of the code-base. Remove the useless
> semicolon.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/kvm/sys_regs.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On 2021-01-05 13:02, Shenming Lu wrote:
On 2021/1/5 17:13, Marc Zyngier wrote:
On 2021-01-04 08:16, 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 tr
On Mon, 4 Jan 2021 19:38:44 +0800, Shannon Zhao wrote:
> Commit d82755b2e781 ("KVM: arm64: Kill off CONFIG_KVM_ARM_HOST") deletes
> CONFIG_KVM_ARM_HOST option, it should use CONFIG_KVM instead.
>
> Just remove CONFIG_KVM_ARM_HOST here.
Applied to next, thanks!
[1/1] arm64: cpufeature: remove non
On 2021/1/5 17:13, Marc Zyngier wrote:
> On 2021-01-04 08:16, 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 t
On Wed, Dec 23, 2020 at 12:11:31PM +, Marc Zyngier wrote:
> If someone happens to write the following code:
>
> b 1f
> init_el2_state vhe
> 1:
> [...]
>
> they will be in for a long debugging session, as the label "1f"
> will be resolved *inside* the init_el2_state ma
On Mon, Jan 04, 2021 at 07:38:44PM +0800, Shannon Zhao wrote:
> Commit d82755b2e781 ("KVM: arm64: Kill off CONFIG_KVM_ARM_HOST") deletes
> CONFIG_KVM_ARM_HOST option, it should use CONFIG_KVM instead.
>
> Just remove CONFIG_KVM_ARM_HOST here.
>
> Signed-off-by: Shannon Zhao
Acked-by: Catalin Ma
On 2021-01-05 09:13, Marc Zyngier wrote:
On 2021-01-04 08:16, 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
v
On 1/5/21 3:38 PM, Catalin Marinas wrote:
> On Tue, Jan 05, 2021 at 05:22:21PM +0800, Keqian Zhu wrote:
>> The local variable irq is added in commit a26388152531 ("arm64:
>> Remove custom IRQ stat accounting"), but forget to remove in
>> commit 5089bc51f81f ("arm64/smp: Use irq_desc_kstat_cpu()
On 2021/1/5 18:08, Catalin Marinas wrote:
> On Tue, Jan 05, 2021 at 05:22:21PM +0800, Keqian Zhu wrote:
>> The local variable irq is added in commit a26388152531 ("arm64:
>> Remove custom IRQ stat accounting"), but forget to remove in
>> commit 5089bc51f81f ("arm64/smp: Use irq_desc_kstat_cpu()
On Tue, Jan 05, 2021 at 05:22:21PM +0800, Keqian Zhu wrote:
> The local variable irq is added in commit a26388152531 ("arm64:
> Remove custom IRQ stat accounting"), but forget to remove in
> commit 5089bc51f81f ("arm64/smp: Use irq_desc_kstat_cpu() in
> arch_show_interrupts()"). Just remove it.
>
On 2021-01-04 08:16, 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
into kvm’s vgic first). And we
The local variable irq is added in commit a26388152531 ("arm64:
Remove custom IRQ stat accounting"), but forget to remove in
commit 5089bc51f81f ("arm64/smp: Use irq_desc_kstat_cpu() in
arch_show_interrupts()"). Just remove it.
Signed-off-by: Keqian Zhu
---
arch/arm64/kernel/smp.c | 1 -
1 file
On 2021-01-04 08:16, 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 tables into guest RAM, but we
On 2021-01-04 23:39, Jing Zhang wrote:
On Mon, Dec 28, 2020 at 4:50 AM Marc Zyngier wrote:
As we are about to change the way a VHE system boots, let's
provide the core helper, in the form of a stub hypercall that
enables VHE and replicates the full EL1 context at EL2, thanks
to EL1 and VHE-EL2
35 matches
Mail list logo
