On 09/30/2012 01:04 PM, Blue Swirl wrote: > On Sun, Sep 30, 2012 at 8:13 AM, Avi Kivity <a...@redhat.com> wrote: >> On 09/29/2012 11:20 AM, liu ping fan wrote: >>> >>> Do we have iommus in qemu now, >> >> We do, but they're hacked into the scsi layer, see hw/sun4m_iommu.c. I >> don't know if it's a standalone iommu on real hardware or whether it is >> part of the HBA. > > It's standalone or even part of CPU (some uniprocessor systems). IOMMU > sits between memory and SBus, so all SBus devices (currently only ESP > and Lance) use it.
So, the current modelling is incorrect? I'd like to fix it as a way of getting proper iommu modelling, but I don't know how it should be done, or how to test it. > >> >>> since there are no separate phys_maps >>> for real address and dev's virt address, and I think the iommu is only >>> needed by host, not guest, so need not emulated by qemu. >> >> Eventually we will emulate iommus for x86 too, so we need to consider them. >> >>> If no, we >>> can just reject the nested DMA, and the c_p_m_rw() can only be nested >>> once, so if introduce a wrapper for c_p_m_rw(), we can avoid >>> recursive big lock, right? >> >> Don't we need that for other reasons? If not, we can drop it for now. > > I don't think nested DMA is ever needed, it would be pretty obscure > feature and it would need a pretty heavy implementation (recursion) in > a real HW IOMMU. In theory the translated address may map to MMIO but > that's different. Sure. But if we can get a model that works for everything at no extra cost, then why not? btw, the model of 'either we take the big lock recusrsively, or we drop the local lock before issuing dma' seems to cover nested iommus with any mix of big locks and little locks. -- error compiling committee.c: too many arguments to function
