Hi,
I'm developing a baremetal hypervisor for Cortex-A15 and I'm using Arndale Board as a reference platform. ATM, I'm working on running Linaro 13.02 as a guest.
I've noticed that `arch/arm/kernel/arch_timer.c` Linux prefers the virtual IRQ timers (CNTV_):
static bool arch_timer_use_virtual = false;
as a timer source and I'm wondering if there's a reason for this. Is it even possible for virtual timer to be available, while physical one is not? I don't think so. So why would Linux want to default to virtual one instead of physical one, especially in the situation when it was started in SVC mode and HYP is not accessible to it?
From Hypervisor point of view, it seems natural that guest does not
care about virtualization stuff, does not try to be smarter than necessary and simply uses physical timer (PL1) all the time.
It's hypervisor's job to trap guest accesses to physical timer (CNTP_) and route them to virtual timer (CNTV_) so virtual offset (CNTVOFF) value can be easily switched (again, by hypervisor, not the guest) when handling multiple guests, to correctly handle virtual time for them. In opposite direction the hardware virtual timer irq is just renumbered to appear to guest as a physical one.
While emulating the CNTVOFF and CNTV_ is entirely possible too and required for completeness, it seems like additional work for no apparent reason. So I wanted to clarify this. Maybe there is something that I don't understand or I misread the intentions described in reference manual.
On Fri, Mar 8, 2013 at 8:26 PM, dpc@ucore.info dpc@ucore.info wrote:
static bool arch_timer_use_virtual = false;
Sorry, this is:
static bool arch_timer_use_virtual = true;
in the original source. I've just pasted the line after I've hacked it.
On Fri, 8 Mar 2013, dpc@ucore.info wrote:
Hi,
I'm developing a baremetal hypervisor for Cortex-A15 and I'm using Arndale Board as a reference platform. ATM, I'm working on running Linaro 13.02 as a guest.
I've noticed that `arch/arm/kernel/arch_timer.c` Linux prefers the virtual IRQ timers (CNTV_):
static bool arch_timer_use_virtual = false;
And how does "false" prefer virtual ?
as a timer source and I'm wondering if there's a reason for this. Is it even possible for virtual timer to be available, while physical one is not? I don't think so. So why would Linux want to default to virtual one instead of physical one, especially in the situation when it was started in SVC mode and HYP is not accessible to it?
From Hypervisor point of view, it seems natural that guest does not care about virtualization stuff, does not try to be smarter than necessary and simply uses physical timer (PL1) all the time.
That's utter nonsense. If the guest knows that it runs in a virtual machine it better uses stuff which was designed to work in a virtual machine rather than trapping out for no good reason.
It's hypervisor's job to trap guest accesses to physical timer (CNTP_) and route them to virtual timer (CNTV_) so virtual offset (CNTVOFF) value can be easily switched (again, by hypervisor, not the guest) when handling multiple guests, to correctly handle virtual time for
Are you really sure, that you want to develop a hypervisor?
It's the damned job of the hypervisor to stay out of the way as much as possible and you can do the handling of multiple guests on a physical core when you actually schedule out guest A and schedule in guest B. Why the heck do you want to trap for each access of the timer if the hardware provides proper means to avoid it? Just because you can or what?
Thanks,
tglx
On Fri, Mar 8, 2013 at 8:57 PM, Thomas Gleixner tglx@linutronix.de wrote:
I've noticed that `arch/arm/kernel/arch_timer.c` Linux prefers the virtual IRQ timers (CNTV_):
static bool arch_timer_use_virtual = false;And how does "false" prefer virtual ?
It's `= true` in the original source, I've pasted it altered already, by mistake.
It's hypervisor's job to trap guest accesses to physical timer (CNTP_) and route them to virtual timer (CNTV_) so virtual offset (CNTVOFF) value can be easily switched (again, by hypervisor, not the guest) when handling multiple guests, to correctly handle virtual time for
Are you really sure, that you want to develop a hypervisor?
It's the damned job of the hypervisor to stay out of the way as much as possible and you can do the handling of multiple guests on a physical core when you actually schedule out guest A and schedule in guest B. Why the heck do you want to trap for each access of the timer if the hardware provides proper means to avoid it? Just because you can or what?
The CNTP_ does not use CNTVOFF. If for some reason hypervisor wants to completly pretend what the guest platform timer is (more like a full virtual-machine) it needs to trap CNTP_ anyway and fake it. Simple re-routing to CNTV_ seemed like a great way to do this.
While I'm thinking about it ... maybe I didn't get the intended purpose of all these timers right. As CNTV is clearly available to the guests, should I consider that the guests will be virtualization-aware and by default use CNTV_, and in case I really need to fake the CNTP_ (which is rarely the case, I guess), I can just do the math manually? Makes sense.
Thanks for clarification,
linaro-kernel@lists.linaro.org
-
Dawid Ciężarkiewicz -
dpc＠ucore.info -
Thomas Gleixner