[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments |
Date: |
Mon, 10 Jan 2011 21:15:06 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
Am 10.01.2011 21:11, Anthony Liguori wrote:
> On 01/08/2011 02:47 AM, Jan Kiszka wrote:
>> OK, but I don't want to argue about the ioeventfd API. So let's put this
>> case aside. :)
>>
>
> I often reply too quickly without explaining myself. Let me use
> ioeventfd as an example to highlight why KVMState is a good thing.
>
> In real life, PIO and MMIO are never directly communicated to the device
> from the processor. Instead, they go through a series of other
> devices. In the case of something like an ISA device, a PIO first goes
> to the chipset into the PCI complex, it will then go through a
> PCI-to-ISA bridge via subtractive decoding, and then forward over the
> ISA device where it will be interpreted by some device.
>
> The path to the chipset may be shared among different processors but it
> may also be unique. The APIC is the best example as there are historic
> APICs that hung directly off of the CPUs such that the same MMIO access
> across different CPUs did not go to the same device. This is why the
> APIC emulation in QEMU is so weird because we don't model this behavior
> correctly.
>
> This means that a PIO operation needs to flow from a CPUState to a
> DeviceState. It can then flow through to another DeviceState until it's
> finally handled.
>
> The first problem with ioeventfd is that it's a per-VM operation. It
> should be per VCPU.
>
> But even if this were the case, the path that a PIO operation takes
> should not be impacted by ioeventfd. IOW, a device shouldn't be
> allocating an eventfd() and handing it to a magical KVM call. Instead,
> a device should register a callback for a particular port in the same
> way it always does. *As an optimization*, we should have another
> interface that says that these values are only valid for this IO port.
> That would let us create eventfds and register things behind the scenes.
>
> That means we can handle TCG, older KVM kernels, and newer KVM kernels
> without any special support in the device model. It also means that the
> device models never have to worry about KVMState because there's an
> entirely different piece of code that's consulting the set of special
> ports and then deciding how to handle it. The result is better, more
> portable code that doesn't have KVM-isms.
>
> If passing state around seems to be ugly, it's probably because we're
> not abstracting things correctly. Removing the state and making it
> implicit is the wrong solution. Fixing the abstraction is the right
> solution (or living with the ugliness until someone else is motivated to
> fix it properly).
Look at my other reply, it should answer this. ioeventfd is the wrong
example IMHO as one may argue about its relation to VCPUS.
Jan
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, (continued)
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Alexander Graf, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/10
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments,
Jan Kiszka <=
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
[Qemu-devel] [PATCH 25/35] kvm: x86: Drop MCE MSRs write back restrictions, Marcelo Tosatti, 2011/01/06
[Qemu-devel] [PATCH] kvm: x86: Fix build in absence of KVM_CAP_ASYNC_PF, Jan Kiszka, 2011/01/27