On 5/21/07, Anthony Liguori <[EMAIL PROTECTED]> wrote: > ron minnich wrote: > > OK, so what are we doing here? We're using a PCI abstraction, as a > > common abstraction,which is not common really, because we don't have a > > common abstraction? So we describe all these non-pci resources with a > > pci abstraction? > > > > No. You're confusing PV device discovery with the actual paravirtual > transport. In a fully virtual environment like KVM, a PCI bus is > present. You need some way for the guest to detect that a PV device is > present. The most natural way to do this IMHO is to have an entry for > the PV device in the PCI bus. That will make a lot of existing code happy. >
I don't think I am confusing it, now that you've explained it more fully. I'm even less happy with it :-) How will I explain this sort of thing to my grandchildren? :-) "grandpop, why do those PV devices look like a bus defined in 1994?" Why would you not have, e.g., a 9p server for PV device "config space" as well? I actually implemented that on Xen -- it was quite trivial, and it makes more sense -- to me anyway -- than pretending a PV device is something it's not. What it happening, it seems to me, is that people are still trying to use an abstraction -- "PCI device" -- which is not really an abstraction, to model aspects of PV device discovery, enumeration, configuration and operation. I'm still pretty uncomfortable with it -- well, honestly, it seems kind of gross to me. It's just as easy to build the right abstraction underneath all this, and then, for those OSes that have existing code that needs to be happy, present that abstraction as a PCI bus. But making the PCI bus the underlying abstraction is getting the order inverted,I believe. I realize that PCI device space is a pretty handy way to do this, that it is very convenient. I wonder what happens when you get a system without enough "holes" in the config space for you to hide the PV devices in, or that has some other weird property that breaks this model. I've already worked with one system that had 32 PCI busses. There are other hypervisors that made convenient choices over the right choice, and they are paying for it. Let's try to avoid that on kvm. Kvm has so much going for it right now. thanks ron ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
