Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386

[Peter Maydell]

On 23 July 2012 14:38, Avi Kivity <address@hidden> 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