ron minnich wrote: > On 5/22/07, Eric Van Hensbergen <[EMAIL PROTECTED]> wrote: > > >> I'm not opposed to supporting emulation environments, just don't make >> a large pile of crap the default like Xen -- and having to integrate >> PCI probing code in my guest domains is a large pile of crap. >> > > Exactly. I'm about to start a pretty large project here, using xen or > kvm, not sure. One thing for sure, we are NOT going to use anything > but PV devices. Full emulation is nice, but it's just plain silly if > you don't have to do it. And we don't have to do it. So let's get the > PV devices right, not try to shoehorn them into some framework like > PCI. > > What happens to these schemes if I want to try, e.g., 2^16 PV devices? > Or some other crazy thing that doesn't play well with PCI -- simple > example -- I want a 256 GB region of memory for a device. PCI rules > require me to align it on 256GB boundaries and it must be contiguous > address space. This is a hardware rule, done for hardware reasons, and > has no place in the PV world. What if I want a bit more than the basic > set of BARs that PCI gives me? Why would we apply such rules to a PV? > Why limit ourselves this early in the game? > >
Device discovery and device operation are separate. Closed operating systems and older Linuces will need pci as a way to have easy plug'n'play discovery with no modifications to the kernel. Virtualization-friendly systems like newer Linux and s390 can have a virtual bus for discovery. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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
