On 2018/2/1 10:40, Hanjun Guo wrote:
> On 2018/1/31 23:05, Marc Zyngier wrote:
>> On 31/01/18 14:38, Ard Biesheuvel wrote:
>>> On 31 January 2018 at 14:35, Ard Biesheuvel
>>> wrote:
On 31 January 2018 at 14:11, Marc Zyngier wrote:
> On 31/01/18 13:56, Hanjun Guo wrote:
>> Hi Marc,
>
On 2018/1/31 23:05, Marc Zyngier wrote:
> On 31/01/18 14:38, Ard Biesheuvel wrote:
>> On 31 January 2018 at 14:35, Ard Biesheuvel
>> wrote:
>>> On 31 January 2018 at 14:11, Marc Zyngier wrote:
On 31/01/18 13:56, Hanjun Guo wrote:
> Hi Marc,
>
> On 2018/1/30 1:45, Marc Zyngier wr
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient
for observability of memory accesses that occur before ICC_SGI1R_EL1
writes.
A DSB instruction
On Wed, Jan 31, 2018 at 06:36:38PM +, Marc Zyngier wrote:
> On 31/01/18 18:03, Andrew Jones wrote:
> > On Wed, Jan 31, 2018 at 05:45:56PM +, Marc Zyngier wrote:
> >> On 31/01/18 17:38, Andrew Jones wrote:
> >>> On Mon, Jan 29, 2018 at 05:45:50PM +, Marc Zyngier wrote:
> Although we
On 31/01/18 18:03, Andrew Jones wrote:
> On Wed, Jan 31, 2018 at 05:45:56PM +, Marc Zyngier wrote:
>> On 31/01/18 17:38, Andrew Jones wrote:
>>> On Mon, Jan 29, 2018 at 05:45:50PM +, Marc Zyngier wrote:
Although we've implemented PSCI 1.0 and 1.1, nothing can select them
Since all
/0day-ci/linux/commits/Marc-Zyngier/arm64-Add-SMCCC-v1-1-support-and-CVE-2017-5715-Spectre-variant-2-mitigation/20180131-234336
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-next/core
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian
On Wed, Jan 31, 2018 at 05:45:56PM +, Marc Zyngier wrote:
> On 31/01/18 17:38, Andrew Jones wrote:
> > On Mon, Jan 29, 2018 at 05:45:50PM +, Marc Zyngier wrote:
> >> Although we've implemented PSCI 1.0 and 1.1, nothing can select them
> >> Since all the new PSCI versions are backward compat
On 31/01/18 17:38, Andrew Jones wrote:
> On Mon, Jan 29, 2018 at 05:45:50PM +, Marc Zyngier wrote:
>> Although we've implemented PSCI 1.0 and 1.1, nothing can select them
>> Since all the new PSCI versions are backward compatible, we decide to
>> default to the latest version of the PSCI implem
On Mon, Jan 29, 2018 at 05:45:50PM +, Marc Zyngier wrote:
> Although we've implemented PSCI 1.0 and 1.1, nothing can select them
> Since all the new PSCI versions are backward compatible, we decide to
> default to the latest version of the PSCI implementation. This is no
> different from doing
2018-01-31 10:34+0100, Christoffer Dall:
> Hi Paolo and Radim,
>
> Apologies for getting this pull request to you rather late; there were a
> number of issues that I wanted to make sure we could fix properly before
> including some of the changes in this pull request.
>
> The changes for this ver
On 31/01/18 14:38, Ard Biesheuvel wrote:
> On 31 January 2018 at 14:35, Ard Biesheuvel wrote:
>> On 31 January 2018 at 14:11, Marc Zyngier wrote:
>>> On 31/01/18 13:56, Hanjun Guo wrote:
Hi Marc,
On 2018/1/30 1:45, Marc Zyngier wrote:
> static int enable_psci_bp_hardening(void
On 31 January 2018 at 14:35, Ard Biesheuvel wrote:
> On 31 January 2018 at 14:11, Marc Zyngier wrote:
>> On 31/01/18 13:56, Hanjun Guo wrote:
>>> Hi Marc,
>>>
>>> On 2018/1/30 1:45, Marc Zyngier wrote:
static int enable_psci_bp_hardening(void *data)
{
const struct arm64_cpu_
On 31 January 2018 at 14:11, Marc Zyngier wrote:
> On 31/01/18 13:56, Hanjun Guo wrote:
>> Hi Marc,
>>
>> On 2018/1/30 1:45, Marc Zyngier wrote:
>>> static int enable_psci_bp_hardening(void *data)
>>> {
>>> const struct arm64_cpu_capabilities *entry = data;
>>>
>>> -if (psci_ops.get_ver
On 31/01/18 12:14, Christoffer Dall wrote:
> When introducing support for irqchip in userspace we needed a way to
> mask the timer signal to prevent the guest continuously exiting due to a
> screaming timer.
>
> We did this by disabling the corresponding percpu interrupt on the
> host interrupt co
On 31/01/18 13:56, Hanjun Guo wrote:
> Hi Marc,
>
> On 2018/1/30 1:45, Marc Zyngier wrote:
>> static int enable_psci_bp_hardening(void *data)
>> {
>> const struct arm64_cpu_capabilities *entry = data;
>>
>> -if (psci_ops.get_version)
>> +if (psci_ops.get_version) {
>> +
Hi Marc,
On 2018/1/30 1:45, Marc Zyngier wrote:
> static int enable_psci_bp_hardening(void *data)
> {
> const struct arm64_cpu_capabilities *entry = data;
>
> - if (psci_ops.get_version)
> + if (psci_ops.get_version) {
> + if (check_smccc_arch_workaround_1(entry))
> +
On Wed, Jan 31, 2018 at 2:16 PM, Andrew Jones wrote:
> On Wed, Jan 31, 2018 at 12:23:09PM +0100, Christoffer Dall wrote:
>> Did I mention that I hate this feature, which keeps breaking, and
>> which really isn't covered by a simple kvm-unit-test script?
>>
>
> Doesn't running the kvm-unit-tests' t
On Wed, Jan 31, 2018 at 12:23:09PM +0100, Christoffer Dall wrote:
> Did I mention that I hate this feature, which keeps breaking, and
> which really isn't covered by a simple kvm-unit-test script?
>
Doesn't running the kvm-unit-tests' timer tests with
'-machine kernel_irqchip=off' exercise at leas
On 12.01.2018 13:07, Christoffer Dall wrote:
There is no need to enable/disable traps to FP registers on every switch
to/from the VM, because the host kernel does not use this resource
without calling vcpu_put. We can therefore move things around enough
that we still always write FPEXC32_EL2 bef
Hi Christoffer,
On 12.01.2018 13:07, Christoffer Dall wrote:
There is no need to enable/disable traps to FP registers on every switch
to/from the VM, because the host kernel does not use this resource
without calling vcpu_put. We can therefore move things around enough
that we still always writ
When introducing support for irqchip in userspace we needed a way to
mask the timer signal to prevent the guest continuously exiting due to a
screaming timer.
We did this by disabling the corresponding percpu interrupt on the
host interrupt controller, because we cannot rely on the host system
hav
On 31/01/18 11:23, Christoffer Dall wrote:
> On Wed, Jan 31, 2018 at 12:19 PM, Marc Zyngier wrote:
>> On 31/01/18 10:05, Christoffer Dall wrote:
>>> On Wed, Jan 31, 2018 at 09:37:31AM +, Marc Zyngier wrote:
On 30/01/18 12:46, Christoffer Dall wrote:
> When introducing support for irqc
On Wed, Jan 31, 2018 at 12:19 PM, Marc Zyngier wrote:
> On 31/01/18 10:05, Christoffer Dall wrote:
>> On Wed, Jan 31, 2018 at 09:37:31AM +, Marc Zyngier wrote:
>>> On 30/01/18 12:46, Christoffer Dall wrote:
When introducing support for irqchip in userspace we needed a way to
mask the
On 31/01/18 10:05, Christoffer Dall wrote:
> On Wed, Jan 31, 2018 at 09:37:31AM +, Marc Zyngier wrote:
>> On 30/01/18 12:46, Christoffer Dall wrote:
>>> When introducing support for irqchip in userspace we needed a way to
>>> mask the timer signal to prevent the guest continuously exiting due t
Hi Drew,
On Wed, Jan 31, 2018 at 11:54 AM, Andrew Jones wrote:
> On Wed, Jan 31, 2018 at 10:34:40AM +0100, Christoffer Dall wrote:
>> From: Andrew Jones
>>
>> Since commit 93390c0a1b20 ("arm64: KVM: Hide unsupported AArch64 CPU
>> features from guests") we can hide cpu features from guests. Appl
On Wed, Jan 31, 2018 at 10:34:40AM +0100, Christoffer Dall wrote:
> From: Andrew Jones
>
> Since commit 93390c0a1b20 ("arm64: KVM: Hide unsupported AArch64 CPU
> features from guests") we can hide cpu features from guests. Apply
> this to a long standing issue where guests see a PMU available, bu
On Wed, Jan 31, 2018 at 09:37:31AM +, Marc Zyngier wrote:
> On 30/01/18 12:46, Christoffer Dall wrote:
> > When introducing support for irqchip in userspace we needed a way to
> > mask the timer signal to prevent the guest continuously exiting due to a
> > screaming timer.
> >
> > We did this
On 30/01/18 12:46, Christoffer Dall wrote:
> When introducing support for irqchip in userspace we needed a way to
> mask the timer signal to prevent the guest continuously exiting due to a
> screaming timer.
>
> We did this by disabling the corresponding percpu interrupt on the
> host interrupt co
We were not decrementing the static key count in the right location.
kvm_arch_vcpu_destroy() is only called to clean up after a failed
VCPU create attempt, whereas kvm_arch_vcpu_free() is called on teardown
of the VM as well. Move the static key decrement call to
kvm_arch_vcpu_free().
Acked-by: M
After the recently introduced support for level-triggered mapped
interrupt, I accidentally left the VCPU thread busily going back and
forward between the guest and the hypervisor whenever the guest was
blocking, because I would always incorrectly report that a timer
interrupt was pending.
This is
From: Luis de Bethencourt
The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_emulate.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion
When I introduced a static key to avoid work in the critical path for
userspace irqchips which is very rarely used, I accidentally messed up
my logic and used && where I should have used ||, because the point was
to short-circuit the evaluation in case userspace irqchips weren't even
in use.
This
From: James Morse
cpu_pm_enter() calls the pm notifier chain with CPU_PM_ENTER, then if
there is a failure: CPU_PM_ENTER_FAILED.
When KVM receives CPU_PM_ENTER it calls cpu_hyp_reset() which will
return us to the hyp-stub. If we subsequently get a CPU_PM_ENTER_FAILED,
KVM does nothing, leaving t
Add an extra temporary register parameter to uaccess_ttbr0_disable which
is about to be required for arm64 PAN support.
This patch doesn't introduce any functional change but ensures that the
kernel compiles once the KVM/ARM tree is merged with the arm64 tree by
ensuring a trivially mergable confl
Add an extra temporary register parameter to uaccess_ttbr0_enable which
is about to be required for arm64 PAN support.
This patch doesn't introduce any functional change but ensures that the
kernel compiles once the KVM/ARM tree is merged with the arm64 tree by
ensuring a trivially mergable confli
From: Marc Zyngier
The vcpu parameter isn't used for anything, and gets in the way of
further cleanups. Let's get rid of it.
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_mmu.h | 7 ++-
arch/arm64/include/asm/kvm_mm
From: Marc Zyngier
So far, we loose the Exec property whenever we take permission
faults, as we always reconstruct the PTE/PMD from scratch. This
can be counter productive as we can end-up with the following
fault sequence:
X -> RO -> ROX -> RW -> RWX
Instead, we can lookup the existing
From: Marc Zyngier
The only case where we actually need to perform a dcache maintenance
is when we map the page for the first time, and subsequent permission
faults do not require cache maintenance. Let's make it conditional
on not being a permission fault (and thus a translation fault).
Reviewe
From: Marc Zyngier
We've so far eagerly invalidated the icache, no matter how
the page was faulted in (data or prefetch abort).
But we can easily track execution by setting the XN bits
in the S2 page tables, get the prefetch abort at HYP and
perform the icache invalidation at that time only.
As
From: Marc Zyngier
Calling __cpuc_coherent_user_range to invalidate the icache on
a PIPT icache machine has some pointless overhead, as it starts
by cleaning the dcache to the PoU, while we're guaranteed to
have already cleaned it to the PoC.
As KVM is the only user of such a feature, let's impl
From: Marc Zyngier
As we're about to make S2 page-tables eXecute Never by default,
add the required bits for both PMDs and PTEs.
Reviewed-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
1 file changed, 2 inse
From: Marc Zyngier
We currently tightly couple dcache clean with icache invalidation,
but KVM could do without the initial flush to PoU, as we've
already flushed things to PoC.
Let's introduce invalidate_icache_range which is limited to
invalidating the icache from the linear mapping (and thus
h
The reason I added this documentation originally was that the concept of
"never taking the interrupt", but just use the timer to generate an exit
from the guest, was confusing to most, and we had to explain it several
times over. But as we can clearly see, we've failed to update the
documentation
From: Marc Zyngier
kvm_hyp.h has an odd dependency on kvm_mmu.h, which makes the
opposite inclusion impossible. Let's start with breaking that
useless dependency.
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_hyp.h | 1 -
From: Marc Zyngier
As we're about to introduce opportunistic invalidation of the icache,
let's split dcache and icache flushing.
Acked-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_mmu.h | 60 --
Commit 0c0543a128bd1c6a4c8610d0d9d869053fa2fbf5 breaks migration and
introduces a regression with existing userspace because it introduces an
ordering requirement of setting up all VCPU features before writing ID
registers which we didn't have before.
Revert this commit for now until we have a pro
The VGIC can now support the life-cycle of mapped level-triggered
interrupts, and we no longer have to read back the timer state on every
exit from the VM if we had an asserted timer interrupt signal, because
the VGIC already knows if we hit the unlikely case where the guest
disables the timer with
The timer logic was designed after a strict idea of modeling an
interrupt line level in software, meaning that only transitions in the
level need to be reported to the VGIC. This works well for the timer,
because the arch timer code is in complete control of the device and can
track the transition
For mapped IRQs (with the HW bit set in the LR) we have to follow some
rules of the architecture. One of these rules is that VM must not be
allowed to deactivate a virtual interrupt with the HW bit set unless the
physical interrupt is also active.
This works fine when injecting mapped interrupts,
We currently check if the VM has a userspace irqchip in several places
along the critical path, and if so, we do some work which is only
required for having an irqchip in userspace. This is unfortunate, as we
could avoid doing any work entirely, if we didn't have to support
irqchip in userspace.
The GIC sometimes need to sample the physical line of a mapped
interrupt. As we know this to be notoriously slow, provide a callback
function for devices (such as the timer) which can do this much faster
than talking to the distributor, for example by comparing a few
in-memory values. Fall back t
Level-triggered mapped IRQs are special because we only observe rising
edges as input to the VGIC, and we don't set the EOI flag and therefore
are not told when the level goes down, so that we can re-queue a new
interrupt when the level goes up.
One way to solve this problem is to side-step the lo
We are about to distinguish between userspace accesses and mmio traps
for a number of the mmio handlers. When the requester vcpu is NULL, it
means we are handling a userspace access.
Factor out the functionality to get the request vcpu into its own
function, mostly so we have a common place to do
The __this_cpu_read() and __this_cpu_write() functions already implement
checks for the required preemption levels when using
CONFIG_DEBUG_PREEMPT which gives you nice error messages and such.
Therefore there is no need to explicitly check this using a BUG_ON() in
the code (which we don't do for ot
From: Vasyl Gomonovych
Fix ptr_ret.cocci warnings:
virt/kvm/arm/vgic/vgic-its.c:971:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Signed-off-by: Vasyl Gomonovych
Signed-off-by: Christoffer
From: Andrew Jones
Since commit 93390c0a1b20 ("arm64: KVM: Hide unsupported AArch64 CPU
features from guests") we can hide cpu features from guests. Apply
this to a long standing issue where guests see a PMU available, but
it's not, because it was not enabled by KVM's userspace.
Signed-off-by: A
Hi Paolo and Radim,
Apologies for getting this pull request to you rather late; there were a
number of issues that I wanted to make sure we could fix properly before
including some of the changes in this pull request.
The changes for this version include icache invalidation optimizations
(improvi
On 30/01/18 12:42, Christoffer Dall wrote:
> When I introduced a static key to avoid work in the critical path for
> userspace irqchips which is very rarely used, I accidentally messed up
> my logic and used && where I should have used ||, because the point was
> to short-circuit the evaluation in
On 30/01/18 12:42, Christoffer Dall wrote:
> We were not decrementing the static key count in the right location.
> kvm_arch_vcpu_destroy() is only called to clean up after a failed
> VCPU create attempt, whereas kvm_arch_vcpu_free() is called on teardown
> of the VM as well. Move the static key d
On 30/01/18 12:42, Christoffer Dall wrote:
> After the recently introduced support for level-triggered mapped
> interrupt, I accidentally left the VCPU thread busily going back and
> forward between the guest and the hypervisor whenever the guest was
> blocking, because I would always incorrectly r
Hi Christoffer,
On 30.01.2018 13:49, Christoffer Dall wrote:
Hi Tomasz,
On Mon, Jan 22, 2018 at 01:32:57PM +0100, Tomasz Nowicki wrote:
On 20.12.2017 12:36, Christoffer Dall wrote:
The VGIC can now support the life-cycle of mapped level-triggered
interrupts, and we no longer have to read back
Hi Christoffer,
On 30.01.2018 13:49, Christoffer Dall wrote:
Hi Tomasz,
On Mon, Jan 22, 2018 at 01:32:57PM +0100, Tomasz Nowicki wrote:
On 20.12.2017 12:36, Christoffer Dall wrote:
The VGIC can now support the life-cycle of mapped level-triggered
interrupts, and we no longer have to read back
Hi Christoffer,
I confirm the patch fixes the issue I saw before. I do not see
unnecessary WFI trap storm any more, hence:
Tested-by: Tomasz Nowicki
Thank you for fixing this.
Tomasz
On 30.01.2018 13:42, Christoffer Dall wrote:
After the recently introduced support for level-triggered map
63 matches
Mail list logo
