From: wanghaibin <wanghaibin.wang@huawei.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: cdall@linaro.org, kvmarm@lists.cs.columbia.edu, wu.wubin@huawei.com
Subject: Re: [PATCH] kvm: arm/arm64: vgic: Fix the sequence principle about vgic save/restore.
Date: Tue, 6 Jun 2017 11:23:19 +0800 [thread overview]
Message-ID: <59362027.4020302@huawei.com> (raw)
In-Reply-To: <e8c54af6-c774-a37e-a14f-04d422fe5234@arm.com>
On 2017/6/5 21:56, Marc Zyngier wrote:
> On 05/06/17 11:30, wanghaibin wrote:
>> At present, take GICv3 as as an example, our implementation is that, the operation
>> of the recovery ICH_HCR register is prior to the recovery of ICH_LRn registers in vgic
>> state restore. Thus, the ICH_LRn registers are 0, and if ICH_HCR.UIE is configured to 1,
>> a large number of unnecessary maintenance interrupts will be triggered.
>
> Is that a theoretical problem? Or something you've actually observed?
I observed this problem with that boot a android vm (with 4 vcpus) on my hisilicon D03 board (4 LRs support).
Boot the android vm will failed because of any virtual interrupts can't deliver to the vm timely.
I watched the maintenance interrupt (/proc/interrupts, GICv3 hwirq:25), and the number can up to 200000+ per second.
(sorry for my express fault, the large number of unnecessary maintenance interrupts means this).
>
> At the point where we restore the vgic state, interrupts are disabled.
> And by the time we enter the guest, we fully expect the HW to be in a
> stable state, and no spurious interrupt would be delivered.
At that point where restore the vgic state, it's true that interrupts are disabled (local_irq_disable),
but in my opinion, here maybe a maintenance interrupt pending at physical redist (at that point it can be delivered).
and it will be delivered at the moment that current vcpu's ctxt restore and entry (eret, here, PSTATE.I maybe unmask).
Thus, the vcpu will be kicked out immediately. At the next vgic state restore point, go round and begin again.
Thanks.
>
> I also dispute the "large number of unnecessary maintenance interrupts".
> This large number is at most *one*.
>
> Or am I missing something obvious?
>
> Thanks,
>
> M.
next prev parent reply other threads:[~2017-06-06 3:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-05 10:30 [PATCH] kvm: arm/arm64: vgic: Fix the sequence principle about vgic save/restore wanghaibin
2017-06-05 13:56 ` Marc Zyngier
2017-06-06 3:23 ` wanghaibin [this message]
2017-06-06 8:34 ` Marc Zyngier
2017-06-06 9:29 ` wanghaibin
2017-06-06 9:43 ` Marc Zyngier
2017-06-06 9:55 ` wanghaibin
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=59362027.4020302@huawei.com \
--to=wanghaibin.wang@huawei.com \
--cc=cdall@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=marc.zyngier@arm.com \
--cc=wu.wubin@huawei.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