|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 4/9] arm64: utilize time accounting
(+ George and Dario) Hi, On 11/09/2019 11:32, Andrii Anisov wrote: From: Andrii Anisov <andrii_anisov@xxxxxxxx> Call time accounting hooks from appropriate transition points of the ARM64 code. Signed-off-by: Andrii Anisov <andrii_anisov@xxxxxxxx> --- xen/arch/arm/arm64/entry.S | 39 ++++++++++++++++++++++++++++++++++++--- xen/arch/arm/domain.c | 2 ++ 2 files changed, 38 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S index 2d9a271..6fb2fa9 100644 --- a/xen/arch/arm/arm64/entry.S +++ b/xen/arch/arm/arm64/entry.S @@ -143,12 +143,21 @@.endm - .macro exit, hyp, compat+ .macro exit, hyp, compat, tacc=1.if \hyp == 0 /* Guest mode */ + .if \tacc == 1 This is here because you may already be in the HYP state, right?I noticed in the previous patch you mention that you only handle "re-entry" for the IRQ state. As you don't have "exit" for states other than IRQ, then I would not consider this is as re-entry. It is more like you transition from one state to another (it happen this is the same state). The problem of re-entry would be if you take an exception that is going to switch the state. But the concern would be exactly the same if you take an exception that switch the state (such as synchronous hypervisor exception). This raises the question, how do you account SError interrupt/synchronous exception? As mentioned in the previous patch, leave_hypervisor_tail() may do some IO emulation that requires to be preemptible. So I don't think this is correct to get that time accounted to the hypervisor. + mov x0, #1 Any reason to call this before the if and not inside?
Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |