On Thu, Jun 7, 2012 at 10:43 AM, Marc Zyngier <marc.zyngier at arm.com> wrote: > On 07/06/12 15:32, Christoffer Dall wrote: >> On Thu, Jun 7, 2012 at 10:20 AM, Peter Maydell <peter.maydell at linaro.org> wrote: >>> On 7 June 2012 15:09, Christoffer Dall <c.dall at virtualopensystems.com> wrote: >>>> I took "it is impossible to hide it [arch. timer support] from the >>>> guest" to mean that if the host has arch. timer support the guest must >>>> in fact support it. >>> >>> No. That means "if the host has arch.timer support it is not >>> possible to present to the guest a virtual CPU which does not >>> have arch.timers". (You can fake the ID register to not set the >>> bit which says "arch timers present", but you can't make the >>> cp15 registers UNDEF if the guest goes ahead and prods them >>> anyway.) >>> >> >> I understand, but what happens if VGIC support is not enabled in the >> host (and thereby arch. timer for VMs are not enabled in KVM) adn the >> guest still prods the cp15 registers? everything breaks or just the >> guest? > > It will most probably result in a breakage on the host as well (both > will try to use the virtual timers, and bad things will happen). > > What we could do is to force the host to switch to physical timers (and > disable access to the guest), regardless of timer support in KVM (at the > moment, this is only done if we enable timer support), and let the guest > hang while waiting for a timer interrupt to occur. > > In any case, this is ugly. > ok, so basically if you configure KVM and have arch. timers support in the host, KVM will configure the arch. timers and expect the guest to use them and the host will always be stable - correct? If the guest doesn't use the arch timers in this case, we don't really care I guess. -Christoffer
