From: Pavel Fedin <p.fedin@samsung.com>
To: 'Christoffer Dall' <christoffer.dall@linaro.org>
Cc: 'Marc Zyngier' <marc.zyngier@arm.com>,
'Andre Przywara' <andre.przywara@arm.com>,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: RE: [PATCH v4 0/3] KVM: arm/arm64: Clean up some obsolete code
Date: Tue, 03 Nov 2015 10:24:18 +0300 [thread overview]
Message-ID: <005201d11608$a73edf80$f5bc9e80$@samsung.com> (raw)
In-Reply-To: <20151102211538.GA5819@cbox>
Hello!
> I ran this through my test scripts and I'm now quite sure that there's
> some breakage in here.
>
> One of my tests is running two VMs in parallel, each booting up, running
> hackbench, and then doing reboot (from within the guest), and just
> repeating like that.
>
> I've run your patches in the above config 100 times, and every time,
> the rebooting VMs got stuck before 50 reboots.
>
> Without these patches, I could run the above config 100 times, and every
> time, the rebooting VMs passed 200 reboots.
Huh, the description looks like some problem with vgic_retire_disabled_irqs(). By the way, during reboot, who does call it? The
only call i see is in vgic_handle_enable_reg(), which obviously just processes emulated register accesses...
And the only thing i know is that in case of GICv2 the userland resets vGIC manually by resetting each register to its default
value (therefore all ENABLER are set to 0). At least qemu does this, and i'm not sure about kvmtool. And in case of vGICv3 nobody
can do this because there's no API to set registers yet. So, could we be rebooting with interrupts enabled or something like that?
So: what kind of container are you running and what vGIC version? Does this problem reproduce with both vGICv2 and vGICv3?
By this time i'll make a very minimal version of patch 0001, for you to test it. If we have problems with current 0001, which we
cannot solve quickly, we could stick to that version then, which will provide the necessary changes to plug in LPIs, yet with
minimal changes (it will only remove vgic_irq_lr_map).
I guess i should have done it before. Or, i could even respin v5, with current 0001 split up. This should make it easier to bisect
the problem.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
next prev parent reply other threads:[~2015-11-03 7:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-27 8:37 [PATCH v4 0/3] KVM: arm/arm64: Clean up some obsolete code Pavel Fedin
2015-10-27 8:37 ` [PATCH v4 1/3] KVM: arm/arm64: Optimize away redundant LR tracking Pavel Fedin
2015-10-27 8:37 ` [PATCH v4 2/3] KVM: arm/arm64: Clean up vgic_retire_lr() and surroundings Pavel Fedin
2015-10-27 8:37 ` [PATCH v4 3/3] KVM: arm/arm64: Merge vgic_set_lr() and vgic_sync_lr_elrsr() Pavel Fedin
2015-11-02 21:15 ` [PATCH v4 0/3] KVM: arm/arm64: Clean up some obsolete code Christoffer Dall
2015-11-03 7:24 ` Pavel Fedin [this message]
2015-11-03 9:44 ` Pavel Fedin
2015-11-04 14:29 ` Christoffer Dall
2015-11-05 6:50 ` Pavel Fedin
2015-11-05 8:05 ` Peter Maydell
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='005201d11608$a73edf80$f5bc9e80$@samsung.com' \
--to=p.fedin@samsung.com \
--cc=andre.przywara@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).