From: Christoffer Dall <cdall@linaro.org>
To: Raz <raziebe@gmail.com>
Cc: kvmarm@lists.cs.columbia.edu
Subject: Re: How to trap a real interrupt to EL2 ?
Date: Wed, 5 Jul 2017 08:23:34 +0200 [thread overview]
Message-ID: <20170705062334.GA18106@cbox> (raw)
In-Reply-To: <CAPB=Z-oZtJyOewtAMsK7iSWnhrhv5iX90HmV0FMj_E5DHy7d-g@mail.gmail.com>
On Tue, Jul 04, 2017 at 07:32:37PM +0000, Raz wrote:
> The entry woken in the vector is IRQ 64-bit EL1 ( same as el1_irq in
> kvn/hyp.S ).
> ESR_EL2.EC = 0x16 -" HVC executed in EL2". It does not change.
ESR_EL2 doesn't say anything meaningful if you're taking an asynchronous
exception, like the IRQ.
>
> Jintack
> CPSR.I is 1 , but I do not think I can just clear it, if that what you
> mean...
CPSR.I will mask virtual interrupts at EL1 when HCR_EL2.IMO is set, not
physical interrupts.
The only way to run code in EL1 when having the IMO bit set and
interrupts arriving would involve either actually handling those
interrupts at EL2, or taking more drastic measures like disabling
physical interrupts entirely by disabling the interrupt controller or
something like that.
>
> Chrtistoph
*Christoffer*
>
> You deactivate traps in kvm_vcpu_return( called from el1_irq).
> Does it mean we cannot exit-enter the hypervisor when hcr_el2.IMO is
> enabled ?
Not sure what you're asking, but the deactivate_traps function is a
result of the split-mode virtualization design of KVM, where we have two
modes of running things in EL1, either the host hypervisor, or the VM.
Therefore, when we run the VM, we enable traps on all sorts of things to
EL2, and when we go back to the host, we disable those traps again,
making EL1 for the host more privileged.
In terms of IRQs, what we do in practice is:
disable_interrupts(); /* sets CPSR.I. HCR_EL2.IMO is 0 here. */
jump_to_el2();
enable_traps(); /* set HCR_EL2.IMO = 1 */
jump_to_vm_in_el1();
handle_exception_from_vm();
disable_traps(); /* set HCR_EL2.IMO = 0 */
return_to_host_el1(); /* CPSR.I is still set */
enable_interrupts(); /* clears CPSR.I. Raises new exception, now
handled at EL1 by Linux default mechanism */
Overall, I recommend you study the ARM Architecture Reference Manual
(ARM ARM) more closely to understand how the hardware works, and you can
also read one of these to get a better understanding of how the KVM design
works:
http://www.cs.columbia.edu/~cdall/pubs/asplos019-dall.pdf
https://lwn.net/Articles/557132/
Hope this helps,
-Christoffer
prev parent reply other threads:[~2017-07-05 6:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-03 21:56 How to trap a real interrupt to EL2 ? Raz
2017-07-04 1:25 ` Jintack Lim
2017-07-04 11:12 ` Christoffer Dall
2017-07-04 19:32 ` Raz
2017-07-05 6:23 ` Christoffer Dall [this message]
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=20170705062334.GA18106@cbox \
--to=cdall@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=raziebe@gmail.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