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

[Jan Kiszka <jan.kiszka@web.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-09-11 08:50, Jan Kiszka wrote:
> Hi Rita,
> 
> [CC'ing Andrew due to overlap with split irqchip topic]
> 
> On 2015-09-09 19:41, Rita Sinha wrote:
>> Hi Jan,
>> 
>>> 
>>> Most likely than not you'll work on the Intel IOMMU and I would
>>> suggest, if you wish to get your feet dirty, just start right
>>> away with the Intel IOMMU (In which case Jan could direct you
>>> better) instead of the AMD one.
>>> 
>> 
>> As suggested by David, I would request you to guide me as to how 
>> to get started with Intel IOMMU.
>> 
> 
> You can find the basic problem description and some links here:
> 
> http://wiki.qemu.org/Google_Summer_of_Code_2015#VT-d_interrupt_emulation_with_KVM_support
>
>
> 
Who much do you know about IOMMUs and interrupt remapping in
> general? The spec may provide a certain introduction to the topic, 
> but it also quickly dives into details. Let me know where you see 
> gaps to build up a better understanding of the topic.
> 
> Implementation-wise, you could start off with the existing 
> interrupt remapping patches and look into the missing error 
> reporting for IR on that basis. I've just rebased and pushed a new 
> version. Error reporting

Oh, another way to approach the topic could be developing unit tests
for the IOMMU. However, I'm not the expert on the related framework
but we'll find one if you like to look into this. You find such tests
in the, well, tests/ subdirectory, for various QEMU aspects in fact.

Jan

> is currently done in form of plain printf. The correct behaviour is
> described in the spec. Feel free to nag me with questions on how 
> things work around interrupt remapping in general and its QEMU 
> integration in particular.
> 
> The goal is to get this upstream eventually. So the current design 
> needs to be prepared for submission, reviewed by subsystem 
> maintainer, and then possibly reworked based on their feedback. We 
> will also need some command line switch (machine property, like 
> iommu=on) to control the availability of IR because the original 
> Q35 chipset didn't include this feature.
> 
> But there is also the aim to integrate it with KVM support, and 
> that's why I'm CC'ing Andrew. At Google, they are currently
> working on QEMU patches for their split KVM irqchip model. This
> will push the IOAPIC into QEMU hands, even when KVM in-kernel APIC 
> acceleration is used. And that will allow IR to be installed 
> easily, without any KVM kernel-side changes.
> 
> Andrew, what is the status of your QEMU patches? Are there chances 
> to preview them in order to asses if and how much integration work 
> is needed for interrupt remapping?
> 
> Rita, you probably noticed that this is no beginner's task, both 
> regarding the hardware background as well as the QEMU subsystems. 
> You have worked with several low-level software components before 
> and have some QEMU experience, so this topic could be a good match 
> for you. Still, if you have doubts after looking into details, let 
> me know so that we can discuss them.
> 
> Best regards, Jan
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlXye3gACgkQitSsb3rl5xRW7wCdEOFPusbslxAjrAYUmka1ta4T
rAsAnioAseNIayFW8C1Faeztb3jRC7PQ
=NtRT
-----END PGP SIGNATURE-----