ron minnich wrote: > On 5/21/07, Anthony Liguori <[EMAIL PROTECTED]> wrote: >> 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 :-)
Sometimes I think the best way to make you happy is to just stop talking :-) > 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. Okay. The first problem here is that you're assuming that I'm suggesting that this who thing mandate a PCI bus. I'm not. I'm merely saying that one possible way to implement this is by using a PCI bus to discover the existing of a VIRTLINK socket. Clearly, the s390 guys would have to use something else. For PV Xen where there is no PCI bus, XenBus would be used. So very concretely, there are three separate classes of problems: 1) How to determine that a VM can use virtlink sockets 2) How to enumerate paravirtual devices 3) The various PV protocols for each device Whatever Linux implements, it has to allow multiple implementations for #1. For x86 VMs, PCI is just the easiest thing to do here. You could do hypercalls but it gets messy on different hypervisors (vmcall with 0 in eax may do something funky in Xen but be the probing hypercall on KVM). For #2, I'm not really proposing anything concrete. One possibility is to allow virtlink sockets to be addressed with a "service" and to use that. That doesn't allow for enumeration though so it may not be perfect. I'm not proposing anything at all for #3. That's outside the scope of this discussion in my mind. Now, once you have a virtlink socket, could you use p9 to implement #2 and #3? Sounds like something you could write a paper about :-) But that's later argument. Right now, I'm just focused on solving the boot strap issue. Hope this clarifies things a bit. Regards, Anthony Liguori > 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
