qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [big lock] Discussion about the convention of device's


From: Blue Swirl
Subject: Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock
Date: Sun, 30 Sep 2012 11:04:23 +0000

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.

>
>> 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.

>
> --
> error compiling committee.c: too many arguments to function
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]