[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC 1/6] xen/arm: Re-enable interrupt later in the trap path



Hello Dario

On 01.08.19 14:19, Dario Faggioli wrote:
On Thu, 2019-08-01 at 09:45 +0300, Andrii Anisov wrote:
Hello Julien,

On 30.07.19 23:10, Julien Grall wrote:

In this series I think I need interrupts locked until I start
time accounting for hypervisor. Time accounting is started by
`tacc_head()` function. I prefer to have it called from C,
because it is more convenient and obvious for those who are less
familiar with the ARM code.

Here is the question to you: what is the best place (and way) to
start hypervisor time tracking?

This is actually quite an important question... And I'd like to throw
it back at you (Andrii)! :-D :-P :-)

At this series I start time accounting for hypervisor after the trap, before 
interrupts being enabled. It is done for all traps except synchronous traps 
from guest, what are hypecalls and io emulation. For synchronous traps, I start 
hyp accounting after the guest's request has been served, and we start softirq 
processing (actually all the stuff `leave_hypervisor_tail()` does). I believe 
it should be so.

In fact, I was about to ask myself something similar, such as, can we
take a bit of a step back and define:

- what's the, let's say, accounting granularity we want? "Just" guest
and hypervisor? Or more fine grained?

As for me hypervisor/guest/idle is quite fine granularity for the beginning.
Such approach might be enough to implement fair time accounting.
Yet we might need something more sophisticated for RT scheduling. E.g. guest's 
IRQ time tracking, to not let some guest to spam the system with its IRQs.

- assuming we "just" want hypervisor and guest, which are the
events/turning points at which we should switch "timing accounting
bucket"? Can we make a list?
And I'd be fine for such list to be generic, in the first place (e.g.,
hypercall, IRQ, etc)... Then we'll turn the entries into actual
locations in the code, as a second step.


I can make such a list, how it is done in this series:

Guest -[async trap (IRQ)]-> Hyp : switch to hyp time accounting
Guest -[sync trap (hypercall, io emulation)]-> HYP : switch to hyp time 
accounting *after* serving sync trap (hypercall, io emulation)

Hyp -[any trap]-> Hyp : if (trapped from guest sync trap serving) then {switch 
to hyp time accounting}
Hyp -[return from trap]-> Hyp : if (returning to guest sync trap serving) then 
{switch to guest time accounting}

Hyp -[return from trap]-> Guest : switch to guest time accounting

--
Sincerely,
Andrii Anisov.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.