Xen project Mailing List

Thanks for your detailed reply.

On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall <julien.grall@xxxxxxx> 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

saeed@xxxxxxx

http://www.ics.uci.edu/~saeed/

Re: [Xen-devel] Routing physical interrupts to EL1