Thanks for your detailed reply. On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall <julien.gr...@arm.com> wrote:
> > > 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 only have one guest domain. So, I'm trying to make Xen transparent to avoid any extra overhead caused by trapping interrupts. But I still need Xen for my own hypercalls. I don't need the timer cause I pinned and don't need any vcpu scheduler. Based on my understanding, I can only disable the interrupts on ARM all together using the HCR_EL2 register and we can't pick one interrupt to not trap, right? > > >> 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? > It's hung with no log. > > 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? > I'm using a GICv2. > 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. > So, in the case of GICv2, we can't route them cause Xen is the one that is updating the LRs and guest is reading from the LRs, am I right? > > 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. > > Is it possible to not trap on the ICDSGIR (SGI register)? Thanks, > Cheers, > > -- > Julien Grall > -- Saeed Mirzamohammadi PhD Student Department of Computer Science University of California, Irvine Irvine, CA 92617 sa...@uci.edu <smirz...@uci.edu> http://www.ics.uci.edu/~saeed/ <http://www.ics.uci.edu/~smirzamo/>
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
