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

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

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 
agreed.

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.

--
Sincerely,
Andrii Anisov.

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