From: Julien Grall <julien.grall@arm.com>
To: Saeed Mirzamohammadi <saeed.mzmd@gmail.com>,
xen-devel@lists.xenproject.org,
Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: Routing physical interrupts to EL1
Date: Fri, 6 Jul 2018 14:13:26 +0100 [thread overview]
Message-ID: <0eb78867-7802-f38a-0711-d5336b262d0f@arm.com> (raw)
In-Reply-To: <CALPKaJ=qbh0rLK+MC=fC966=D50+_3eOCTYbQcbCyqm1psaYcg@mail.gmail.com>
On 06/07/18 04:51, Saeed Mirzamohammadi wrote:
> Hi,
Hello,
> I'm trying to route all the physical interrupts to the guest domain
> rather than being trapped in the Xen. I would like to know what is the
> right way to do that?
May I ask what is your use case for that? If you route interrupts to the
guest, Xen will not receive vital interrupt such as the timer, UART,
SMMU interrupts, maintenance interrupt....
>
> I know that HCR_IMO bit in the HCR_EL2 register is supposed to be for
> routing the interrupts to the guest (Routing to EL1 instead of EL2).
> link to the datasheet:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500d/CIHJHAAG.html
>
> So, I have tried doing the following in the leave_hypervisor_tail. I run
> a simple hypercall and do the following lines before return (which is I
> guess the last point of exit to the guest from hypervisor):
> ---------------------
> /current->arch.hcr_el2 &= ~HCR_IMO;/
> /WRITE_SYSREG(current->arch.hcr_el2, HCR_EL2);/
> /isb();/
> /----------------------/
> /
> /
> /It looks like to be doing it right for all thevcpus butgets stuck after
> return from leave_hypervisor_tail for the lastvcpu.
What do you mean by stuck? Do you see any logs?
HCR_EL2.IMO unset means the interrupt will get signaled to EL1. It does
not affect how interrupt will get read (e.g IAR).
Which interrupt controller are you using?
In case of GICv2, Xen is re-mapping GICC to GICV. So when the guest is
reading IAR, it will read the interrupts from the LRs. Not the physical
interface.
In case of GICv3, HCR_EL2.IMO will also control the access. So you
should be fine here.
However, in both case you will at least need to rework the way software
generated interrupts are sent to the guest. At the moment, they are
written in the LRs.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-07-06 13:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 3:51 Routing physical interrupts to EL1 Saeed Mirzamohammadi
2018-07-06 13:13 ` Julien Grall [this message]
2018-07-07 19:32 ` Saeed Mirzamohammadi
2018-07-07 21:25 ` Julien Grall
2018-08-02 19:14 ` Saeed Mirzamohammadi
2018-08-02 19:52 ` Julien Grall
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=0eb78867-7802-f38a-0711-d5336b262d0f@arm.com \
--to=julien.grall@arm.com \
--cc=saeed.mzmd@gmail.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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).