On Sun, Sep 30, 2012 at 11:17 AM, Avi Kivity <a...@redhat.com> wrote: > 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.
The model (opaque IOMMU handle + ESP/Lance specific accessors) could be improved much, it predates all IOMMU discussions. Just grab any ISO (preferably a sparc32 one), try booting. If it fails, there's a problem because IOMMU is enabled by OpenBIOS. > >> >>> >>>> 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? That's OK, I'm not opposing it. > > 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