On 23 July 2012 14:38, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 07/23/2012 04:27 PM, Peter Maydell wrote: >> That seems reasonable, although we have an awkward ordering issue >> in KVM as it stands: KVM_CREATE_IRQCHIP needs to be called before >> we start creating VCPU threads (at the moment it is done via kvm_init) >> but we don't know what kind of irqchip we want to create until the >> machine model code actually creates the irqchip device, which generally >> happens after the CPU object is created (and VCPU threads are created >> at that point). We could fix that by moving creation of the actual >> VCPU thread to vl.c after the model has been initialized. > > Seems to be purely a qemu problem, no? While I think it's reasonable to > be flexible, in this case I think qemu ought to know all these things > beforehand. Yes, sorry, I meant "issue in QEMU" but had a thinko; my suggested solution is basically shuffling code around in QEMU so we wait until we know what we are dealing with before asking the kernel to create the vcpu threads. >> (On a core with the virtualization extensions there are also >> signals for the GIC to raise a virtual IRQ or FIQ, but we can >> ignore those for KVM because we don't and can't provide the >> virtualization extensions to a guest.) > > Yet. There is no mechanism in the virtualization extensions to either trap on or present a false value for guest accesses to the CPSR mode bits. So you can't make the guest OS think it is in Hypervisor mode. Therefore you can't provide the guest with the virtualization extensions. (The same argument applies for Monitor mode and means you can't provide the Security extensions (TrustZone) to the guest either.) I guess you could handle all code in the guest hypervisor under TCG but implementing a hybrid TCG+KVM mode would be a lot of effort and probably not really perform very well anyway... -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
