Eric Van Hensbergen wrote: > 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 PV environment why not just pass an initial cookie/hash/whatever > as a command-line argument/register/memory-space to the underlying > kernel?
You can't pass a command line argument to Windows (at least, not easily AFAIK). You could get away with an MSR/CPUID flag but then you're relying on uniqueness which isn't guaranteed. > The presence of such a kernel argument would suggest the > existence of a hypercall interface or other such mechanism to "attach" > to the initial transport(s). Command-line arguments may be a bit too > linux-centric to Ron's taste, but if we are going to chose something > arbitrary like PCI, I'd prefer we chose something a bit more > straightforward to interact with instead of doing crazy ritual dances > to extract what should be straightforward information. I really don't > want to have integrate PCI parsing into my testOS/libOS kernels. You could just hard code a PIC interrupt and rely on some static memory address for IO and avoid the PCI bus entirely. The whole point of the PCI bus is to avoid hardcoding this sort of things but if you don't want the complexity associated with PCI, then using the "older" mechanisms seems like the obvious thing to do. Regards, Anthony Liguori > -eric > ------------------------------------------------------------------------- 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
