[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.19 12:15, Julien Grall wrote:
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.

I guess your question is *why* do I split hyp/guest time in such a way.

So for the guest I count time spent in the guest mode. Plus time spent in 
hypervisor mode to serve explicit requests by guest.

That time may be quite deterministic from the guest's point of view.

But the time spent by hypervisor to handle interrupts, update the hardware 
state is not requested by the guest itself. It is a virtualization overhead. 
And the overhead heavily depends on the system configuration (e.g. how many 
guests are running).
That overhead may be accounted for a guest or for hyp, depending on the model 

My idea is as following:
Accounting that overhead for guests is quite OK for server applications, you 
put server overhead time on guests and charge money from their budget.
Yet for RT applications you will have more accurate view on the guest execution 
time if you drop that overhead.

Our target is XEN in safety critical systems. So I chosen more deterministic 
(from my point of view) approach.

Well, I suppose we may add granularity to the time accounting, and then decide 
at the scheduler level what we count for the guest execution time.

But it is so far from the end, and we are here to discuss and agree the stuff.

Andrii Anisov.

Xen-devel mailing list



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