Anthony Liguori wrote: >> Another point is that virtio still has a lot of leading zeros in its >> mileage counter. We need to keep things flexible and learn from >> others as much as possible, especially when talking about the ABI. > > Yes, after thinking about it over holiday, I agree that we should at > least introduce a virtio-pci feature bitmask. I'm not inclined to > attempt to define a hypercall ABI or anything like that right now but > having the feature bitmask will at least make it possible to do such a > thing in the future.
No, definitely not define a hypercall ABI. The feature bit should say "this device understands a hypervisor-specific way of kicking. consult your hypervisor manual and cpuid bits for further details. should you not be satisfied with this method, port io is still available". > >>> I'm wary of introducing the notion of hypercalls to this device >>> because it makes the device VMM specific. Maybe we could have the >>> device provide an option ROM that was treated as the device "BIOS" >>> that we could use for kicking and interrupt acking? Any idea of how >>> that would map to Windows? Are there real PCI devices that use the >>> option ROM space to provide what's essentially firmware? >>> Unfortunately, I don't think an option ROM BIOS would map well to >>> other architectures. >>> >>> >> >> The BIOS wouldn't work even on x86 because it isn't mapped to the >> guest address space (at least not consistently), and doesn't know the >> guest's programming model (16, 32, or 64-bits? segmented or flat?) >> >> Xen uses a hypercall page to abstract these details out. However, I'm >> not proposing that. Simply indicate that we support hypercalls, and >> use some layer below to actually send them. It is the responsibility >> of this layer to detect if hypercalls are present and how to call them. >> >> Hey, I think the best place for it is in paravirt_ops. We can even >> patch the hypercall instruction inline, and the driver doesn't need >> to know about it. > > Yes, paravirt_ops is attractive for abstracting the hypercall calling > mechanism but it's still necessary to figure out how hypercalls would > be identified. I think it would be necessary to define a virtio > specific hypercall space and use the virtio device ID to claim subspaces. > > For instance, the hypercall number could be (virtio_devid << 16) | > (call number). How that translates into a hypercall would then be > part of the paravirt_ops abstraction. In KVM, we may have a single > virtio hypercall where we pass the virtio hypercall number as one of > the arguments or something like that. If we don't call it a hypercall, but a virtio kick operation, we don't need to worry about the hypercall number or ABI. It's just a function that takes an argument that's implemented differently by every hypervisor. The default implementation can be a pio operation. >>>> Make it appear as a pci function? (though my feeling is that >>>> multiple mounts should be different devices; we can then hotplug >>>> mountpoints). >>>> >>> >>> We may run out of PCI slots though :-/ >>> >> >> Then we can start selling virtio extension chassis. > > :-) Do you know if there is a hard limit on the number of devices on > a PCI bus? My concern was that it was limited by something stupid > like an 8-bit identifier. IIRC pci slots are 8-bit, but you can have multiple buses, so effectively 16 bits of device address space (discounting functions which are likely not hot-pluggable). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel