Re: [Qemu-devel] Aspirant for AMD IOMMU emulation project for Outreachy

[Valentine Sinitsyn <valentine.sinitsyn@gmail.com>]

On 09.09.2015 11:54, David kiarie wrote:
...snip...
>>> Most recent work is here
>>> http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg02759.html
>>> . Most the code is Qemu device boilerplate(so there are a ton of
>>> things to add but I wanted to have the existing work merged first).
>>> The IOMMU just offers basic translation. From Valentine's previous
>>> comments, I only have a few minor issues to fix in the code.
>>
>> This is a bit of off-topic here, but I'd argue they are minor. There are
>> some inaccuracies in emulation, and IOMMU itself is rather feature-limited,
>> just as you said. I doubt I'd be able to run current Jailhouse
>> implementation on it, for instance, albeit I haven't tried. So, your patches
>> are good start, but I feel there's a somewhat long way before they actually
>> get merged.
>
> Yep, that is possible. For instance, you were insisting on 'cache'
> implemention ;) which IMHO, is optional but could be a good project
> start.
The thing that worried me most is how you handle invalid Device Table 
entries, and that most bits in control/status registers are actually 
no-op. And I don't insist on cache implementation, just make sure there 
is a way to invalidate the configuration. Maybe I overlooked something 
and you already do it?

Let's discuss it not in this thread but where your patch is.

>
>>
>> So, in short: there are still tasks to be done in AMD IOMMU emulation
>> project. I also feel it's possible to parallelize them so David and Rita can
>> continue without stepping at each other toe, if the program permits it.
>>
>>> I obviously do other things alongside :-D this project but given some
>>> time I could get the code merged and continue to add other features.
>>>
>>>>
>>>> For the Outreachy program, just like for GSoC, we need to find a good
>>>> topic that is sufficiently clear defined on program start and not worked
>>>> on in parallel during the runtime. There are still a number of open
>>>> topics in this area, e.g. around the older Intel IOMMU model (error
>>>> handling and reporting, interrupt remapping), or maybe we find something
>>>> different - depends on your interests and experiences. Do you have any
>>>> public references to your previous work?
>>>>
>>>> Then I'd suggest to schedule an irc meeting to discuss your interests
>>>> and background a bit further and consider available options.
>>>>
>>>> Jan
>>>>
>>
>> Regards,
>> Valentine

Valentine