[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 14/16] kvm: x86: Add user space part for in

From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC][PATCH 14/16] kvm: x86: Add user space part for in-kernel i8259
Date: Sun, 04 Dec 2011 14:42:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2011-12-04 14:31, Avi Kivity wrote:
> On 12/03/2011 01:17 PM, Jan Kiszka wrote:
>> From: Jan Kiszka <address@hidden>
>> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]