On Wed, Jun 6, 2012 at 6:07 AM, Marc Zyngier <marc.zyngier at arm.com> wrote: > On 05/06/12 18:45, Christoffer Dall wrote: >> On Mon, May 14, 2012 at 12:26 PM, Marc Zyngier <marc.zyngier at arm.com> wrote: >>> On 14/05/12 16:48, Peter Maydell wrote: >>>> On 14 May 2012 14:06, Marc Zyngier <marc.zyngier at arm.com> wrote: >>>>> This patch series adds support for the architected timer for the >>>>> guest. It relies on the VGIC code to inject timer interrupts. >>>> >>>> This seems like a good point to raise the suggestion that >>>> using the in-kernel support for the architected timer and >>>> VGIC should be mandatory. >>> >>> Indeed, thanks for pointing this out. This is why CONFIG_KVM_ARM_TIMER >>> depends on KVM_ARM_VGIC && ARM_ARCH_TIMER. >>> >> is it really that clear that we should just mandate this? If we are >> really sure that there will not be devices with virtualization >> extensions without GIC virtualization extensions support then fine >> (???). Otherwise, I think we definitely want to support such >> configurations. > > There is probably several configurations we want to support: > - Cortex-A7/15 host and guest: VGIC + ARCH_TIMER mandatory, or at least > be the default configuration. > - Hypothetical v7 + virt extensions but without VGIC: QEMU GIC emulation > + whatever timer the guest wants to use (and that QEMU provides). > > Whether or not someone will build this hypothetical v7, I have no idea. > But the fact that someone *could* build such a thing means we should > keep our interrupt injection code flexible enough. agreed > > When it comes to the architected timer, it is practically impossible to > use it in a guest without VGIC support. Even worse, it is impossible to > hide it from the guest. > so if there's architected timer support, mandate that the guest uses it, and make architected timer support rely on VGIC support is our scheme, right? I'm fine with that. -Christoffer
