Re: [PATCH kvmtool v2 0/6] arm: Add support for firmware booting

Hi Julien, On Thu, Jan 10, 2019 at 02:20:40PM +, Julien Thierry wrote: > This series is based on the virtio reset series[1] posted earlier. > > We would like to be able to load firmwares like UEFI in kvmtool. > > The series contains: > A way to load the firmware into RAM and an option to be

Re: [PATCH kvmtool v2 00/13] Implement reset of virtio devices

On Thu, Jan 10, 2019 at 02:12:37PM +, Julien Thierry wrote: > This series was developped by Jean-Philippe and is needed for a series > I'll be posting shortly after to load firmwares on arm kvmtool. > > Currently, when a guest tries to reset a device, a lot of ressources > aren't reset

Re: [PATCH v7 22/25] ACPI / APEI: Kick the memory_failure() queue for synchronous errors

On Mon, Dec 03, 2018 at 06:06:10PM +, James Morse wrote: > memory_failure() offlines or repairs pages of memory that have been > discovered to be corrupt. These may be detected by an external > component, (e.g. the memory controller), and notified via an IRQ. > In this case the work is queued

Re: [PATCH v7 20/25] ACPI / APEI: Use separate fixmap pages for arm64 NMI-like notifications

On Mon, Dec 03, 2018 at 06:06:08PM +, James Morse wrote: > Now that ghes notification helpers provide the fixmap slots and > take the lock themselves, multiple NMI-like notifications can > be used on arm64. > > These should be named after their notification method as they can't > all be

Re: [PATCH v7 19/25] ACPI / APEI: Only use queued estatus entry during _in_nmi_notify_one()

On Mon, Dec 03, 2018 at 06:06:07PM +, James Morse wrote: > Each struct ghes has an worst-case sized buffer for storing the > estatus. If an error is being processed by ghes_proc() in process > context this buffer will be in use. If the error source then triggers > an NMI-like notification, the

[PATCH 0/4] Fix some KVM/HYP interactions with kprobes

Hi guys, When looking at Masami Hiramatsu's kprobe cleanup series, it occurred to me the 'no KVM' isn't just about the EL1/EL2 split on non-VHE systems, but whether KVM is prepared to handle stepping on a breakpoint. It's not. This moves all the VHE-only KVM functions that run during world

[PATCH 2/4] arm64: kprobe: Always blacklist the KVM world-switch code

On systems with VHE the kernel and KVM's world-switch code run at the same exception level. Code that is only used on a VHE system does not need to be annotated as __hyp_text as it can reside anywhere in the kernel text. __hyp_text was also used to prevent kprobes from patching breakpoint

[PATCH 3/4] arm64: hyp-stub: Forbid kprobing of the hyp-stub

The hyp-stub is loaded by the kernel's early startup code at EL2 during boot, before KVM takes ownership later. The hyp-stub's text is part of the regular kernel text, meaning it can be kprobed. A breakpoint in the hyp-stub causes the CPU to spin in el2_sync_invalid. Add it to the __hyp_text.

[PATCH 4/4] arm64: hibernate: Clean the __hyp_text to PoC after resume

During resume hibernate restores all physical memory. Any memory that is accessed with the MMU disabled needs to be cleaned to the PoC. KVMs __hyp_text was previously ommited as it runs with the MMU enabled, but now that the hyp-stub is located in this section, we must clean __hyp_text too. This

[PATCH 1/4] KVM: arm64: Forbid kprobing of the VHE world-switch code

On systems with VHE the kernel and KVM's world-switch code run at the same exception level. Code that is only used on a VHE system does not need to be annotated as __hyp_text as it can reside anywhere in the kernel text. __hyp_text was also used to prevent kprobes from patching breakpoint

Re: [PATCH 1/2] KVM: arm/arm64: Add save/restore support for firmware workaround state

On Mon, 7 Jan 2019 13:17:37 + Steven Price wrote: Hi, > On 07/01/2019 12:05, Andre Przywara wrote: > > KVM implements the firmware interface for mitigating cache > > speculation vulnerabilities. Guests may use this interface to > > ensure mitigation is active. > > If we want to migrate such

[PATCH v9 10/26] arm64: kvm: Unmask PMR before entering guest

