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

[Valentine Sinitsyn]

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