On Thu, Dec 10, 2009 at 12:34:38PM +0100, Alexander Graf wrote: > > On 10.12.2009, at 12:28, Muli Ben-Yehuda wrote: > > > On Thu, Dec 10, 2009 at 12:56:56PM +0200, Michael S. Tsirkin wrote: > > > >>> mmio and pio are easy, DMA you'd need an IOMMU for security, or > >>> whatever uio does just for translation, > >> > >> uio currently does not support DMA, but I plan to fix this > > > > With or without an IOMMU? > > > >>> and interrupts you probably get for free from uio. Seems eminently > >>> doable to me. Why you'd want to is another matter :-) > >> > >> The list above ignores the biggest issue: you would have to change > >> TCG code generation to make this work. > > > > Yep, I know nothing about TCG, only looking at this from the device > > interaction side. > > > >> I am not sure this problem is solvable unless host and guest > >> architectures are very similar. > > > > Now you are ignoring the most interesting issue, namely, why would you > > want to solve it? What is the value of device assignment for TCG > > targets? > > Why would you want to emulate a machine at all? ;-) > > Imagine you were a hardware manufacturer who develops some self-made hardware. Now that manufacturer of course has x86 boxes. Chances are pretty low he has PPC ones and imagine we'd ever get MMIO/PCI on S390, he definitely does not have those. > > Still, while developing his driver it'd be really valuable to know that it works on other architectures as well. Especially since he can claim support for architectures he doesn't have himself. At least until the first customer arrives :-). > > While this is a scenario I just made up and don't really have myself, its goal is to illustrate why we shouldn't close doors that don't have to be closed. If TCG doesn't deal with it properly, that doesn't mean we shouldn't work on making the other end compatible. > Well, it does IMO mean that such a project should not be a blocker for passthrough in upstream qemu, after fixing endian-ness issues and generally cleaning up the code. > Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
