All of lore.kernel.org
 help / color / mirror / Atom feed
From: <peng.hao2@zte.com.cn>
To: christoffer.dall@arm.com
Cc: marc.zyngier@arm.com, andre.przywara@arm.com,
	linux-kernel@vger.kernel.org, leif.lindholm@linaro.org,
	ard.bieshseuvel@linaro.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH] kvm: arm/arm64 : fix vm's hanging at startup time
Date: Sat, 24 Nov 2018 12:15:07 +0800 (CST)	[thread overview]
Message-ID: <201811241215075419114@zte.com.cn> (raw)
In-Reply-To: <20181123100302.GB3331@e113682-lin.lund.arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 8572 bytes --]

>> >Hi,
>> >
>> >On Wed, Nov 21, 2018 at 04:56:54PM +0800, peng.hao2@zte.com.cn wrote:
>> >> >On 19/11/2018 09:10, Mark Rutland wrote:
>> >> >> On Sat, Nov 17, 2018 at 10:58:37AM +0800, peng.hao2@zte.com.cn wrote:
>> >> >>>> On 16/11/18 00:23, peng.hao2@zte.com.cn wrote:
>> >> >>>>>> Hi,
>> >> >>>>>>> When virtual machine starts, hang up.
>> >> >>>>>>
>> >> >>>>>> I take it you mean the *guest* hangs? Because it doesn't get a timer
>> >> >>>>>> interrupt?
>> >> >>>>>>
>> >> >>>>>>> The kernel version of guest
>> >> >>>>>>> is 4.16. Host support vgic_v3.
>> >> >>>>>>
>> >> >>>>>> Your host kernel is something recent, I guess?
>> >> >>>>>>
>> >> >>>>>>> It was mainly due to the incorrect vgic_irq's(intid=27) group value
>> >> >>>>>>> during injection interruption. when kvm_vgic_vcpu_init is called,
>> >> >>>>>>> dist is not initialized at this time. Unable to get vgic V3 or V2
>> >> >>>>>>> correctly, so group is not set.
>> >> >>>>>>
>> >> >>>>>> Mmh, that shouldn't happen with (v)GICv3. Do you use QEMU (which
>> >> >>>>>> version?) or some other userland tool?
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>> QEMU emulator version 3.0.50 .
>> >> >>>>>
>> >> >>>>>>> group is setted to 1 when vgic_mmio_write_group is invoked at some
>> >> >>>>>>> time.
>> >> >>>>>>> when irq->group=0 (intid=27), No ICH_LR_GROUP flag was set and
>> >> >>>>>>> interrupt injection failed.
>> >> >>>>>>>
>> >> >>>>>>> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
>> >> >>>>>>> ---
>> >> >>>>>>>   virt/kvm/arm/vgic/vgic-v3.c | 2 +-
>> >> >>>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>>>>>>
>> >> >>>>>>> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
>> >> >>>>>>> index 9c0dd23..d101000 100644
>> >> >>>>>>> --- a/virt/kvm/arm/vgic/vgic-v3.c
>> >> >>>>>>> +++ b/virt/kvm/arm/vgic/vgic-v3.c
>> >> >>>>>>> @@ -198,7 +198,7 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu,
>> >> >>>>>>> struct vgic_irq *irq, int lr) if (vgic_irq_is_mapped_level(irq) &&
>> >> >>>>>>> (val & ICH_LR_PENDING_BIT)) irq->line_level = false;
>> >> >>>>>>>
>> >> >>>>>>> -    if (irq->group)
>> >> >>>>>>> +    if (model == KVM_DEV_TYPE_ARM_VGIC_V3)

[...]

