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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
