qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 00/34] target/arm: Implement ARMv8.1-VHE


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH v3 00/34] target/arm: Implement ARMv8.1-VHE
Date: Mon, 05 Aug 2019 15:23:27 +0100
User-agent: mu4e 1.3.4; emacs 27.0.50

Richard Henderson <address@hidden> writes:

> On 8/5/19 6:02 AM, Alex Bennée wrote:
>>
>> Richard Henderson <address@hidden> writes:
>>
>>> About half of this patch set is cleanup of the qemu tlb handling
>>> leading up to the actual implementation of VHE, and the biggest
>>> piece of that: The EL2&0 translation regime.
>>>
>>> Changes since v2:
>>>   * arm_mmu_idx was incomplete; test TGE+E2H not just E2H.
>>>   * arm_sctlr was incomplete; now uses arm_mmu_idx to avoid
>>>     duplication of tests.
>>>   * Update aa64_zva_access and ctr_el0_access for EL2.
>>>
>>> Changes since v1:
>>>   * Merge feedback from AJB.
>>>   * Split out 7 renaming patches from "Reorganize ARMMMUIdx".
>>>   * Alex's MIDR patch keeps the nested KVM from spitting warnings.
>>>
>>> I have tested
>>>
>>>   qemu-system-aarch64 -accel kvm -cpu host -M virt,gic-version-host \
>>>     -m 512 -bios /usr/share/edk2/aarch64/QEMU_EFI.fd -nographic
>>
>> So testing with a host doing:
>>
>>   ./aarch64-softmmu/qemu-system-aarch64 -machine type=virt,virtualization=on 
>> -cpu cortex-a57 -serial mon:stdio -nic 
>> user,model=virtio-net-pci,hostfwd=tcp::2222-:22 -device virtio-scsi-pci 
>> -drive 
>> file=/dev/zvol/hackpool-0/debian-buster-arm64,id=hd0,index=0,if=none,format=raw,discard=on
>>  -device scsi-hd,drive=hd0 -kernel 
>> ../linux.git/builds/arm64/arch/arm64/boot/Image -append "console=ttyAMA0 
>> root=/dev/sda2" -display none -m 4096 -smp 8
>>
>> And a guest doing:
>>
>>   ./aarch64-softmmu/qemu-system-aarch64 -machine type=virt -cpu host
>>   -serial mon:stdio -nic user,model=virtio-net-pci -device
>>   virtio-scsi-pci -kernel /boot/vmlinuz-4.19.0-5-arm64 -append 
>> "console=ttyAMA0 panic=-1" -display none -m 256 -smp 4 --no-reboot
>>   --enable-kvm
>>
>> I triggered:
>>
>>   
>> ERROR:/home/alex.bennee/lsrc/qemu.git/target/arm/helper.c:3436:update_lpae_el1_asid:
>>  code should not be reached
>> fish: “./aarch64-softmmu/qemu-system-a…” terminated by signal SIGABRT (Abort)
>
> Whoops.  Rebase error while changing the signature of this function.
> Thanks for re-testing the case where VHE isn't present.  :-P
>
>> With -cpu max on the host it hangs the whole thing. I'm going to
>> continue to experiment with explicit GIC versions.
>
> Hangs the host?  Are you sure that the guest isn't just slow?

Ahh nested terminology - the aarch64 VHE host hangs so I can't access
it's shells either. I'll try and get a better trace once I've gotten a
reliable non-VHE guest-guest boot ;-)

> That's why I changed my testing to boot a debug edk2, which
> outputs stuff much sooner than the kernel does.

Looking via gdbstub it looked like stuff had stopped happening but you
are right it could be just slow. None of the threads seem to be doing
anything.

> Although I have no idea why the guest should be extra slow.
> It does seem like it ought to be booting at the same speed as
> the host.  I see tlb flushes as quite high in the profile,
> and wonder if I'm doing too many of them.

Hmm yeah they do seem a bit high:

TLB full flushes    8
TLB partial flushes 39036316
TLB elided flushes  256488402

... 10 seconds ...

TLB full flushes    8
TLB partial flushes 40393340
TLB elided flushes  265444803

For non-VHE that seems expected because we should be changing the entire
mapping regime as we bounce between the EL1's - shouldn't be as high for
VHE right?


>
>
> r~


--
Alex Bennée



reply via email to

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