Gregory Haskins wrote: > >> PCI means that you can reuse all of the platform's infrastructure for >> irq allocation, discovery, device hotplug, and management. >> > > Its tempting to use, yes. However, most of that infrastructure is > completely inappropriate for a PV implementation, IMHO.
Why? > You are > probably better off designing something that is PV specific instead of > shoehorning it in to fit a different model (at least for the things I > have in mind). Well, if we design our pv devices to look like hardware, they will fit quite well. Both to the guest OS and to user's expectations. > Its not a heck of a lot of code to write a pv-centric > version of these facilities. > > It is. Especially if you consider Windows and a gazillion versions of deployed, non-pv-capable Linux systems. For pv-friendly newer Linux, it's probably doable, but why? Look at the mess Xen finds itself in. >> You can write it for new guests but backporting it to older guests will be a >> huge task. >> >> We will support non-pci for s390, but in order to support Windows and >> older Linux PCI is necessary. >> > > I don't know if I would agree with "necessary". "Easier" perhaps. ;) By > definition once you are PV you are hypervisor aware. Now its just a > matter of plugging in the appropriate plumbing to bridge the hypervisor > to the guest-os. Some might be easier than others, sure. But all > should be extensible to a degree. > > It's "necessary" in a pragmatic sense: we want to deliver drivers that provide features for a wide variety of guests in a reasonable timeframe. And that means no rewriting guest OS infrastructure. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
