* Routing physical interrupts to EL1 @ 2018-07-06 3:51 Saeed Mirzamohammadi 2018-07-06 13:13 ` Julien Grall 0 siblings, 1 reply; 6+ messages in thread From: Saeed Mirzamohammadi @ 2018-07-06 3:51 UTC (permalink / raw) To: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1144 bytes --] Hi, 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? 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 the vcpus but gets stuck after return from leave_hypervisor_tail for the last vcpu.* Any help is appreciated, Thanks, -- Saeed Mirzamohammadi PhD Student Department of Computer Science University of California, Irvine Irvine, CA 92617 saeed@uci.edu <smirzamo@uci.edu> http://www.ics.uci.edu/~saeed/ <http://www.ics.uci.edu/~smirzamo/> [-- Attachment #1.2: Type: text/html, Size: 4393 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Routing physical interrupts to EL1 2018-07-06 3:51 Routing physical interrupts to EL1 Saeed Mirzamohammadi @ 2018-07-06 13:13 ` Julien Grall 2018-07-07 19:32 ` Saeed Mirzamohammadi 0 siblings, 1 reply; 6+ messages in thread From: Julien Grall @ 2018-07-06 13:13 UTC (permalink / raw) To: Saeed Mirzamohammadi, xen-devel, Stefano Stabellini 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Routing physical interrupts to EL1 2018-07-06 13:13 ` Julien Grall @ 2018-07-07 19:32 ` Saeed Mirzamohammadi 2018-07-07 21:25 ` Julien Grall 0 siblings, 1 reply; 6+ messages in thread From: Saeed Mirzamohammadi @ 2018-07-07 19:32 UTC (permalink / raw) To: Julien Grall; +Cc: xen-devel, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 2905 bytes --] Thanks for your detailed reply. On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall <julien.grall@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 saeed@uci.edu <smirzamo@uci.edu> http://www.ics.uci.edu/~saeed/ <http://www.ics.uci.edu/~smirzamo/> [-- Attachment #1.2: Type: text/html, Size: 5693 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Routing physical interrupts to EL1 2018-07-07 19:32 ` Saeed Mirzamohammadi @ 2018-07-07 21:25 ` Julien Grall 2018-08-02 19:14 ` Saeed Mirzamohammadi 0 siblings, 1 reply; 6+ messages in thread From: Julien Grall @ 2018-07-07 21:25 UTC (permalink / raw) To: Saeed Mirzamohammadi; +Cc: xen-devel, Stefano Stabellini Hello, On 07/07/2018 08:32 PM, Saeed Mirzamohammadi wrote: > Thanks for your detailed reply. > > On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall <julien.grall@arm.com > <mailto:julien.grall@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. Do you include Dom0 in your "one guest domain"? If so, may I ask what is your end goal? Why not booting the OS on baremetal? > 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. Well, Xen still needs interrupts for other things like UART and SMMU. It also needs interrupts to IPI other pCPU such as for softirq, unblocking another vCPU (waiting on an event for instance)... I don't think you can discard interrupts that easily in Xen without some cooperation with the guest. Let's imagine Xen IPIs another pCPU. If interrupts are routed to your guest, this guest will receive the IPIs and will not understand what to do. > 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? Depends on your interrupts controller. On GICv4, you will be able to directly injected some LPIs (i.e MSI). > > > > 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 > <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? If you want to route *all* the interrupts, you can map GICC and not GICV to your guest. So when the guest will read IAR, it will read the physical interrupts. > > > 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)? SGIs register are already trapped by Xen. They are emulated by writing the corresponding interrupt to the LRs. However, SGIs are not the only interrupt generated by the hypervisor directly. There are also the event channel (a PPI) or any device emulated by the hypervisor (e.g PL011). Trying to remove interrupts from the hypervisor is more a pain compare to the benefits you will gain. You will be better at improving the latency when receiving interrupt (AFAIK this is already be good). Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Routing physical interrupts to EL1 2018-07-07 21:25 ` Julien Grall @ 2018-08-02 19:14 ` Saeed Mirzamohammadi 2018-08-02 19:52 ` Julien Grall 0 siblings, 1 reply; 6+ messages in thread From: Saeed Mirzamohammadi @ 2018-08-02 19:14 UTC (permalink / raw) To: Julien Grall; +Cc: xen-devel, Stefano Stabellini [-- Attachment #1.1: Type: text/plain, Size: 6082 bytes --] Sorry for the late reply. On Sat, Jul 7, 2018 at 2:25 PM, Julien Grall <julien.grall@arm.com> wrote: > Hello, > > On 07/07/2018 08:32 PM, Saeed Mirzamohammadi wrote: > >> Thanks for your detailed reply. >> >> On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall <julien.grall@arm.com >> <mailto:julien.grall@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. >> > > Do you include Dom0 in your "one guest domain"? If so, may I ask what is > your end goal? Why not booting the OS on baremetal? > > Yes, I only have the Dom0 domain and no DomU. My end goal is to make Xen transparent to the interrupts but have control over the memory management and be able to create another domain (like a driver domain) on-demand whenever I need it. > 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. >> > > Well, Xen still needs interrupts for other things like UART and SMMU. It > also needs interrupts to IPI other pCPU such as for softirq, unblocking > another vCPU (waiting on an event for instance)... I don't think you can > discard interrupts that easily in Xen without some cooperation with the > guest. > > Let's imagine Xen IPIs another pCPU. If interrupts are routed to your > guest, this guest will receive the IPIs and will not understand what to do. My end goal is that all the IPIs are handled in the guest like when it is on baremetal. > > > 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? >> > > Depends on your interrupts controller. On GICv4, you will be able to > directly injected some LPIs (i.e MSI). > > > >> >> >> 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 >> <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? >> > > If you want to route *all* the interrupts, you can map GICC and not GICV > to your guest. So when the guest will read IAR, it will read the physical > interrupts. > > >> >> 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)? >> > > SGIs register are already trapped by Xen. They are emulated by writing the > corresponding interrupt to the LRs. > > How can make it available to the guest and not trap in Xen? Is it doable? > However, SGIs are not the only interrupt generated by the hypervisor > directly. There are also the event channel (a PPI) or any device emulated > by the hypervisor (e.g PL011). > > Trying to remove interrupts from the hypervisor is more a pain compare to > the benefits you will gain. You will be better at improving the latency > when receiving interrupt (AFAIK this is already be good). > > I changed the value of the HCR_EL2 register after doing a hypercall in "leave_hypervisor_tail" and now debugging. I realize that "guest_sync" in entry.S doesn't return back to the guest (I put a print after my hypercall in the guest and doesn't show up). I see that "return_from_trap" gets called. I suppose that eret should take me back to the hvc call I made in the guest. I checked the value of the LR register (link register that store the return address) in "return_from_trap" and there is no change. Do you know why changing the value of the HCR_EL2 register should affect returning back to the guest? Also, without changing the register value I get back to the guest from Xen normally. Cheers, > > -- > Julien Grall > Thanks a bunch! -- Saeed Mirzamohammadi PhD Student Department of Computer Science University of California, Irvine Irvine, CA 92617 saeed@uci.edu <smirzamo@uci.edu> http://www.ics.uci.edu/~saeed/ <http://www.ics.uci.edu/~smirzamo/> [-- Attachment #1.2: Type: text/html, Size: 9814 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Routing physical interrupts to EL1 2018-08-02 19:14 ` Saeed Mirzamohammadi @ 2018-08-02 19:52 ` Julien Grall 0 siblings, 0 replies; 6+ messages in thread From: Julien Grall @ 2018-08-02 19:52 UTC (permalink / raw) To: Saeed Mirzamohammadi; +Cc: xen-devel, nd, Stefano Stabellini Hello, Please configure your e-mail client to quote properly (i.e with >). On 02/08/2018 20:14, Saeed Mirzamohammadi wrote: > Sorry for the late reply. > > On Sat, Jul 7, 2018 at 2:25 PM, Julien Grall <julien.grall@arm.com > <mailto:julien.grall@arm.com>> wrote: > > Hello, > > On 07/07/2018 08:32 PM, Saeed Mirzamohammadi wrote: > > Thanks for your detailed reply. > > On Fri, Jul 6, 2018 at 6:13 AM, Julien Grall > <julien.grall@arm.com <mailto:julien.grall@arm.com> > <mailto:julien.grall@arm.com <mailto:julien.grall@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. > > > Do you include Dom0 in your "one guest domain"? If so, may I ask > what is your end goal? Why not booting the OS on baremetal? > > Yes, I only have the Dom0 domain and no DomU. My end goal is to make Xen > transparent to the interrupts but have control over the memory > management and be able to create another domain (like a driver domain) > on-demand whenever I need it. Then you really don't want bypass Xen for the interrupts... If you do that, you will lose the ability to communicate between physical CPUs in the hypervisor. > > 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. > > > Well, Xen still needs interrupts for other things like UART and > SMMU. It also needs interrupts to IPI other pCPU such as for > softirq, unblocking another vCPU (waiting on an event for > instance)... I don't think you can discard interrupts that easily in > Xen without some cooperation with the guest. > > Let's imagine Xen IPIs another pCPU. If interrupts are routed to > your guest, this guest will receive the IPIs and will not understand > what to do. > > My end goal is that all the IPIs are handled in the guest like when it > is on baremetal. You keep saying interrupts should be directly routed to the guest but you don't explain why you want that. As I said in my previous e-mail, trying to remove interrupts from the hypervisor is more a pain compare to the benefits you will gain. You will be better at improving the latency when receiving interrupt (AFAIK this is already be good). > > > > 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? > > > Depends on your interrupts controller. On GICv4, you will be able to > directly injected some LPIs (i.e MSI). > > > > > > 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 > <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500d/CIHJHAAG.html> > > <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500d/CIHJHAAG.html > <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? > > > If you want to route *all* the interrupts, you can map GICC and not > GICV to your guest. So when the guest will read IAR, it will read > the physical interrupts. > > > > 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)? > > > SGIs register are already trapped by Xen. They are emulated by > writing the corresponding interrupt to the LRs. > > How can make it available to the guest and not trap in Xen? Is it doable? I am afraid you are on your own here. Xen requires interrupts for itself (e.g scheduling, timer, event channel...). If you want more information then I invite you to read my previous e-mail again. > > However, SGIs are not the only interrupt generated by the hypervisor > directly. There are also the event channel (a PPI) or any device > emulated by the hypervisor (e.g PL011). > > Trying to remove interrupts from the hypervisor is more a pain > compare to the benefits you will gain. You will be better at > improving the latency when receiving interrupt (AFAIK this is > already be good). > > I changed the value of the HCR_EL2 register after doing a hypercall in > "leave_hypervisor_tail" and now debugging. I realize that "guest_sync" > in entry.S doesn't return back to the guest (I put a print after my > hypercall in the guest and doesn't show up). I see that > "return_from_trap" gets called. I suppose that eret should take me back > to the hvc call I made in the guest. I checked the value of the LR > register (link register that store the return address) in > "return_from_trap" and there is no change. > Do you know why changing the value of the HCR_EL2 register should affect > returning back to the guest? Also, without changing the register value > I get back to the guest from Xen normally. While eret means returning in the guest, you may receive an exception (e.g interrupt) in the guest diverting from the "normal" path. Hence why you don't see the message after the "hvc". It is likely possible you get stuck in the exception handler. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-08-02 19:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-07-06 3:51 Routing physical interrupts to EL1 Saeed Mirzamohammadi 2018-07-06 13:13 ` Julien Grall 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
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).