On 2011-12-04 14:31, Avi Kivity wrote:
> On 12/03/2011 01:17 PM, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@xxxxxxxxxxx>
>>
>> Introduce the alternative 'kvm-i8259' device model that exploits KVM
>> in-kernel acceleration.
>>
>> The PIIX3 initialization code is furthermore extended by KVM specific
>> IRQ route setup. Moreover, GSI injection differs in KVM mode from the
>> user space model. As we can dispatch ISA-range IRQs to both IOAPIC and
>> PIC inside the kernel, we do not need to inject them separately. This is
>> reflected by a KVM-specific GSI handler.
>>
>> +
>> +qemu_irq *kvm_i8259_init(void)
>> +{
>> + ISADevice *dev;
>> +
>> + dev = isa_create("kvm-i8259");
>>
>
> Same issue. Is this a different device, or an different implementation
> of the same device?
They are theoretically the same from guest perspective (therefore you
can migrate between machines that differ in this).
>
> We're forcing migration from 1.0 to 1.1 to disable in-kernel irqchip on
> the target. For qemu itself, that's no issue. But for qemu-kvm, it
> will result in loss of performance, or hacks to alias the two back together.
We should this happen with qemu-kvm? The vmstates are compatible, thus
you can migration from old qemu-kvm in-kernel devices to the new kvm-*
ones (once they are feature-equivalent). Not sure how much hacks this
may require to qemu-kvm, but I don't think it should make the situation
worse for that tree.
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
