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:
signature.asc
Description: OpenPGP digital signature
