On Tue, 2011-01-18 at 18:08 +0100, Jan Kiszka wrote: > On 2011-01-18 18:02, Alex Williamson wrote: > > On Tue, 2011-01-18 at 16:54 +0100, Jan Kiszka wrote: > >> On 2011-01-18 16:48, Anthony Liguori wrote: > >>> On 01/18/2011 09:43 AM, Jan Kiszka wrote: > >>>> On 2011-01-18 16:04, Anthony Liguori wrote: > >>>> > >>>>> On 01/18/2011 08:28 AM, Jan Kiszka wrote: > >>>>> > >>>>>> On 2011-01-12 11:31, Jan Kiszka wrote: > >>>>>> > >>>>>> > >>>>>>> Am 12.01.2011 11:22, Avi Kivity wrote: > >>>>>>> > >>>>>>> > >>>>>>>> On 01/11/2011 03:54 PM, Anthony Liguori wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Right, we should introduce a KVMBus that KVM devices are created on. > >>>>>>>>> The devices can get at KVMState through the BusState. > >>>>>>>>> > >>>>>>>>> > >>>>>>>> There is no kvm bus in a PC (I looked). We're bending the device model > >>>>>>>> here because a device is implemented in the kernel and not in > >>>>>>>> userspace. An implementation detail is magnified beyond all proportions. > >>>>>>>> > >>>>>>>> An ioapic that is implemented by kvm lives in exactly the same place > >>>>>>>> that the qemu ioapic lives in. An assigned pci device lives on the PCI > >>>>>>>> bus, not a KVMBus. If we need a pointer to KVMState, then we must find > >>>>>>>> it elsewhere, not through creating imaginary buses that don't exist. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Exactly. > >>>>>>> > >>>>>>> So we can either "infect" the whole device tree with kvm (or maybe a > >>>>>>> more generic accelerator structure that also deals with Xen) or we need > >>>>>>> to pull the reference inside the device's init function from some global > >>>>>>> service (kvm_get_state). > >>>>>>> > >>>>>>> > >>>>>> Note that this topic is still waiting for good suggestions, specifically > >>>>>> from those who believe in kvm_state references :). This is not only > >>>>>> blocking kvmstate merge but will affect KVM irqchips as well. > >>>>>> > >>>>>> It boils down to how we reasonably pass a kvm_state reference from > >>>>>> machine init code to a sysbus device. I'm probably biased, but I don't > >>>>>> see any way that does not work against the idea of confining access to > >>>>>> kvm_state or breaks device instantiation from the command line or a > >>>>>> config file. > >>>>>> > >>>>>> > >>>>> A KVM device should sit on a KVM specific bus that hangs off of sysbus. > >>>>> It can get to kvm_state through that bus. > >>>>> > >>>>> That bus doesn't get instantiated through qdev so requiring a pointer > >>>>> argument should not be an issue. > >>>>> > >>>>> > >>>> This design is in conflict with the requirement to attach KVM-assisted > >>>> devices also to their home bus, e.g. an assigned PCI device to the PCI > >>>> bus. We don't support multi-homed qdev devices. > >>>> > >>> > >>> With vfio, would an assigned PCI device even need kvm_state? > >> > >> IIUC: Yes, for establishing the irqfd link. > > > > We abstract this through the msi/msix layer though, so the vfio driver > > doesn't directly know anything about kvm_state. > > Which version/tree are you referring to? It wasn't the case in the last > version I found on the list. > > Does the msi layer use irqfd for every source in kvm mode then? Of > course, the key question will be how that layer will once obtain kvm_state. Looking at "[RFC PATCH v2] VFIO based device assignment" sent on Nov 5th, I guess we do call kvm_set_irqfd. Maybe I'm just wishing that the msi layer abstracted it better. I'd like to be able to pass in a userspace interrupt handler function pointer and an event notifier fd and let the interrupt layers worry about how it's hooked up. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
