On Thu, Dec 10, 2009 at 12:09:13PM +0100, Alexander Graf wrote: > > On 10.12.2009, at 11:56, Michael S. Tsirkin wrote: > > > On Thu, Dec 10, 2009 at 12:37:37PM +0200, Muli Ben-Yehuda wrote: > >> On Thu, Dec 10, 2009 at 11:31:01AM +0100, Alexander Graf wrote: > >> > >>>> What do you have in mind for such a rewrite? > >>> > >>> I'd like to see it more well-abstracted and versatile. I don't see > >>> an obvious reason why we shouldn't be able to use a physical device > >>> in a TCG target :-). > >> > >> 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 > > > >> and interrupts you probably > >> get for free from uio. Seems eminently doable to me. Why you'd want to > >> is another matter :-) > >> > >> Cheers, > >> Muli > > > > The list above ignores the biggest issue: you would have to change TCG > > code generation to make this work. > > > > For example, I think a read memory barrier is currently ignored in > > translation, and host CPU will reorder reads. Some drivers might also > > rely on ordering guarantees that depend on CPU cacheline sizes. Atomics > > is another bag of tricks but I expect atomics on a DMA memory are not > > widely used. > > Since we'd use the mmio callbacks for MMIO we'd be strictly ordered, no? > > Alex Not unless you issue appropriate host memory barriers on mmio callbacks (kvm currently uses a lock for this, which has an implicit barrier, but I do not think TCG does this). But even then, it depends on the device, for some devices DMA memory reads/writes might depend on each other. Look at virtio as an example, a real device might have the same semantics. As a simpler example, some devices DMA the following into ring in host memory to signal data available: - valid tag - data length host will read tag, and when it's valid use data length, but e.g. on intel this only works well if these share a cache line, otherwise data read might bypass tag read and you get invalid data. -- MST -- 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