>> >Could you try the following patch:
>> >
>> >diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
>> >index c0c0b88af1d5..6fa858c7a5a6 100644
>> >--- a/virt/kvm/arm/vgic/vgic-init.c
>> >+++ b/virt/kvm/arm/vgic/vgic-init.c
>> >@@ -231,13 +231,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
>> >irq->config = VGIC_CONFIG_LEVEL;
>> >}
>> >-        /*
>> >-         * GICv3 can only be created via the KVM_DEVICE_CREATE API and
>> >-         * so we always know the emulation type at this point as it's
>> >-         * either explicitly configured as GICv3, or explicitly
>> >-         * configured as GICv2, or not configured yet which also
>> >-         * implies GICv2.
>> >-         */
>> >if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
>> >irq->group = 1;
>> >else
>> >@@ -298,6 +291,16 @@ int vgic_init(struct kvm *kvm)
>> >if (ret)
>> >goto out;
>> >+    /* Initialize groups on CPUs created before the VGIC type was known */
>> >+    kvm_for_each_vcpu(i, vcpu, kvm) {
>> >+        struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
>> >+
>> >+        for (i = 0; i < VGIC_NR_PRIVATE_IRQS; i++) {
>> >+            struct vgic_irq *irq = &vgic_cpu->private_irqs[i];
>> >+            irq->group = 1;
>> >+        }
>> >+    }
>> >+
>> >if (vgic_has_its(kvm)) {
>> >ret = vgic_v4_init(kvm);
>> >if (ret)
>> >
>> Sorry for the late reply.
>> I test the patch and it works. But I think there is randomness here.
>> 1.vgic_init:  set intid/27 group=1
>> 2.vgic_mmio_write_group:## intid/27 group=0
>> 3.!!! receive a  vtimer irq   ----- it may exist.
>> 4.vgic_mmio_write_group:## intid/27 group=1
>>
>Are these writes from userspace or from the guest?
>(I assume they're from the guest.)
>
>>
>> I made an attempt before:
>>
>>Was this previous experiment using my patch or without my patch?
>>
>> 1. kvm_vgic_vcpu_init
>>      according to if  kvm_vgic_global_state.type == VGIC_V3, set group=1
>> 2.vgic_mmio_write_group:## intid/27 group=0
> >3.!!! receive a  vtimer irq   -----I really receive a vtimer irq, then the guest hangs.
>>
>
>If the guest you're using is flipping the group of the interrupt and yet
>enabling the device and interrupt while flipping the group, then it's
>not expected to work and it's a guest bug.
>
>My hunch here tells me that my patch is what we need for KVM, and either
>
>(1) You no longer have a problem but are tracing some guest
>initialization behavior which is fine, or
>
>(2) You still have a problem because you also have some broken guest
>code (guest UEFI or guest Linux) that also needs fixing.
>
>If you can demonstrate that you still have a problem, with my path
>applied to KVM, and with a recent guest Linux and guest UEFI, then I'll
>be happy to have another look.  In that case, could you please provide
>the exact versions of your guest Linux and UEFI, as well as the QEMU
>version and command line.
>
>
I'm sorry I make a mistake.I updated UEFI but never had time to test it. Yesterday I merged your patch
 to test, but forgot that I had updated UEFI.
Here are the corrected test results :
-----------------------------------------------------------------------------------------
|_new uefi + your patch_____________|______guest start normally__|
|_old uefi + your patch______________|______guest hangs________|
|_bypass uefi _(with/without your patch)|______guest start normally__|
|_new uefi + without your patch ______|______guest start normally_  |
|_old uefi + without your patch_ ______| _____ guest hangs________|

So the problem seems to be in UEFI. new uefi can be sure there is no a irq between
the group=0 and group=1 from  vgic_mmio_write_group.

guest kernel :4.16.0 (commit c18bb396d3d261ebbb4efbc05129c5d354c541e4)
the version of guest old uefi  corresponds to qemu 3.0.50.
the version of new uefi is the latest edk2.
I use libvirt to start guest, and the qemu command line  is like this:
/home/qemu-patch/linshi/qemu/aarch64-softmmu/qemu-system-aarch64 -name guest=centos74-ph-1,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-centos74-ph-1/master-key.aes -machine virt-3.1,accel=kvm,usb=off,dump-guest-core=off,gic-version=3 -cpu host -drive file=/usr/share/AAVMF/AAVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/centos74-ph-1_VARS.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 4,maxcpus=8,sockets=8,cores=1,threads=1 -uuid ff5ecf4e-1234-425f-948d-8d91135e109c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-centos74-ph-1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1 -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x10,chassis=3,id=pci.3,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 -device usb-ehci,id=usb,bus=pci.2,addr=0x1 -device piix3-usb-uhci,id=usb1,bus=pci.2,addr=0x2 -device virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-serial0 -drive file=/home/centos74-ph/boot.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/centos74-ph/data.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -drive file=/home/CentOS-7-aarch64-Everything.iso,format=raw,if=none,id=drive-scsi0-0-0-2,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2,bootindex=2 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-device,netdev=hostnet0,id=net0,mac=aa:35:97:5b:33:ac -add-fd set=2,fd=30 -chardev pty,id=charserial0,logfile=/dev/fdset/2,logappend=on -serial chardev:charserial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/centos74.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -device usb-kbd,id=input1,bus=usb.0,port=2 -vnc 0.0.0.0:0 -k en-us -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.3,addr=0x0 -device pvpanic-mmio -msg timestamp=on

Thanks.
>Thanks,
>
>Christoffer

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2018-11-24  4:15 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15 15:14 [PATCH] kvm: arm/arm64 : fix vm's hanging at startup time Peng Hao
2018-11-15 15:14 ` Peng Hao
2018-11-15  9:42 ` Julien Thierry
2018-11-15  9:42   ` Julien Thierry
2018-11-15 10:22   ` peng.hao2
2018-11-15 11:10     ` Julien Thierry
2018-11-15 11:10       ` Julien Thierry
2018-11-15 14:39 ` Andre Przywara
2018-11-15 14:39   ` Andre Przywara
2018-11-16  0:23   ` peng.hao2
2018-11-16 10:03     ` Julien Thierry
2018-11-16 10:03       ` Julien Thierry
2018-11-17  2:58       ` peng.hao2
2018-11-19  9:10         ` Mark Rutland
2018-11-19  9:10           ` Mark Rutland
2018-11-19  9:26           ` Marc Zyngier
2018-11-19  9:26             ` Marc Zyngier
2018-11-19  9:26             ` Marc Zyngier
2018-11-19 12:49           ` Marc Zyngier
2018-11-19 12:49             ` Marc Zyngier
2018-11-19 13:08             ` peng.hao2
2018-11-21  8:56             ` peng.hao2
2018-11-21 11:06               ` Christoffer Dall
2018-11-21 11:06                 ` Christoffer Dall
2018-11-21 12:17                 ` Julien Thierry
2018-11-21 12:17                   ` Julien Thierry
2018-11-21 15:24                   ` Christoffer Dall
2018-11-21 15:24                     ` Christoffer Dall
2018-11-21 15:53                     ` Julien Thierry
2018-11-21 15:53                       ` Julien Thierry
2018-11-22 10:45                       ` Christoffer Dall
2018-11-22 10:45                         ` Christoffer Dall
2018-11-23  6:01                 ` peng.hao2
2018-11-23 10:03                   ` Christoffer Dall
2018-11-23 10:03                     ` Christoffer Dall
2018-11-24  4:15                     ` peng.hao2 [this message]
2018-11-15 15:06 ` Marc Zyngier
2018-11-15 15:06   ` Marc Zyngier
2018-11-15 15:06   ` Marc Zyngier
2018-11-16  0:55   ` peng.hao2

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201811241215075419114@zte.com.cn \
    --to=peng.hao2@zte.com.cn \
    --cc=andre.przywara@arm.com \
    --cc=ard.bieshseuvel@linaro.org \
    --cc=christoffer.dall@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.