On Tue, Nov 03, 2020 at 05:14:45PM +, Marc Zyngier wrote:
> As the kernel never sets HCR_EL2.EnSCXT, accesses to SCXTNUM_ELx
> will trap to EL2. Let's handle that as gracefully as possible
> by injecting an UNDEF exception into the guest. This is consistent
> with the guest's view of
On Tue, Nov 03, 2020 at 05:14:44PM +, Marc Zyngier wrote:
> The only thing that access_amu() does is to inject an UNDEF exception,
> so let's rename it to the clearer undef_access(). We'll reuse that
> for some other system registers.
>
> Signed-off-by: Marc Zyngier
> ---
>
On Tue, Nov 03, 2020 at 05:14:43PM +, Marc Zyngier wrote:
> We now expose ID_AA64PFR0_EL1.CSV2=1 to guests running on hosts
> that are immune to Spectre-v2, but that don't have this field set,
> most likely because they predate the specification.
>
> However, this prevents the migration of
On 05/11/2020 17:15, kernel test robot wrote:
> Hi Andre,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v5.10-rc2 next-20201105]
> [cannot apply to arm64/for-next/core kvmarm/next arm-perf/for-next/p
Hi Andre,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.10-rc2 next-20201105]
[cannot apply to arm64/for-next/core kvmarm/next arm-perf/for-next/perf]
[If your patch is applied to the wrong git tree, kindly drop us a note
Hi Andre,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.10-rc2 next-20201105]
[cannot apply to arm64/for-next/core kvmarm/next arm-perf/for-next/perf]
[If your patch is applied to the wrong git tree, kindly drop us a note
On Thu, 5 Nov 2020 at 15:13, Marc Zyngier wrote:
>
> On 2020-11-05 12:56, Andre Przywara wrote:
> > From: Ard Biesheuvel
> >
> > Provide a hypervisor implementation of the ARM architected TRNG
> > firmware
> > interface described in ARM spec DEN0098. All function IDs are
> > implemented,
> >
Hi Marc,
> > +static DEFINE_PER_CPU(hyp_spinlock_t, psci_cpu_lock);
> > DEFINE_PER_CPU(enum kvm_nvhe_psci_state, psci_cpu_state);
> >
> > static u64 get_psci_func_id(struct kvm_cpu_context *host_ctxt)
> > @@ -76,9 +79,32 @@ static __noreturn unsigned long
> > psci_forward_noreturn(struct
On Wed, 4 Nov 2020 at 19:37, 'David Brazdil' via kernel-team
wrote:
>
> Add a handler of CPU_SUSPEND host PSCI SMCs. When invoked, it determines
> whether the requested power state loses context, ie. whether it is
> indistinguishable from a WHI or whether it is a deeper sleep state that
Do you
> > Add a handler of CPU_SUSPEND host PSCI SMCs. When invoked, it determines
> > whether the requested power state loses context, ie. whether it is
> > indistinguishable from a WHI or whether it is a deeper sleep state that
> Do you mean WFI?
Of course, sorry, just a typo.
On 2020-11-05 14:34, Ard Biesheuvel wrote:
On Thu, 5 Nov 2020 at 15:30, Mark Rutland wrote:
On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
> > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > > On Thu, Nov 05,
On Thu, Nov 05, 2020 at 03:34:01PM +0100, Ard Biesheuvel wrote:
> On Thu, 5 Nov 2020 at 15:30, Mark Rutland wrote:
> > On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> > > On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
> >
> > > > That said, I'm not sure it's great to plumb
On Thu, Nov 05, 2020 at 02:29:49PM +, Mark Brown wrote:
> On Thu, Nov 05, 2020 at 02:03:22PM +, Mark Rutland wrote:
> > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
>
> > > It isn't obvious to me why we don't fall through to trying the SMCCC
> > > TRNG here if for some
On Thu, 5 Nov 2020 at 15:30, Mark Rutland wrote:
>
> On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> > On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
> > > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > > > On Thu, Nov 05, 2020 at 12:56:55PM +, Andre
On 05/11/2020 14:03, Mark Rutland wrote:
> On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
>> On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
>>
>>> static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
>>> {
>>> + struct arm_smccc_res res;
>>>
On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
> > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > > On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
> > That said, I'm not sure it's great to plumb
On Thu, Nov 05, 2020 at 02:03:22PM +, Mark Rutland wrote:
> On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > It isn't obvious to me why we don't fall through to trying the SMCCC
> > TRNG here if for some reason the v8.5-RNG didn't give us something.
> > Definitely an obscure
On 2020-11-05 12:56, Andre Przywara wrote:
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
On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
>
> On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
> >
> > > static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
> > > {
> > > + struct
On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
>
> > static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
> > {
> > + struct arm_smccc_res res;
> > unsigned long val;
> > - bool ok =
Using arm-none-eabi-gcc triggers the following compilation errors:
$ ./configure --arch=arm --cross-prefix=arm-none-eabi-
$ make clean
$ make -j8
[..]
arm/pmu.c: In function 'pmu_probe':
arm/pmu.c:1000:47: error: format '%c' expects argument of type 'int', but
argument 3 has type 'long unsigned
Marc, James, Julien, Suzuki,
argh, I am sorry, I forgot to CC: you guys on this patch. This is v2 of
Ard's original patch, fixing the endianess problem pointed out by Drew.
It's on the kvm-arm ML:
https://lists.cs.columbia.edu/pipermail/kvmarm/2020-November/043138.html
or here in my repo:
On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
> static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
> {
> + struct arm_smccc_res res;
> unsigned long val;
> - bool ok = arch_get_random_seed_long();
>
> - *v = val;
> - return ok;
>
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
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
The ARM architected TRNG firmware interface, described in ARM spec
DEN0098[1], defines an ARM SMCCC based interface to a true random number
generator, provided by firmware.
This series collects all the patches implementing this in various
places: as a user feeding into the ARCH_RANDOM pool, both
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
On 2020-11-04 18:36, David Brazdil wrote:
Add a handler of the CPU_OFF PSCI host SMC trapped in KVM nVHE hyp
code.
When invoked, it changes the recorded state of the core to OFF before
forwarding the call to EL3. If the call fails, it changes the state
back
to ON and returns the error to the
On 2020-11-04 18:36, David Brazdil wrote:
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 36
On Wed, 28 Oct 2020 at 01:26, Alexandru Elisei wrote:
>
> Stage 2 faults triggered by the profiling buffer attempting to write to
> memory are reported by the SPE hardware by asserting a buffer management
> event interrupt. Interrupts are by their nature asynchronous, which means
> that the guest
On Wed, 28 Oct 2020 at 01:26, Alexandru Elisei wrote:
>
> user_mem_abort() is already a long and complex function, let's make it
> slightly easier to understand by abstracting the algorithm for choosing the
> stage 2 IPA entry size into its own function.
>
> This also makes it possible to reuse
On Wed, 28 Oct 2020 at 01:26, Alexandru Elisei wrote:
>
> From: Sudeep Holla
>
> To configure the virtual SPE buffer management interrupt number, we use a
> VCPU kvm_device ioctl, encapsulating the KVM_ARM_VCPU_SPE_IRQ attribute
> within the KVM_ARM_VCPU_SPE_CTRL group.
>
> After configuring the
On 2020-11-04 18:36, David Brazdil wrote:
Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
host is using PSCI v0.1, KVM's PSCI proxy needs to use the same IDs.
Expose the array holding the information.
Signed-off-by: David Brazdil
---
drivers/firmware/psci/psci.c | 10
On 2020-11-04 18:36, David Brazdil wrote:
The version of PSCI that the kernel should use to communicate with
firmware is typically obtained from probing PSCI_VERSION. However, that
doesn't work for PSCI v0.1 where the host gets the information from
DT/ACPI, or if PSCI is not supported / was
张东旭 reported a regression seen with CentOS
when migrating from an old kernel to a new one. The problem was
that QEMU rejected the migration since KVM_GET_REG_LIST reported
a register was missing on the destination. Extra registers are OK
on the destination, but not missing ones. The regression
The AA64ZFR0_EL1 accessors are just the general accessors with
its visibility function open-coded. It also skips the if-else
chain in read_id_reg, but there's no reason not to go there.
Indeed consolidating ID register accessors and removing lines
of code make it worthwhile.
Remove the
REG_HIDDEN_GUEST and REG_HIDDEN_USER are always used together.
Consolidate them into a single REG_HIDDEN flag. We can always
add another flag later if some register needs to expose itself
differently to the guest than it does to userspace.
No functional change intended.
Signed-off-by: Andrew
ID registers are RAZ until they've been allocated a purpose, but
that doesn't mean they should be removed from the KVM_GET_REG_LIST
list. So far we only have one register, SYS_ID_AA64ZFR0_EL1, that
is hidden from userspace when its function, SVE, is not present.
Expose SYS_ID_AA64ZFR0_EL1 to
The instruction encodings of ID registers are preallocated. Until an
encoding is assigned a purpose the register is RAZ. KVM's general ID
register accessor functions already support both paths, RAZ or not.
If for each ID register we can determine if it's RAZ or not, then all
ID registers can build
41 matches
Mail list logo
