qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v2 0/7] arm_gic: add virtualization extensions sup


From: Jan Kiszka
Subject: Re: [Qemu-arm] [PATCH v2 0/7] arm_gic: add virtualization extensions support
Date: Tue, 26 Jun 2018 12:29:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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, address@hidden wrote:
>>>> From: Luc MICHEL <address@hidden>
>>>>
>>>> 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 (address@hidden) (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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]