Re: [PATCH v4 08/20] irqchip/gic-v4.1: Plumb get/set_irqchip_state SGI callbacks
On 2020-02-20 03:11, Zenghui Yu wrote:
Hi Marc,
On 2020/2/18 23:31, Marc Zyngier wrote:
diff --git a/drivers/irqchip/irq-gic-v3-its.c
b/drivers/irqchip/irq-gic-v3-its.c
index 7656b353a95f..0ed286dba827 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -144,7 +144,7 @@ struct event_lpi_map {
u16 *col_map;
irq_hw_number_t lpi_base;
int nr_lpis;
- raw_spinlock_t vlpi_lock;
+ raw_spinlock_t map_lock;
So we use map_lock to protect both LPI's and VLPI's mapping affinity of
a device, and use vpe_lock to protect vPE's affinity, OK.
struct its_vm *vm;
struct its_vlpi_map *vlpi_maps;
int nr_vlpis;
@@ -240,15 +240,33 @@ static struct its_vlpi_map *get_vlpi_map(struct
irq_data *d)
return NULL;
}
-static int irq_to_cpuid(struct irq_data *d)
+static int irq_to_cpuid_lock(struct irq_data *d, unsigned long
*flags)
{
- struct its_device *its_dev = irq_data_get_irq_chip_data(d);
struct its_vlpi_map *map = get_vlpi_map(d);
+ int cpu;
- if (map)
- return map->vpe->col_idx;
+ if (map) {
+ raw_spin_lock_irqsave(&map->vpe->vpe_lock, *flags);
+ cpu = map->vpe->col_idx;
+ } else {
+ struct its_device *its_dev = irq_data_get_irq_chip_data(d);
+ raw_spin_lock_irqsave(&its_dev->event_map.map_lock, *flags);
+ cpu = its_dev->event_map.col_map[its_get_event_id(d)];
+ }
- return its_dev->event_map.col_map[its_get_event_id(d)];
+ return cpu;
+}
This helper is correct for normal LPIs and VLPIs, but wrong for per-vPE
IRQ (doorbell) and vSGIs. irq_data_get_irq_chip_data() gets confused by
both of them.
Yes, I've fixed that in the current state of the tree last week. Do have
a
look if you can, but it seems to survive on both the model with v4.1 and
my D05.
[...]
- rdbase = per_cpu_ptr(gic_rdists->rdist,
vpe->col_idx)->rd_base;
+ cpu = irq_to_cpuid_lock(d, &flags);
+ rdbase = per_cpu_ptr(gic_rdists->rdist, cpu)->rd_base;
gic_write_lpir(d->parent_data->hwirq, rdbase +
GICR_INVLPIR);
wait_for_syncr(rdbase);
+ irq_to_cpuid_unlock(d, flags);
} else {
its_vpe_send_cmd(vpe, its_send_inv);
}
Do we really need to grab the vpe_lock for those which are belong to
the same irqchip with its_vpe_set_affinity()? The IRQ core code should
already ensure the mutual exclusion among them, wrong?
I've been trying to think about that, but jet-lag keeps getting in the
way.
I empirically think that you are right, but I need to go and check the
various
code paths to be sure. Hopefully I'll have a bit more brain space next
week.
For sure this patch tries to do too many things at once...
M.
--
Jazz is not dead. It just smells funny...
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 16/20] KVM: arm64: GICv4.1: Allow SGIs to switch between HW and SW interrupts
Hi Zenghui, On 2020-02-20 03:55, Zenghui Yu wrote: Hi Marc, On 2020/2/14 22:57, Marc Zyngier wrote: In order to let a guest buy in the new, active-less SGIs, we need to be able to switch between the two modes. Handle this by stopping all guest activity, transfer the state from one mode to the other, and resume the guest. Signed-off-by: Marc Zyngier [...] diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c index 1bc09b523486..2c9fc13e2c59 100644 --- a/virt/kvm/arm/vgic/vgic-v3.c +++ b/virt/kvm/arm/vgic/vgic-v3.c @@ -540,6 +540,8 @@ int vgic_v3_map_resources(struct kvm *kvm) goto out; } + if (kvm_vgic_global_state.has_gicv4_1) + vgic_v4_configure_vsgis(kvm); dist->ready = true; out: Is there any reason to invoke vgic_v4_configure_vsgis() here? This is called on the first VCPU run, through kvm_vgic_map_resources(). Shouldn't the vSGI configuration only driven by a GICD_CTLR.nASSGIreq writing (from guest, or from userspace maybe)? What I'm trying to catch here is the guest that has been restored with nASSGIreq set. At the moment, we don't do anything on the userspace side, because the vmm could decide to write that particular bit multiple times, and switching between the two modes is expensive (not to mention that all the vcpus may not have been created yet). Moving it to the first run makes all these pitfalls go away (we have the final nASSSGIreq value, and all the vcpus are accounted for). Does this make sense to you? Thanks, M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 09/20] irqchip/gic-v4.1: Plumb set_vcpu_affinity SGI callbacks
Hi Zenghui,
On 2020-02-20 03:37, Zenghui Yu wrote:
Hi Marc,
On 2020/2/14 22:57, Marc Zyngier wrote:
As for VLPIs, there is a number of configuration bits that cannot
As for vSGIs,
No, I think this is correct, if a bit ambiguous. What I'm trying to say
here is that vSGIs have the same requirements as vLPIs, in the sense
that some of the configuration aspects cannot be expressed in terms of
the irqchip API.
be directly communicated through the normal irqchip API, and we
have to use our good old friend set_vcpu_affinity.
This is used to configure group and priority for a given vSGI.
Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
---
drivers/irqchip/irq-gic-v3-its.c | 18 ++
include/linux/irqchip/arm-gic-v4.h | 5 +
2 files changed, 23 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c
b/drivers/irqchip/irq-gic-v3-its.c
index a9753435c4ff..a2e824eae43f 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3969,6 +3969,23 @@ static int its_sgi_get_irqchip_state(struct
irq_data *d,
return 0;
}
+static int its_sgi_set_vcpu_affinity(struct irq_data *d, void
*vcpu_info)
+{
+ struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
+ struct its_cmd_info *info = vcpu_info;
+
+ switch (info->cmd_type) {
+ case PROP_UPDATE_SGI:
+ vpe->sgi_config[d->hwirq].priority = info->priority;
+ vpe->sgi_config[d->hwirq].group = info->group;
+ its_configure_sgi(d, false);
+ return 0;
+
+ default:
+ return -EINVAL;
+ }
+}
+
static struct irq_chip its_sgi_irq_chip = {
.name = "GICv4.1-sgi",
.irq_mask = its_sgi_mask_irq,
@@ -3976,6 +3993,7 @@ static struct irq_chip its_sgi_irq_chip = {
.irq_set_affinity = its_sgi_set_affinity,
.irq_set_irqchip_state = its_sgi_set_irqchip_state,
.irq_get_irqchip_state = its_sgi_get_irqchip_state,
+ .irq_set_vcpu_affinity = its_sgi_set_vcpu_affinity,
};
static int its_sgi_irq_domain_alloc(struct irq_domain *domain,
diff --git a/include/linux/irqchip/arm-gic-v4.h
b/include/linux/irqchip/arm-gic-v4.h
index 30b4855bf766..a1a9d40266f5 100644
--- a/include/linux/irqchip/arm-gic-v4.h
+++ b/include/linux/irqchip/arm-gic-v4.h
@@ -98,6 +98,7 @@ enum its_vcpu_info_cmd_type {
SCHEDULE_VPE,
DESCHEDULE_VPE,
INVALL_VPE,
+ PROP_UPDATE_SGI,
Maybe better to use 'PROP_UPDATE_VSGI'?
That's indeed better.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 2/3] KVM: arm64: limit PMU version to PMUv3 for ARMv8.1
On Fri, Feb 28, 2020 at 04:51:22PM +, Mark Rutland wrote:
> On Mon, Jan 27, 2020 at 11:44:28AM +, Andrew Murray wrote:
> > We currently expose the PMU version of the host to the guest via
> > emulation of the DFR0_EL1 and AA64DFR0_EL1 debug feature registers.
> > However many of the features offered beyond PMUv3 for 8.1 are not
> > supported in KVM. Examples of this include support for the PMMIR
> > registers (added in PMUv3 for ARMv8.4) and 64-bit event counters
> > added in (PMUv3 for ARMv8.5).
> >
> > Let's trap the Debug Feature Registers in order to limit
> > PMUVer/PerfMon in the Debug Feature Registers to PMUv3 for ARMv8.1
> > to avoid unexpected behaviour.
> >
> > Signed-off-by: Andrew Murray
> > ---
> > arch/arm64/include/asm/sysreg.h | 5 +
> > arch/arm64/kvm/sys_regs.c | 11 +++
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/sysreg.h
> > b/arch/arm64/include/asm/sysreg.h
> > index 6e919fa..1009878 100644
> > --- a/arch/arm64/include/asm/sysreg.h
> > +++ b/arch/arm64/include/asm/sysreg.h
> > @@ -672,6 +672,11 @@
> > #define ID_AA64DFR0_TRACEVER_SHIFT 4
> > #define ID_AA64DFR0_DEBUGVER_SHIFT 0
> >
> > +#define ID_DFR0_PERFMON_SHIFT 24
> > +
> > +#define ID_DFR0_EL1_PMUVER_8_1 4
> > +#define ID_AA64DFR0_EL1_PMUVER_8_1 4
> > +
> > #define ID_ISAR5_RDM_SHIFT 24
> > #define ID_ISAR5_CRC32_SHIFT 16
> > #define ID_ISAR5_SHA2_SHIFT12
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index 9f21659..3f0f3cc 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -1085,6 +1085,17 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> > (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> > (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> > (0xfUL << ID_AA64ISAR1_GPI_SHIFT));
> > + } else if (id == SYS_ID_AA64DFR0_EL1) {
> > + /* Limit guests to PMUv3 for ARMv8.1 */
> > + val = cpuid_feature_cap_signed_field_width(val,
> > + ID_AA64DFR0_PMUVER_SHIFT,
> > + 4, ID_AA64DFR0_EL1_PMUVER_8_1);
> > + } else if (id == SYS_ID_DFR0_EL1) {
> > + /* Limit guests to PMUv3 for ARMv8.1 */
> > + val = cpuid_feature_cap_signed_field_width(val,
> > + ID_DFR0_PERFMON_SHIFT,
> > + 4, ID_DFR0_EL1_PMUVER_8_1);
> > +
>
> Unfortunately, ID_AA64DFR0_EL1.PMUVer and ID_DFR0_EL1.PerfMon don't
> follow the usual ID scheme, and cannot be treated as signed fields.
>
> Per ARM DDI 0487E.a, page D13-2825, they follow an alternative scheme
> that is treated as unsigned, with 0xF additionally being treated as an
> architected PMU version not being implemented. For KVM we'll want to
> convert 0xF to 0x0.
>
> I'll respin these patches accordingly.
I've pushed an updated series to:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/pmu-8.5
Hopefully I'll get the chance to give that a go on ARMv8.{0,1} hardware
on Monday. I'm not sure how useful the PMU in FVPs is these days, so I'm
not sure how far I can test the ARMv8.5+ bits.
Thanks,
Mark.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 13/18] arm64: kvm: Annotate assembly using modern annoations
On 2020-02-18 19:58, Mark Brown wrote: In an effort to clarify and simplify the annotation of assembly functions in the kernel new macros have been introduced. These replace ENTRY and ENDPROC with separate annotations for standard C callable functions, data and code with different calling conventions. Update the more straightforward annotations in the kvm code to the new macros. Signed-off-by: Mark Brown --- arch/arm64/kvm/hyp-init.S | 8 arch/arm64/kvm/hyp.S | 4 ++-- arch/arm64/kvm/hyp/fpsimd.S| 8 arch/arm64/kvm/hyp/hyp-entry.S | 15 --- 4 files changed, 18 insertions(+), 17 deletions(-) For the three KVM/arm patches: Acked-by: Marc Zyngier I'd expect this to go as a whole via the arm64 tree, but I can also cherry-pick them if necessary. Thanks, M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v5 2/3] KVM: arm64: limit PMU version to PMUv3 for ARMv8.1
On Mon, Jan 27, 2020 at 11:44:28AM +, Andrew Murray wrote:
> We currently expose the PMU version of the host to the guest via
> emulation of the DFR0_EL1 and AA64DFR0_EL1 debug feature registers.
> However many of the features offered beyond PMUv3 for 8.1 are not
> supported in KVM. Examples of this include support for the PMMIR
> registers (added in PMUv3 for ARMv8.4) and 64-bit event counters
> added in (PMUv3 for ARMv8.5).
>
> Let's trap the Debug Feature Registers in order to limit
> PMUVer/PerfMon in the Debug Feature Registers to PMUv3 for ARMv8.1
> to avoid unexpected behaviour.
>
> Signed-off-by: Andrew Murray
> ---
> arch/arm64/include/asm/sysreg.h | 5 +
> arch/arm64/kvm/sys_regs.c | 11 +++
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 6e919fa..1009878 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -672,6 +672,11 @@
> #define ID_AA64DFR0_TRACEVER_SHIFT 4
> #define ID_AA64DFR0_DEBUGVER_SHIFT 0
>
> +#define ID_DFR0_PERFMON_SHIFT24
> +
> +#define ID_DFR0_EL1_PMUVER_8_1 4
> +#define ID_AA64DFR0_EL1_PMUVER_8_1 4
> +
> #define ID_ISAR5_RDM_SHIFT 24
> #define ID_ISAR5_CRC32_SHIFT 16
> #define ID_ISAR5_SHA2_SHIFT 12
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 9f21659..3f0f3cc 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1085,6 +1085,17 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
>(0xfUL << ID_AA64ISAR1_API_SHIFT) |
>(0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
>(0xfUL << ID_AA64ISAR1_GPI_SHIFT));
> + } else if (id == SYS_ID_AA64DFR0_EL1) {
> + /* Limit guests to PMUv3 for ARMv8.1 */
> + val = cpuid_feature_cap_signed_field_width(val,
> + ID_AA64DFR0_PMUVER_SHIFT,
> + 4, ID_AA64DFR0_EL1_PMUVER_8_1);
> + } else if (id == SYS_ID_DFR0_EL1) {
> + /* Limit guests to PMUv3 for ARMv8.1 */
> + val = cpuid_feature_cap_signed_field_width(val,
> + ID_DFR0_PERFMON_SHIFT,
> + 4, ID_DFR0_EL1_PMUVER_8_1);
> +
Unfortunately, ID_AA64DFR0_EL1.PMUVer and ID_DFR0_EL1.PerfMon don't
follow the usual ID scheme, and cannot be treated as signed fields.
Per ARM DDI 0487E.a, page D13-2825, they follow an alternative scheme
that is treated as unsigned, with 0xF additionally being treated as an
architected PMU version not being implemented. For KVM we'll want to
convert 0xF to 0x0.
I'll respin these patches accordingly.
Thanks,
Mark.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 12/18] arm64: kernel: Convert to modern annotations for assembly functions
On Fri, Feb 28, 2020 at 01:37:18PM +, Catalin Marinas wrote: > On Fri, Feb 28, 2020 at 01:41:21PM +0100, Ard Biesheuvel wrote: > > This hunk is going to conflict badly with the EFI tree. I will > > incorporate this change for v5.7, so could you please just drop it > > from this patch? Will do for any reposts. > I wonder whether it would be easier to merge all these patches at > 5.7-rc1, once most of the major changes went in. Only thing I can think that doing that might cause issue with is if people are doing work that's not likely to make it in this cycle then it'd be some extra rebasing or carrying of out of tree patches they'd need to do (plus obviously this series might pick up new conflicts itself). It's not a completely automated process unfortunately, especially with trying to fix up some of the problems with the existing annotations changing the output. But yeah, we could do that. signature.asc Description: PGP signature ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 12/18] arm64: kernel: Convert to modern annotations for assembly functions
On Fri, Feb 28, 2020 at 01:41:21PM +0100, Ard Biesheuvel wrote: > On Tue, 18 Feb 2020 at 21:02, Mark Brown wrote: > > In an effort to clarify and simplify the annotation of assembly functions > > in the kernel new macros have been introduced. These replace ENTRY and > > ENDPROC and also add a new annotation for static functions which previously > > had no ENTRY equivalent. Update the annotations in the core kernel code to > > the new macros. > > > > Signed-off-by: Mark Brown > > --- > > arch/arm64/kernel/cpu-reset.S | 4 +- > > arch/arm64/kernel/efi-entry.S | 4 +- > > arch/arm64/kernel/efi-rt-wrapper.S| 4 +- > > arch/arm64/kernel/entry-fpsimd.S | 20 - > > arch/arm64/kernel/hibernate-asm.S | 16 +++ > > arch/arm64/kernel/hyp-stub.S | 20 - > > arch/arm64/kernel/probes/kprobes_trampoline.S | 4 +- > > arch/arm64/kernel/reloc_test_syms.S | 44 +-- > > arch/arm64/kernel/relocate_kernel.S | 4 +- > > arch/arm64/kernel/sleep.S | 12 ++--- > > arch/arm64/kernel/smccc-call.S| 8 ++-- > > 11 files changed, 70 insertions(+), 70 deletions(-) > > > ... > > diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S > > index 304d5b02ca67..de6ced92950e 100644 > > --- a/arch/arm64/kernel/efi-entry.S > > +++ b/arch/arm64/kernel/efi-entry.S > > @@ -25,7 +25,7 @@ > > * we want to be. The kernel image wants to be placed at TEXT_OFFSET > > * from start of RAM. > > */ > > -ENTRY(entry) > > +SYM_CODE_START(entry) > > /* > > * Create a stack frame to save FP/LR with extra space > > * for image_addr variable passed to efi_entry(). > > @@ -117,4 +117,4 @@ efi_load_fail: > > ret > > > > entry_end: > > -ENDPROC(entry) > > +SYM_CODE_END(entry) > > This hunk is going to conflict badly with the EFI tree. I will > incorporate this change for v5.7, so could you please just drop it > from this patch? I wonder whether it would be easier to merge all these patches at 5.7-rc1, once most of the major changes went in. -- Catalin ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 12/18] arm64: kernel: Convert to modern annotations for assembly functions
Hi Mark, On Tue, 18 Feb 2020 at 21:02, Mark Brown wrote: > > In an effort to clarify and simplify the annotation of assembly functions > in the kernel new macros have been introduced. These replace ENTRY and > ENDPROC and also add a new annotation for static functions which previously > had no ENTRY equivalent. Update the annotations in the core kernel code to > the new macros. > > Signed-off-by: Mark Brown > --- > arch/arm64/kernel/cpu-reset.S | 4 +- > arch/arm64/kernel/efi-entry.S | 4 +- > arch/arm64/kernel/efi-rt-wrapper.S| 4 +- > arch/arm64/kernel/entry-fpsimd.S | 20 - > arch/arm64/kernel/hibernate-asm.S | 16 +++ > arch/arm64/kernel/hyp-stub.S | 20 - > arch/arm64/kernel/probes/kprobes_trampoline.S | 4 +- > arch/arm64/kernel/reloc_test_syms.S | 44 +-- > arch/arm64/kernel/relocate_kernel.S | 4 +- > arch/arm64/kernel/sleep.S | 12 ++--- > arch/arm64/kernel/smccc-call.S| 8 ++-- > 11 files changed, 70 insertions(+), 70 deletions(-) > ... > diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S > index 304d5b02ca67..de6ced92950e 100644 > --- a/arch/arm64/kernel/efi-entry.S > +++ b/arch/arm64/kernel/efi-entry.S > @@ -25,7 +25,7 @@ > * we want to be. The kernel image wants to be placed at TEXT_OFFSET > * from start of RAM. > */ > -ENTRY(entry) > +SYM_CODE_START(entry) > /* > * Create a stack frame to save FP/LR with extra space > * for image_addr variable passed to efi_entry(). > @@ -117,4 +117,4 @@ efi_load_fail: > ret > > entry_end: > -ENDPROC(entry) > +SYM_CODE_END(entry) This hunk is going to conflict badly with the EFI tree. I will incorporate this change for v5.7, so could you please just drop it from this patch? ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [GIT PULL] KVM/arm fixes for 5.6
On 26/02/20 00:52, Marc Zyngier wrote: > Paolo, > > This is a small update containing a number of fixes, the most important ones > making sure we force the inlining of any helper that gets used by the EL2 code > (James identified that some bad things happen with CLang and the Shadow Call > Stack extention). > > Please pull, > > M. > > The following changes since commit 4a267aa707953a9a73d1f5dc7f894dd9024a92be: > > KVM: arm64: Treat emulated TVAL TimerValue as a signed 32-bit integer > (2020-01-28 13:09:31 +) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git > tags/kvmarm-fixes-5.6-1 > > for you to fetch changes up to e43f1331e2ef913b8c566920c9af75e0ccdd1d3f: > > arm64: Ask the compiler to __always_inline functions used by KVM at HYP > (2020-02-22 11:01:47 +) > > > KVM/arm fixes for 5.6, take #1 > > - Fix compilation on 32bit > - Move VHE guest entry/exit into the VHE-specific entry code > - Make sure all functions called by the non-VHE HYP code is tagged as > __always_inline > > > James Morse (3): > KVM: arm64: Ask the compiler to __always_inline functions used at HYP > KVM: arm64: Define our own swab32() to avoid a uapi static inline > arm64: Ask the compiler to __always_inline functions used by KVM at HYP > > Jeremy Cline (1): > KVM: arm/arm64: Fix up includes for trace.h > > Mark Rutland (1): > kvm: arm/arm64: Fold VHE entry/exit work into kvm_vcpu_run_vhe() > > arch/arm/include/asm/kvm_host.h | 3 -- > arch/arm64/include/asm/arch_gicv3.h | 2 +- > arch/arm64/include/asm/cache.h | 2 +- > arch/arm64/include/asm/cacheflush.h | 2 +- > arch/arm64/include/asm/cpufeature.h | 10 +++ > arch/arm64/include/asm/io.h | 4 +-- > arch/arm64/include/asm/kvm_emulate.h | 48 > > arch/arm64/include/asm/kvm_host.h| 32 - > arch/arm64/include/asm/kvm_hyp.h | 7 + > arch/arm64/include/asm/kvm_mmu.h | 3 +- > arch/arm64/include/asm/virt.h| 2 +- > arch/arm64/kvm/hyp/switch.c | 39 -- > arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 +-- > virt/kvm/arm/arm.c | 2 -- > virt/kvm/arm/trace.h | 1 + > 15 files changed, 84 insertions(+), 77 deletions(-) > Pulled, thanks. Paolo ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
