hw/arm/xlnx-zynqmp.c | 92 +++- hw/intc/arm_gic.c | 790 ++++++++++++++++++++++++------- hw/intc/arm_gic_common.c | 158 +++++-- hw/intc/arm_gic_kvm.c | 31 +- hw/intc/gic_internal.h | 258 ++++++++-- hw/intc/trace-events | 12 +- include/hw/arm/xlnx-zynqmp.h | 4 +- include/hw/intc/arm_gic_common.h | 51 +- include/migration/vmstate.h | 3 + 9 files changed, 1153 insertions(+), 246 deletions(-)
From: Luc MICHEL <luc.michel@greensocs.com>
This patch series add support for the virtualization extensions in the
ARM GICv2 interrupt controller.
The first two commits do some refactoring to prepare for the
implementation. Commits 3 and 4 are the actual implementation. The last
commit updates the ZynqMP implementation to support virtualization.
The current state allows to boot Xen (tested with 4.8 and 4.10) with
Linux Dom0 guest properly.
I also tested in SMP. It does not work directly because Xen expects to
find CPU IDs in the GIC ITARGETSR0 register. This behavior is not
documented in the GICv2 specification, and is not implemented in QEMU.
By hacking this register, I was able to get the whole thing to boot in
SMP properly. This hack is not part of those patches though.
I also tested migration, it works fine AFAIK. I had to add the HYP and
SEC timers in the ARM CPU VMState though (Xen uses the HYP one) (not
part of those patches).
I want to thanks the Xilinx's QEMU team who sponsored this work for
their collaboration.
v2:
- Add VMSTATE_UINT16_SUB_ARRAY to vmstate.h
- Keep backward compatibility on the GIC VMState by storing vCPUs
state in the virt VMState subsection.
- Use h_apr to store APR value for vCPUs, instead of increasing apr 2D
array. This adds a little complexity to the implementation (a bunch
of `if (gic_is_vcpu(cpu))'), but avoid ugly VMState description for
the apr array.
Luc MICHEL (7):
intc/arm_gic: Refactor operations on the distributor
intc/arm_gic: Remove some dead code and put some functions static
vmstate.h: Provide VMSTATE_UINT16_SUB_ARRAY
intc/arm_gic: Add the virtualization extensions to the GIC state
intc/arm_gic: Add virtualization extensions logic
intc/arm_gic: Improve traces
xlnx-zynqmp: Improve GIC wiring and MMIO mapping
hw/arm/xlnx-zynqmp.c | 92 +++-
hw/intc/arm_gic.c | 790 ++++++++++++++++++++++++-------
hw/intc/arm_gic_common.c | 158 +++++--
hw/intc/arm_gic_kvm.c | 31 +-
hw/intc/gic_internal.h | 258 ++++++++--
hw/intc/trace-events | 12 +-
include/hw/arm/xlnx-zynqmp.h | 4 +-
include/hw/intc/arm_gic_common.h | 51 +-
include/migration/vmstate.h | 3 +
9 files changed, 1153 insertions(+), 246 deletions(-)
--
2.17.1
On 2018-06-19 11:31, luc.michel@greensocs.com wrote: > From: Luc MICHEL <luc.michel@greensocs.com> > > This patch series add support for the virtualization extensions in the > ARM GICv2 interrupt controller. > > The first two commits do some refactoring to prepare for the > implementation. Commits 3 and 4 are the actual implementation. The last > commit updates the ZynqMP implementation to support virtualization. Is it enabled for the virt machine as well? Seems we are missing some mapping of GICV and GICH there. And what is the recommended way to get the ZynqMP model running? I've a kernel that works on a ZCU102, but just passing it via -kernel to the QEMU model seems insufficient. Jan
On 25 June 2018 at 05:55, Jan Kiszka <jan.kiszka@web.de> wrote: > On 2018-06-19 11:31, luc.michel@greensocs.com wrote: >> From: Luc MICHEL <luc.michel@greensocs.com> >> >> This patch series add support for the virtualization extensions in the >> ARM GICv2 interrupt controller. >> >> The first two commits do some refactoring to prepare for the >> implementation. Commits 3 and 4 are the actual implementation. The last >> commit updates the ZynqMP implementation to support virtualization. > > Is it enabled for the virt machine as well? Seems we are missing some > mapping of GICV and GICH there. I agree that it would be very nice to see this enabled for the 'virt' board; it's a bit tricky for me to test otherwise. It should just be a matter of mapping in the GICV and GICH, wiring up the maintenance interrupt, and advertising it correctly in the DTB and ACPI data... I'm hoping to get to reviewing this series this afternoon. thanks -- PMM
On 06/25/2018 01:12 PM, Peter Maydell wrote: > On 25 June 2018 at 05:55, Jan Kiszka <jan.kiszka@web.de> wrote: >> On 2018-06-19 11:31, luc.michel@greensocs.com wrote: >>> From: Luc MICHEL <luc.michel@greensocs.com> >>> >>> This patch series add support for the virtualization extensions in the >>> ARM GICv2 interrupt controller. >>> >>> The first two commits do some refactoring to prepare for the >>> implementation. Commits 3 and 4 are the actual implementation. The last >>> commit updates the ZynqMP implementation to support virtualization. >> >> Is it enabled for the virt machine as well? Seems we are missing some >> mapping of GICV and GICH there. > > I agree that it would be very nice to see this enabled for the > 'virt' board; it's a bit tricky for me to test otherwise. It > should just be a matter of mapping in the GICV and GICH, > wiring up the maintenance interrupt, and advertising it > correctly in the DTB and ACPI data... OK, I'll give it a look for the v3 then. > > I'm hoping to get to reviewing this series this afternoon. > > thanks > -- PMM >
On 06/25/2018 06:55 AM, Jan Kiszka wrote:
> On 2018-06-19 11:31, luc.michel@greensocs.com wrote:
>> From: Luc MICHEL <luc.michel@greensocs.com>
>>
>> This patch series add support for the virtualization extensions in the
>> ARM GICv2 interrupt controller.
>>
>> The first two commits do some refactoring to prepare for the
>> implementation. Commits 3 and 4 are the actual implementation. The last
>> commit updates the ZynqMP implementation to support virtualization.
>
> Is it enabled for the virt machine as well? Seems we are missing some
> mapping of GICV and GICH there.
>
> And what is the recommended way to get the ZynqMP model running? I've a
> kernel that works on a ZCU102, but just passing it via -kernel to the
> QEMU model seems insufficient.
Hum, I think it should be enough. This is the way I run my tests with Xen:
qemu-system-aarch64 -M xlnx-zcu102,secure=on,virtualization=on \
-m 1024 \
-kernel xen-kernel -nographic -smp 1
--
Luc
>
> Jan
>
On 2018-06-26 11:24, Luc Michel wrote:
>
>
> On 06/25/2018 06:55 AM, Jan Kiszka wrote:
>> On 2018-06-19 11:31, luc.michel@greensocs.com wrote:
>>> From: Luc MICHEL <luc.michel@greensocs.com>
>>>
>>> This patch series add support for the virtualization extensions in the
>>> ARM GICv2 interrupt controller.
>>>
>>> The first two commits do some refactoring to prepare for the
>>> implementation. Commits 3 and 4 are the actual implementation. The last
>>> commit updates the ZynqMP implementation to support virtualization.
>>
>> Is it enabled for the virt machine as well? Seems we are missing some
>> mapping of GICV and GICH there.
>>
>> And what is the recommended way to get the ZynqMP model running? I've a
>> kernel that works on a ZCU102, but just passing it via -kernel to the
>> QEMU model seems insufficient.
> Hum, I think it should be enough. This is the way I run my tests with Xen:
> qemu-system-aarch64 -M xlnx-zcu102,secure=on,virtualization=on \
> -m 1024 \
> -kernel xen-kernel -nographic -smp 1
>
Just debugged this further a bit, and it seems my kernel is not getting
any device tree from qemu:
(gdb) bt
#0 cpu_relax () at ../arch/arm64/include/asm/processor.h:203
#1 setup_machine_fdt (dt_phys=256) at ../arch/arm64/kernel/setup.c:194
#2 setup_arch (cmdline_p=<optimized out>) at ../arch/arm64/kernel/setup.c:258
#3 0xffffff8008e30bc4 in start_kernel () at ../init/main.c:552
#4 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) lx-dmesg
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0.000000] Linux version 4.17.0-00033-g67c2a9a37d59 (jan@md1f2u6c) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #17 SMP Tue Jun 26 12:16:56 CEST 2018
(gdb) l setup_machine_fdt
178 pr_warn("Large number of MPIDR hash buckets detected\n");
179 }
180
181 static void __init setup_machine_fdt(phys_addr_t dt_phys)
182 {
183 void *dt_virt = fixmap_remap_fdt(dt_phys);
184 const char *name;
185
186 if (!dt_virt || !early_init_dt_scan(dt_virt)) {
187 pr_crit("\n"
188 "Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
189 "The dtb must be 8-byte aligned and must not exceed 2 MB in size\n"
190 "\nPlease check your bootloader.",
191 &dt_phys, dt_virt);
192
193 while (true)
194 cpu_relax();
[...]
(gdb) p dt_virt
$1 = (void *) 0x0
Jan
On 2018-06-26 12:22, Jan Kiszka wrote:
> On 2018-06-26 11:24, Luc Michel wrote:
>>
>>
>> On 06/25/2018 06:55 AM, Jan Kiszka wrote:
>>> On 2018-06-19 11:31, luc.michel@greensocs.com wrote:
>>>> From: Luc MICHEL <luc.michel@greensocs.com>
>>>>
>>>> This patch series add support for the virtualization extensions in the
>>>> ARM GICv2 interrupt controller.
>>>>
>>>> The first two commits do some refactoring to prepare for the
>>>> implementation. Commits 3 and 4 are the actual implementation. The last
>>>> commit updates the ZynqMP implementation to support virtualization.
>>>
>>> Is it enabled for the virt machine as well? Seems we are missing some
>>> mapping of GICV and GICH there.
>>>
>>> And what is the recommended way to get the ZynqMP model running? I've a
>>> kernel that works on a ZCU102, but just passing it via -kernel to the
>>> QEMU model seems insufficient.
>> Hum, I think it should be enough. This is the way I run my tests with Xen:
>> qemu-system-aarch64 -M xlnx-zcu102,secure=on,virtualization=on \
>> -m 1024 \
>> -kernel xen-kernel -nographic -smp 1
>>
>
> Just debugged this further a bit, and it seems my kernel is not getting
> any device tree from qemu:
>
> (gdb) bt
> #0 cpu_relax () at ../arch/arm64/include/asm/processor.h:203
> #1 setup_machine_fdt (dt_phys=256) at ../arch/arm64/kernel/setup.c:194
> #2 setup_arch (cmdline_p=<optimized out>) at ../arch/arm64/kernel/setup.c:258
> #3 0xffffff8008e30bc4 in start_kernel () at ../init/main.c:552
> #4 0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) lx-dmesg
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
> [ 0.000000] Linux version 4.17.0-00033-g67c2a9a37d59 (jan@md1f2u6c) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #17 SMP Tue Jun 26 12:16:56 CEST 2018
> (gdb) l setup_machine_fdt
> 178 pr_warn("Large number of MPIDR hash buckets detected\n");
> 179 }
> 180
> 181 static void __init setup_machine_fdt(phys_addr_t dt_phys)
> 182 {
> 183 void *dt_virt = fixmap_remap_fdt(dt_phys);
> 184 const char *name;
> 185
> 186 if (!dt_virt || !early_init_dt_scan(dt_virt)) {
> 187 pr_crit("\n"
> 188 "Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
> 189 "The dtb must be 8-byte aligned and must not exceed 2 MB in size\n"
> 190 "\nPlease check your bootloader.",
> 191 &dt_phys, dt_virt);
> 192
> 193 while (true)
> 194 cpu_relax();
> [...]
> (gdb) p dt_virt
> $1 = (void *) 0x0
>
> Jan
>
OK, feeding in -dtb arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dtb
and setting the console to ttyPS0 gives now some output. Looks like this
can take me closer towards a testable setup.
Jan
© 2016 - 2024 Red Hat, Inc.