Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]