Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock

[Blue Swirl]

On Sun, Sep 30, 2012 at 11:17 AM, Avi Kivity <address@hidden> wrote:
> On 09/30/2012 01:04 PM, Blue Swirl wrote:
>> On Sun, Sep 30, 2012 at 8:13 AM, Avi Kivity <address@hidden> 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