Interrupts masked by ICC_PMR_EL1 will not be signaled to the CPU. This means that hypervisor will not receive masked interrupts while running a guest. Avoid this by making sure ICC_PMR_EL1 is unmasked when we enter a guest. Signed-off-by: Julien Thierry Acked-by: Catalin Marinas Cc:

[PATCH 4.19 19/99] arm64: Dont trap host pointer auth use to EL2

4.19-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ] To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and

[PATCH 4.19 18/99] arm64/kvm: consistently handle host HCR_EL2 flags

4.19-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit 4eaed6aa2c628101246bcabc91b203bfac1193f8 ] In KVM we define the configuration of HCR_EL2 for a VHE HOST in HCR_HOST_VHE_FLAGS, but we don't have a similar definition for the non-VHE

[PATCH 4.9 12/51] arm64: Dont trap host pointer auth use to EL2

4.9-stable review patch. If anyone has any objections, please let me know. -- [ Backport of upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ] To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions

[PATCH 4.9 11/51] arm64/kvm: consistently handle host HCR_EL2 flags

4.9-stable review patch. If anyone has any objections, please let me know. -- [ Backport of upstream commit 4eaed6aa2c628101246bcabc91b203bfac1193f8 ] In KVM we define the configuration of HCR_EL2 for a VHE HOST in HCR_HOST_VHE_FLAGS, but we don't have a similar definition for

[PATCH 4.14 11/59] arm64/kvm: consistently handle host HCR_EL2 flags

4.14-stable review patch. If anyone has any objections, please let me know. -- [ Backport of upstream commit 4eaed6aa2c628101246bcabc91b203bfac1193f8 ] In KVM we define the configuration of HCR_EL2 for a VHE HOST in HCR_HOST_VHE_FLAGS, but we don't have a similar definition for

Re: [PATCH v7 18/25] ACPI / APEI: Split ghes_read_estatus() to allow a peek at the CPER length

On Mon, Dec 03, 2018 at 06:06:06PM +, James Morse wrote: > ghes_read_estatus() reads the record address, then the record's > header, then performs some sanity checks before reading the > records into the provided estatus buffer. > > To provide this estatus buffer the caller must know the size

[PATCH 4.14 12/59] arm64: Dont trap host pointer auth use to EL2

4.14-stable review patch. If anyone has any objections, please let me know. -- [ Backport of upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ] To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions

[PATCH 4.20 016/111] arm64: Dont trap host pointer auth use to EL2

4.20-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit b3669b1e1c09890d61109a1a8ece2c5b66804714 ] To allow EL0 (and/or EL1) to use pointer authentication functionality, we must ensure that pointer authentication instructions and

[PATCH 4.20 015/111] arm64/kvm: consistently handle host HCR_EL2 flags

4.20-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit 4eaed6aa2c628101246bcabc91b203bfac1193f8 ] In KVM we define the configuration of HCR_EL2 for a VHE HOST in HCR_HOST_VHE_FLAGS, but we don't have a similar definition for the non-VHE

Re: [PATCH v7 17/25] ACPI / APEI: Pass ghes and estatus separately to avoid a later copy

On Mon, Dec 03, 2018 at 06:06:05PM +, James Morse wrote: > The NMI-like notifications scribble over ghes->estatus, before > copying it somewhere else. If this interrupts the ghes_probe() code > calling ghes_proc() on each struct ghes, the data is corrupted. > > All the NMI-like notifications

Re: [PATCH v7 11/25] ACPI / APEI: Move NOTIFY_SEA between the estatus-queue and NOTIFY_NMI

On Mon, Dec 03, 2018 at 06:05:59PM +, James Morse wrote: > The estatus-queue code is currently hidden by the NOTIFY_NMI #ifdefs. > Once NOTIFY_SEA starts using the estatus-queue we can stop hiding > it as each architecture has a user that can't be turned off. > > Split the existing

Re: [PATCH v7 0/7] Add virtio-iommu driver

Hi, On 18/01/2019 15:51, Michael S. Tsirkin wrote: > > On Tue, Jan 15, 2019 at 12:19:52PM +, Jean-Philippe Brucker wrote: >> Implement the virtio-iommu driver, following specification v0.9 [1]. >> >> This is a simple rebase onto Linux v5.0-rc2. We now use the >> dev_iommu_fwspec_get() helper