Xen Guest Timer (ARM) question

Xen Guest Timer (ARM) question

[embeddev student]

[-- Attachment #1.1: Type: text/plain, Size: 698 bytes --]

Hello Xen Team,

I am trying to understand the Timer implementation for a Guest. After going
through the code I have a few trivial questions,

a) As per ARM documentation There are 3 timers
i) Physical Timer
ii) Virtual Timer
iii) Hypervisor Timer
As per my understanding the hypervisor timer is for Xen and Virtual Timer
is for Domain. I am not able to find the need for a physical timer in a Xen
system.
Q1. Why is guest not given only a virtual timer, What is the need for  the
guest to have a physical timer as well ?

Q2. In virt_timer_save set_timer is called. If vcpu is going in a suspended
state what is the requirement of a timer being set ?

Thanks and Best Regards
embedded dev student

[-- Attachment #1.2: Type: text/html, Size: 910 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen Guest Timer (ARM) question

[Ian Campbell]

On Sun, 2014-08-31 at 15:01 +0530, embeddev student wrote:

> Q1. Why is guest not given only a virtual timer, What is the need for
> the guest to have a physical timer as well ?

Some guest kernels may not know about the virt timer yet, since it is
new, or they may choose not to use it for some reason (not so likely
since we require paravirt of the timers under Xen today, but eventually
we may want to think about running unmodified OSes on ARM).

It can also occasionally be useful for Paravirtualisation to know both
the real and virtual time (although I can't think of an example off
hand...)

> Q2. In virt_timer_save set_timer is called. If vcpu is going in a
> suspended state what is the requirement of a timer being set ?

This is setting a Xen software timer, not a hardware timer (except that
setting  software timer may trigger the hypervisor timer to be used to
fulfil it).

Since we are descheduling the vcpu we save its virt+phys timer state,
including the comparators, so we can use the hardware for the next vcpu.
The timer is there to make sure we wake up the vcpu when its timer would
have expired and triggered an interrupt.

Ian.

Re: Xen Guest Timer (ARM) question

[embeddev student]

On Sun, Aug 31, 2014 at 7:56 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
>
> On Sun, 2014-08-31 at 15:01 +0530, embeddev student wrote:
>
> > Q1. Why is guest not given only a virtual timer, What is the need for
> > the guest to have a physical timer as well ?
>
> Some guest kernels may not know about the virt timer yet, since it is
> new, or they may choose not to use it for some reason (not so likely
> since we require paravirt of the timers under Xen today, but eventually
> we may want to think about running unmodified OSes on ARM).
>
> It can also occasionally be useful for Paravirtualisation to know both
> the real and virtual time (although I can't think of an example off
> hand...)
>
> > Q2. In virt_timer_save set_timer is called. If vcpu is going in a
> > suspended state what is the requirement of a timer being set ?
>
> This is setting a Xen software timer, not a hardware timer (except that
> setting  software timer may trigger the hypervisor timer to be used to
> fulfil it).
>
> Since we are descheduling the vcpu we save its virt+phys timer state,
> including the comparators, so we can use the hardware for the next vcpu.
> The timer is there to make sure we wake up the vcpu when its timer would
> have expired and triggered an interrupt.
>
Wouldnt there be a problem in this? If two guests timers are
configured to expire at the same physical time, how would Xen knows it
needs to inject the interrupt into which Guest. It always injects
virtual timer interrupt into current which many be G3.

>From a pure academic point of view, and using ARM virtual timers in
VMs, below is my take on ARM Timer Virtualization
(a) Guest would be using a HW Virtual Timer Interrupt  and Hypervisor
should use HW Hypervisor Timer Interrupt.
(b) Paravirt Timers may not be required as ARM has provided the same
feature to minimize the context switches to read the TimerCounter
(c) If a guest is running only then the virtual time be incremented.
So if two vcpus are there and there is only 1 physical core
(hypothetically) then the guest time be incremented as long as any
vcpu is running for that guest.



>
> Ian.

Re: Xen Guest Timer (ARM) question

[Stefano Stabellini]

On Tue, 2 Sep 2014, embeddev student wrote:
> On Sun, Aug 31, 2014 at 7:56 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> >
> > On Sun, 2014-08-31 at 15:01 +0530, embeddev student wrote:
> >
> > > Q1. Why is guest not given only a virtual timer, What is the need for
> > > the guest to have a physical timer as well ?
> >
> > Some guest kernels may not know about the virt timer yet, since it is
> > new, or they may choose not to use it for some reason (not so likely
> > since we require paravirt of the timers under Xen today, but eventually
> > we may want to think about running unmodified OSes on ARM).
> >
> > It can also occasionally be useful for Paravirtualisation to know both
> > the real and virtual time (although I can't think of an example off
> > hand...)
> >
> > > Q2. In virt_timer_save set_timer is called. If vcpu is going in a
> > > suspended state what is the requirement of a timer being set ?
> >
> > This is setting a Xen software timer, not a hardware timer (except that
> > setting  software timer may trigger the hypervisor timer to be used to
> > fulfil it).
> >
> > Since we are descheduling the vcpu we save its virt+phys timer state,
> > including the comparators, so we can use the hardware for the next vcpu.
> > The timer is there to make sure we wake up the vcpu when its timer would
> > have expired and triggered an interrupt.
> >
> Wouldnt there be a problem in this? If two guests timers are
> configured to expire at the same physical time, how would Xen knows it
> needs to inject the interrupt into which Guest. It always injects
> virtual timer interrupt into current which many be G3.

Each Xen timer would expire independently.
I think you are still confusing hardware timers and Xen timers (struct
timer).


> >From a pure academic point of view, and using ARM virtual timers in
> VMs, below is my take on ARM Timer Virtualization
> (a) Guest would be using a HW Virtual Timer Interrupt  and Hypervisor
> should use HW Hypervisor Timer Interrupt.
> (b) Paravirt Timers may not be required as ARM has provided the same
> feature to minimize the context switches to read the TimerCounter
> (c) If a guest is running only then the virtual time be incremented.
> So if two vcpus are there and there is only 1 physical core
> (hypothetically) then the guest time be incremented as long as any
> vcpu is running for that guest.

This is known not to work. Lots of things need to know exactly how much
*real* time has passed. For example think of a device driver that needs
to use timestamps to program the device.