[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


On 02/08/2019 08:50, Andrii Anisov wrote:
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:

From the list below it is not clear what is the split between hypervisor time and guest time. See some of the examples below.

Guest -[async trap (IRQ)]-> Hyp : switch to hyp time accounting

Why all the interrupts should be accounted to the hypervisor? Why not accounting guest time for any interrupt routed to the current guest?

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

Why so? Some of the work after servicing an hypercall/IO emulation are still guest specific. For instance, we may update the hardware state for the guest (see vgic_sync_to_lrs()). We may also have defer work that take a long time (see check_for_pcpu_work()).

IHMO, the only part worth accounting to the hypervisor mode is check_for_pcpu_work().


Julien Grall

Xen-devel mailing list



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