hi everyone:
currently, I meet a problem about qemu.Use virt-install order to create a
domain, return a failed:
order: virt-install -n centos-gg -r 1024 --disk
centos-gg.img,format=qcow2,size=10 --cdrom
/home/Centos-7-aarch64-Everything.iso --graphics vnc, listen=0.0.0.0
failed: this QEM
Add last_fpsimd_trap to notify if guest last exit reason is handling fpsimd. If
guest is using fpsimd frequently, save host's fpsimd state and restore guest's
fpsimd state and deactive fpsimd trap before returning to guest. It can avoid
guest fpsimd trap soon to improve performance.
Signed-off-
On 16/05/18 03:24, lizhuoyao wrote:
> hi everyone:
> currently, I meet a problem about qemu.Use virt-install order to
> create a domain, return a failed:
> order:_virt-install -n centos-gg -r 1024 --disk
> centos-gg.img,format=qcow2,size=10 --cdrom
> /home/Centos-7-aarch64-Everything.iso --grap
On 05/16/18 04:24, lizhuoyao wrote:
> hi everyone:
> currently, I meet a problem about qemu.Use virt-install order to create a
> domain, return a failed:
> order: virt-install -n centos-gg -r 1024 --disk
> centos-gg.img,format=qcow2,size=10 --cdrom
> /home/Centos-7-aarch64-Everything.iso --g
According to KVM commit 75d61fbc, it needs to delete the slot before
changing the KVM_MEM_READONLY flag. But QEMU commit 235e8982 only check
whether KVM_MEM_READONLY flag is set instead of changing. It doesn't
need to delete the slot if the KVM_MEM_READONLY flag is not changed.
This fixes a issue
[+Dave]
Hi Nianyao,
On 16/05/18 10:08, Tangnianyao (ICT) wrote:
> Add last_fpsimd_trap to notify if guest last exit reason is handling fpsimd.
> If guest is using fpsimd frequently, save host's fpsimd state and restore
> guest's fpsimd state and deactive fpsimd trap before returning to guest. I
On Wed, May 16, 2018 at 10:25:40AM +0100, Marc Zyngier wrote:
> [+Dave]
>
> Hi Nianyao,
>
> On 16/05/18 10:08, Tangnianyao (ICT) wrote:
> > Add last_fpsimd_trap to notify if guest last exit reason is handling
> > fpsimd. If guest is using fpsimd frequently, save host's fpsimd state and
> > rest
Hi Marc,
This is a trivial update to the previously posted v7 [1]. The only
changes are a couple of minor cosmetic changes requested by reviewers,
on-list and the addition of Acked-by/Reviewed-by tags received since the
series was posted.
Let me know if you need anything else on this.
Cheers
--
This series addresses the Spectre variant 2 issues on ARM Cortex and
Broadcom Brahma B15 CPUs. Due to the complexity of the bug, it is not
possible to verify that this series fixes any of the bugs, since it
has not been able to reproduce these exact scenarios using test
programs.
I believe that t
Add CPU part numbers for the above mentioned CPUs
Signed-off-by: Russell King
---
arch/arm/include/asm/cputype.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index cb546425da8a..adc4a3eef815 100644
--- a/arch/arm/include
Prepare the processor bug infrastructure so that it can be expanded to
check for per-processor bugs.
Signed-off-by: Russell King
---
arch/arm/include/asm/bugs.h | 4 ++--
arch/arm/kernel/Makefile| 1 +
arch/arm/kernel/bugs.c | 9 +
3 files changed, 12 insertions(+), 2 deletions(
Check for CPU bugs when secondary processors are being brought online,
and also when CPUs are resuming from a low power mode. This gives an
opportunity to check that processor specific bug workarounds are
correctly enabled for all paths that a CPU re-enters the kernel.
Signed-off-by: Russell King
Add support for per-processor bug checking - each processor function
descriptor gains a function pointer for this check, which must not be
an __init function. If non-NULL, this will be called whenever a CPU
enters the kernel via which ever path (boot CPU, secondary CPU startup,
CPU resuming, etc.)
Add a Kconfig symbol for CPUs which are vulnerable to the Spectre
attacks.
Signed-off-by: Russell King
---
arch/arm/mm/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 7f14acf67caf..8a5a1bb415c4 100644
--- a/arch/arm/mm/Kconfig
+++ b
Harden the branch predictor against Spectre v2 attacks on context
switches for ARMv7 and later CPUs. We do this by:
Cortex A9, A12, A17, A73, A75, R7, R8: invalidating the BTB.
Cortex A15, Brahma B15: invalidating the instruction cache.
Cortex A57 and Cortex A72 are not addressed in this patch.
When the branch predictor hardening is enabled, firmware must have set
the IBE bit in the auxiliary control register. If this bit has not
been set, the Spectre workarounds will not be functional.
Add validation that this bit is set, and print a warning at alert level
if this is not the case.
Sig
In order to prevent aliasing attacks on the branch predictor,
invalidate the BTB or instruction cache on CPUs that are known to be
affected when taking an abort on a address that is outside of a user
task limit:
Cortex A8, A9, A12, A17, A73, A75: flush BTB.
Cortex A15, Brahma B15: invalidate icach
Add PSCI based hardening for cores that require more complex handling in
firmware.
Signed-off-by: Russell King
---
arch/arm/mm/proc-v7-bugs.c | 50 ++
arch/arm/mm/proc-v7.S | 21 +++
2 files changed, 71 insertions(+)
diff --git a/
We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible.
So let's intercept it as early as we can by testing for the
function call number as soon as we've identified a HVC call
coming from the guest.
Signed-off-by: Russell King
---
arch/arm/kvm/hyp/hyp-entry.S | 13 -
1 file
From: Marc Zyngier
In order to avoid aliasing attacks against the branch predictor
on Cortex-A15, let's invalidate the BTB on guest exit, which can
only be done by invalidating the icache (with ACTLR[0] being set).
We use the same hack as for A12/A17 to perform the vector decoding.
Signed-off-b
Include Brahma B15 in the Spectre v2 KVM workarounds.
Signed-off-by: Russell King
---
arch/arm/include/asm/kvm_mmu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 48edb1f4ced4..fea770f78144 100644
--- a/arch/arm/include/
Report support for SMCCC_ARCH_WORKAROUND_1 to KVM guests for affected
CPUs.
Signed-off-by: Russell King
---
arch/arm/include/asm/kvm_host.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index
From: Marc Zyngier
In order to avoid aliasing attacks against the branch predictor,
let's invalidate the BTB on guest exit. This is made complicated
by the fact that we cannot take a branch before invalidating the
BTB.
We only apply this to A12 and A17, which are the only two ARM
cores on which
On Tue, May 08, 2018 at 09:45:01AM +0100, James Morse wrote:
> NOTIFY_NMI is x86's NMI, arm doesn't have anything that behaves in the same
> way,
> so doesn't use it. The equivalent notifications with NMI-like behaviour are:
> * SEA (synchronous external abort)
> * SEI (SError Interrupt)
> * SDEI
Suzuki K Poulose writes:
> On 05/14/2018 03:43 PM, Punit Agrawal wrote:
>> KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault
>> handling to add support for PUD hugepages.
>>
>> Addition of pud hugepage support enables additional hugepage
>> sizes (e.g., 1G with 4K granule) whic
On 16/05/18 12:01, Russell King wrote:
> __v7_cr7mp_proc_info:
> .long 0x410fc170
> .long 0xff00
> - __v7_proc __v7_cr7mp_proc_info, __v7_cr7mp_setup
> + __v7_proc __v7_cr7mp_proc_info, __v7_cr7mp_setup, proc_fns =
> HARDENED_BPIALL_PROCESSOR_FUNCTIONS
> .size
On Wed, May 16, 2018 at 11:32:17AM +0100, Dave Martin wrote:
> On Wed, May 16, 2018 at 10:25:40AM +0100, Marc Zyngier wrote:
> > [+Dave]
> >
> > Hi Nianyao,
> >
> > On 16/05/18 10:08, Tangnianyao (ICT) wrote:
> > > Add last_fpsimd_trap to notify if guest last exit reason is handling
> > > fpsimd
Hi Borislav,
On 16/05/18 12:05, Borislav Petkov wrote:
> On Tue, May 08, 2018 at 09:45:01AM +0100, James Morse wrote:
>> NOTIFY_NMI is x86's NMI, arm doesn't have anything that behaves in the same
>> way,
>> so doesn't use it. The equivalent notifications with NMI-like behaviour are:
>> * SEA (sy
On 5/16/2018 7:05 AM, Borislav Petkov wrote:
On Tue, May 08, 2018 at 09:45:01AM +0100, James Morse wrote:
Alternatively, I can put the fixmap-page and spinlock in some 'struct
ghes_notification' that only the NMI-like struct-ghes need. This is just moving
the indirection up a level, but it does
The aim of this series is to wire arm64's SDEI into APEI.
Since v3 the NMI fixmap entries and locks have moved into their own
structure. This moves the indirection up from the 'lock', which should
be more acceptible to polite society.
Changes are noted in each patch.
This touches a few trees, so
To support asynchronous NMI-like notifications on arm64 we need to use
the estatus-queue. These patches refactor it to allow multiple APEI
notification types to use it.
First we move the estatus-queue code higher in the file so that any
notify_foo() handler can make use of it.
This patch moves co
Refactor the estatus queue's pool grow/shrink code and notification
routine from NOTIFY_NMI's handlers. This will allow another notification
method to use the estatus queue without duplicating this code.
This patch adds rcu_read_lock()/rcu_read_unlock() around the list
list_for_each_entry_rcu() wa
oops_begin() exists to group printk() messages with the oops message
printed by die(). To reach this caller we know that platform firmware
took this error first, then notified the OS via NMI with a 'panic'
severity.
Don't wait for another CPU to release the die-lock before we can
panic(), our only
Now that the estatus queue can be used by more than one notification
method, we can move notifications that have NMI-like behaviour over to
it, and start abstracting GHES's single in_nmi() path.
Switch NOTIFY_SEA over to use the estatus queue. This makes it behave
in the same way as x86's NOTIFY_N
To split up APEIs in_nmi() path, we need any nmi-like callers to always
be in_nmi(). KVM shouldn't have to know about this, pull the RAS plumbing
out into a header file.
Currently guest synchronous external aborts are claimed as RAS
notifications by handle_guest_sea(), which is hidden in the arch
To split up APEIs in_nmi() path, we need the nmi-like callers to always
be in_nmi(). Add a helper to do the work and claim the notification.
When KVM or the arch code takes an exception that might be a RAS
notification, it asks the APEI firmware-first code whether it wants
to claim the exception.
Arm64 has multiple NMI-like notifications, but ghes.c only has one
in_nmi() path, risking deadlock if one NMI-like notification can
interrupt another.
To support this we need a fixmap entry and lock for each notification
type. But ghes_probe() attempts to process each struct ghes at probe
time, to
Now that ghes uses the fixmap addresses and locks via some indirection
we can support multiple NMI-like notifications on arm64.
These should be named after their notification method. x86's
NOTIFY_NMI already is, move it to live with the ghes_nmi list.
Change the SEA fixmap entry to be called FIX_A
If the GHES notification type is SDEI, register the provided event
number and point the callback at ghes_sdei_callback().
Signed-off-by: James Morse
Reviewed-by: Punit Agrawal
---
drivers/acpi/apei/ghes.c | 66 ++--
include/linux/arm_sdei.h | 3 +++
APEI's Generic Hardware Error Source structures do not describe
whether the SDEI event is shared or private, as this information is
discoverable via the API.
GHES needs to know whether an event is normal or critical to avoid
sharing locks or fixmap entries.
Add a helper to ask firmware for this i
arm64 can take an NMI-like error notification when user-space steps in
some corrupt memory. APEI's GHES code will call memory_failure_queue()
to schedule the recovery work. We then return to user-space, possibly
taking the fault again.
Currently the arch code unconditionally signals user-space fro
APEI is unable to do all of its error handling work in nmi-context, so
it defers non-fatal work onto the irq_work queue. arch_irq_work_raise()
sends an IPI to the calling cpu, but we can't guarantee this will be
taken before we return.
Unless we interrupted a context with irqs-masked, we can call
On 16/05/18 17:28, James Morse wrote:
> The aim of this series is to wire arm64's SDEI into APEI.
... and I missed the 'l' from the beginning of the well know inux...@kvack.org
mailing list. I won't increase the spam by resending, please fix it when
pointing out my other mistakes!
Thanks,
James
[updating Christoffer's email address]
On 16/05/18 12:01, Russell King wrote:
> Add PSCI based hardening for cores that require more complex handling in
> firmware.
>
> Signed-off-by: Russell King
> ---
> arch/arm/mm/proc-v7-bugs.c | 50
> ++
> arch/
I ever met a panic under memory pressure tests(start 20 guests and run
memhog in the host).
-begin
[35380.800950] BUG: Bad page state in process qemu-kvm pfn:dd0b6
[35380.805825] page:7fe003742d80 count:-4871 mapcount:-2126053375
On 05/16/2018 04:00 AM, Russell King wrote:
> Prepare the processor bug infrastructure so that it can be expanded to
> check for per-processor bugs.
>
> Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
--
Florian
___
kvmarm mailing list
kvma
On 05/16/2018 04:00 AM, Russell King wrote:
> Add CPU part numbers for the above mentioned CPUs
>
> Signed-off-by: Russell King
> ---
> arch/arm/include/asm/cputype.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
>
On 05/16/2018 04:00 AM, Russell King wrote:
> Check for CPU bugs when secondary processors are being brought online,
> and also when CPUs are resuming from a low power mode. This gives an
> opportunity to check that processor specific bug workarounds are
> correctly enabled for all paths that a CP
On 05/16/2018 04:00 AM, Russell King wrote:
> Add support for per-processor bug checking - each processor function
> descriptor gains a function pointer for this check, which must not be
> an __init function. If non-NULL, this will be called whenever a CPU
> enters the kernel via which ever path (
On 05/16/2018 04:01 AM, Russell King wrote:
> Add a Kconfig symbol for CPUs which are vulnerable to the Spectre
> attacks.
>
> Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
--
Florian
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
h
On 05/16/2018 04:01 AM, Russell King wrote:
> Include Brahma B15 in the Spectre v2 KVM workarounds.
>
> Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
--
Florian
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbi
On 05/16/2018 04:01 AM, Russell King wrote:
> When the branch predictor hardening is enabled, firmware must have set
> the IBE bit in the auxiliary control register. If this bit has not
> been set, the Spectre workarounds will not be functional.
>
> Add validation that this bit is set, and print
select virtio video also failed.
order:virt-install -n centos-gg -r 1024 --disk
centos-gg.img,format=qcow2,size=10 --cdrom
/home/lzy/CentOs-7-aarch64-Everything.iso --video virtio
failed: PCI controller at index 1 (0x01) has bus='0x01',but index must be
larger than bus.
(I have tryed in other
On 05/16/2018 04:01 AM, Russell King wrote:
> In order to prevent aliasing attacks on the branch predictor,
> invalidate the BTB or instruction cache on CPUs that are known to be
> affected when taking an abort on a address that is outside of a user
> task limit:
>
> Cortex A8, A9, A12, A17, A73,
On 05/16/2018 04:01 AM, Russell King wrote:
> When the branch predictor hardening is enabled, firmware must have set
> the IBE bit in the auxiliary control register. If this bit has not
> been set, the Spectre workarounds will not be functional.
>
> Add validation that this bit is set, and print
you said VGA cannot be realistically supported on ARM at the moment,then wrote
it's ok checked with VNC.Did you experiment in x86 or arm?
There is likely no -device(--device) parameter in "virt-install -h". Sorry, I'm
not familiar with virt-install much. Can you show the order you use?
Thanks!
56 matches
Mail list logo