[Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Stefan Hajnoczi]

QEMU will apply to the Google Summer of Code
(https://summerofcode.withgoogle.com/) and Outreachy
(https://www.outreachy.org/) open source internship programs again
this year.

Do you want to mentor newcomers beginning open source development in
our community?

Please post your project ideas on the wiki by January 23rd:
https://wiki.qemu.org/Google_Summer_of_Code_2018

Project ideas must:
 * Be doable in 12 weeks by someone fluent in C programming but not
familiar with the codebase.
 * Have a clear scope and few dependencies.
 * Have a high chance of being merged.
 * Consist of smaller steps that can be merged incrementally.

Active QEMU, KVM, and Jailhouse contributors are invited to become
mentors.  Mentoring is a volunteer activity that requires around 5
hours per week to interact with your intern, review code, etc.  GSoC
and Outreachy internships run from May through August.

For background on why QEMU participates in open source internship
programs and how it works, check out my KVM Forum presentation:
https://www.youtube.com/watch?v=xNVCX7YMUL8
https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf

KVM and Jailhouse are invited to participate under the QEMU GSoC
umbrella organization.

Please let me know if you have any questions!

Stefan

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Alistair Francis]

On Tue, Jan 2, 2018 at 12:23 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> QEMU will apply to the Google Summer of Code
> (https://summerofcode.withgoogle.com/) and Outreachy
> (https://www.outreachy.org/) open source internship programs again
> this year.
>
> Do you want to mentor newcomers beginning open source development in
> our community?
>
> Please post your project ideas on the wiki by January 23rd:
> https://wiki.qemu.org/Google_Summer_of_Code_2018
>
> Project ideas must:
>  * Be doable in 12 weeks by someone fluent in C programming but not
> familiar with the codebase.
>  * Have a clear scope and few dependencies.
>  * Have a high chance of being merged.
>  * Consist of smaller steps that can be merged incrementally.
>
> Active QEMU, KVM, and Jailhouse contributors are invited to become
> mentors.  Mentoring is a volunteer activity that requires around 5
> hours per week to interact with your intern, review code, etc.  GSoC
> and Outreachy internships run from May through August.
>
> For background on why QEMU participates in open source internship
> programs and how it works, check out my KVM Forum presentation:
> https://www.youtube.com/watch?v=xNVCX7YMUL8
> https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
>
> KVM and Jailhouse are invited to participate under the QEMU GSoC
> umbrella organization.
>
> Please let me know if you have any questions!

Hey,

Can anyone who has done this before chime in.

What do you think about getting someone to cleanup and improve the GDB
support in QEMU? Would that be the right difficulty of task for a GSoC
project?

Alistair

>
> Stefan
>

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Fam Zheng]

On Tue, 01/09 13:45, Alistair Francis wrote:
> On Tue, Jan 2, 2018 at 12:23 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > QEMU will apply to the Google Summer of Code
> > (https://summerofcode.withgoogle.com/) and Outreachy
> > (https://www.outreachy.org/) open source internship programs again
> > this year.
> >
> > Do you want to mentor newcomers beginning open source development in
> > our community?
> >
> > Please post your project ideas on the wiki by January 23rd:
> > https://wiki.qemu.org/Google_Summer_of_Code_2018
> >
> > Project ideas must:
> >  * Be doable in 12 weeks by someone fluent in C programming but not
> > familiar with the codebase.
> >  * Have a clear scope and few dependencies.
> >  * Have a high chance of being merged.
> >  * Consist of smaller steps that can be merged incrementally.
> >
> > Active QEMU, KVM, and Jailhouse contributors are invited to become
> > mentors.  Mentoring is a volunteer activity that requires around 5
> > hours per week to interact with your intern, review code, etc.  GSoC
> > and Outreachy internships run from May through August.
> >
> > For background on why QEMU participates in open source internship
> > programs and how it works, check out my KVM Forum presentation:
> > https://www.youtube.com/watch?v=xNVCX7YMUL8
> > https://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> >
> > KVM and Jailhouse are invited to participate under the QEMU GSoC
> > umbrella organization.
> >
> > Please let me know if you have any questions!
> 
> Hey,
> 
> Can anyone who has done this before chime in.
> 
> What do you think about getting someone to cleanup and improve the GDB
> support in QEMU? Would that be the right difficulty of task for a GSoC
> project?

Yeah. I don't know much about GDB stub in QEMU but it sounds like a good idea if
the requirements (what exactly to improve) are concrete.  In general, a few
factors to consider are:

* Is it managable for a student who is not familiar with QEMU code but has fair
  proficiency in C and Linux programming?
* Is it roughly 3 months' (full time) amount of work for such a student?
* Is there a mentor that can guide and help (like said above, devote a few hours
  every week in the process, meeting with the student, answering questions and
  reviewing patches)?

Fam

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Stefan Hajnoczi]

On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
> Can anyone who has done this before chime in.
>
> What do you think about getting someone to cleanup and improve the GDB
> support in QEMU? Would that be the right difficulty of task for a GSoC
> project?

There is not enough information to give feedback on whether this
project idea is suitable.  What are the specific tasks you'd like the
student to work on?

In general, I'm sure there are well-defined 12-week project ideas
around the GDB stub.  New features are easy to propose and are usually
well-defined (e.g. implement these commands that are documented in the
GDB protocol documentation).  Cleaning up code is less clear and it
would depend on exactly what needs to be done.  Interns will not have
a background in the QEMU codebase and may not be able to make
judgements about how to structure things, so I would be more careful
about refactoring/cleanup projects.

Please see my talk about QEMU GSoC for guidelines on project ideas:
https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf

Hope this helps,
Stefan

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Alistair Francis]

On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
>> Can anyone who has done this before chime in.
>>
>> What do you think about getting someone to cleanup and improve the GDB
>> support in QEMU? Would that be the right difficulty of task for a GSoC
>> project?
>
> There is not enough information to give feedback on whether this
> project idea is suitable.  What are the specific tasks you'd like the
> student to work on?
>
> In general, I'm sure there are well-defined 12-week project ideas
> around the GDB stub.  New features are easy to propose and are usually
> well-defined (e.g. implement these commands that are documented in the
> GDB protocol documentation).  Cleaning up code is less clear and it
> would depend on exactly what needs to be done.  Interns will not have
> a background in the QEMU codebase and may not be able to make
> judgements about how to structure things, so I would be more careful
> about refactoring/cleanup projects.
>
> Please see my talk about QEMU GSoC for guidelines on project ideas:
> https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
> http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf

That helps a lot, thanks for that.

So for a more concrete solution, how would adding support for multi
CPU support to the GDB server sound?

This would allow GDB debugging for the A53 and the R5 on the Xilinx
ZynqMP for example. This is something we have in the Xilinx tree, but
it is in no state to go upstream and really needs to be re-write to be
upstreamable and more generic.

Alistair

>
> Hope this helps,
> Stefan

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

On Thu, Jan 11, 2018 at 03:25:56PM -0800, Alistair Francis wrote:
> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
> >> Can anyone who has done this before chime in.
> >>
> >> What do you think about getting someone to cleanup and improve the GDB
> >> support in QEMU? Would that be the right difficulty of task for a GSoC
> >> project?
> >
> > There is not enough information to give feedback on whether this
> > project idea is suitable.  What are the specific tasks you'd like the
> > student to work on?
> >
> > In general, I'm sure there are well-defined 12-week project ideas
> > around the GDB stub.  New features are easy to propose and are usually
> > well-defined (e.g. implement these commands that are documented in the
> > GDB protocol documentation).  Cleaning up code is less clear and it
> > would depend on exactly what needs to be done.  Interns will not have
> > a background in the QEMU codebase and may not be able to make
> > judgements about how to structure things, so I would be more careful
> > about refactoring/cleanup projects.
> >
> > Please see my talk about QEMU GSoC for guidelines on project ideas:
> > https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
> > http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> 
> That helps a lot, thanks for that.
> 
> So for a more concrete solution, how would adding support for multi
> CPU support to the GDB server sound?
> 
> This would allow GDB debugging for the A53 and the R5 on the Xilinx
> ZynqMP for example. This is something we have in the Xilinx tree, but
> it is in no state to go upstream and really needs to be re-write to be
> upstreamable and more generic.

Excellent.  Then they'll already have an idea of "how" it can be
achieved but have the freedom to write code that is most suitable for
upstream.  That is a good starting point for a project.

Here is the project idea template:

=== TITLE ===

 '''Summary:''' Short description of the project

 Detailed description of the project.

 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites

 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

Once you have written down the project idea, please post it under
Internships/ProjectIdeas/MultiCPUGDBStub and then add it to the
Google_Summer_of_Code_2018 wiki page using the
"{{:Internships/ProjectIdeas/MultiCPUGDBStub}}" inlining syntax.

Or if you prefer, just reply with the project idea to this email and
I'll post it on the wiki for you.

Can you think of a co-mentor who would be willing to participate?  It
makes internships easier when there are multiple mentors - less stress
for mentors, faster communication for students.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Alistair Francis]

On Mon, Jan 15, 2018 at 4:59 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Thu, Jan 11, 2018 at 03:25:56PM -0800, Alistair Francis wrote:
>> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> > On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
>> >> Can anyone who has done this before chime in.
>> >>
>> >> What do you think about getting someone to cleanup and improve the GDB
>> >> support in QEMU? Would that be the right difficulty of task for a GSoC
>> >> project?
>> >
>> > There is not enough information to give feedback on whether this
>> > project idea is suitable.  What are the specific tasks you'd like the
>> > student to work on?
>> >
>> > In general, I'm sure there are well-defined 12-week project ideas
>> > around the GDB stub.  New features are easy to propose and are usually
>> > well-defined (e.g. implement these commands that are documented in the
>> > GDB protocol documentation).  Cleaning up code is less clear and it
>> > would depend on exactly what needs to be done.  Interns will not have
>> > a background in the QEMU codebase and may not be able to make
>> > judgements about how to structure things, so I would be more careful
>> > about refactoring/cleanup projects.
>> >
>> > Please see my talk about QEMU GSoC for guidelines on project ideas:
>> > https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
>> > http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
>>
>> That helps a lot, thanks for that.
>>
>> So for a more concrete solution, how would adding support for multi
>> CPU support to the GDB server sound?
>>
>> This would allow GDB debugging for the A53 and the R5 on the Xilinx
>> ZynqMP for example. This is something we have in the Xilinx tree, but
>> it is in no state to go upstream and really needs to be re-write to be
>> upstreamable and more generic.
>
> Excellent.  Then they'll already have an idea of "how" it can be
> achieved but have the freedom to write code that is most suitable for
> upstream.  That is a good starting point for a project.
>
> Here is the project idea template:
>
> === TITLE ===
>
>  '''Summary:''' Short description of the project
>
>  Detailed description of the project.
>
>  '''Links:'''
>  * Wiki links to relevant material
>  * External links to mailing lists or web sites
>
>  '''Details:'''
>  * Skill level: beginner or intermediate or advanced
>  * Language: C
>  * Mentor: Email address and IRC nick
>  * Suggested by: Person who suggested the idea
>
> Once you have written down the project idea, please post it under
> Internships/ProjectIdeas/MultiCPUGDBStub and then add it to the
> Google_Summer_of_Code_2018 wiki page using the
> "{{:Internships/ProjectIdeas/MultiCPUGDBStub}}" inlining syntax.
>
> Or if you prefer, just reply with the project idea to this email and
> I'll post it on the wiki for you.
>
> Can you think of a co-mentor who would be willing to participate?  It
> makes internships easier when there are multiple mentors - less stress
> for mentors, faster communication for students.

Yep, here is my proposal. I don't have wiki access, so I can't add it myself.

I think Philippe would be a good co-mentor, if he is happy to. I am
also welcome to mentor other ideas, it doesn't have to be this one.

=== Multi-CPU cluster support for GDB server in QEMU ===

There are many examples in modern computing where multiple CPU
clusters are grouped together in a single SoC. This is common in the
ARM world especially. There are numerous examples such as ARM's
big.LITTLE implementations and Xilinx's 4xA53s and 2xR5s on the ZynqMP
SoC. The goal of this task is to add support to the GDB server to
allow users to debug across these clusters.

This is another step towards single binary QEMU as well.

 Detailed description of the project.

Xilinx has an out of tree implementation that can be used as a
starting point. Work will need to be done on top of this to prepare it
for upstream submission and to ensure the implementation is more
generic.

This will mostly involve extending GDB server to tell GDB about
different architectures and then allow the user to swap between them.

The Xilinx implementation can be seen here:
https://github.com/Xilinx/qemu/blob/master/gdbstub.c
There has been some steps in preparing the work to go upstream, which
can be seen here:
https://github.com/Xilinx/qemu/tree/mainline/alistair/gdb

 '''Details:'''
 * Skill level: advanced
 * Language: C
 * Mentor: alistair23@gmail.com, Philippe?
 * Suggested by: Alistair Francis

>
> Stefan

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 5094 bytes --]

On Wed, Feb 14, 2018 at 11:00:36AM -0800, Alistair Francis wrote:
> On Mon, Jan 15, 2018 at 4:59 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > On Thu, Jan 11, 2018 at 03:25:56PM -0800, Alistair Francis wrote:
> >> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >> > On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
> >> >> Can anyone who has done this before chime in.
> >> >>
> >> >> What do you think about getting someone to cleanup and improve the GDB
> >> >> support in QEMU? Would that be the right difficulty of task for a GSoC
> >> >> project?
> >> >
> >> > There is not enough information to give feedback on whether this
> >> > project idea is suitable.  What are the specific tasks you'd like the
> >> > student to work on?
> >> >
> >> > In general, I'm sure there are well-defined 12-week project ideas
> >> > around the GDB stub.  New features are easy to propose and are usually
> >> > well-defined (e.g. implement these commands that are documented in the
> >> > GDB protocol documentation).  Cleaning up code is less clear and it
> >> > would depend on exactly what needs to be done.  Interns will not have
> >> > a background in the QEMU codebase and may not be able to make
> >> > judgements about how to structure things, so I would be more careful
> >> > about refactoring/cleanup projects.
> >> >
> >> > Please see my talk about QEMU GSoC for guidelines on project ideas:
> >> > https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
> >> > http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> >>
> >> That helps a lot, thanks for that.
> >>
> >> So for a more concrete solution, how would adding support for multi
> >> CPU support to the GDB server sound?
> >>
> >> This would allow GDB debugging for the A53 and the R5 on the Xilinx
> >> ZynqMP for example. This is something we have in the Xilinx tree, but
> >> it is in no state to go upstream and really needs to be re-write to be
> >> upstreamable and more generic.
> >
> > Excellent.  Then they'll already have an idea of "how" it can be
> > achieved but have the freedom to write code that is most suitable for
> > upstream.  That is a good starting point for a project.
> >
> > Here is the project idea template:
> >
> > === TITLE ===
> >
> >  '''Summary:''' Short description of the project
> >
> >  Detailed description of the project.
> >
> >  '''Links:'''
> >  * Wiki links to relevant material
> >  * External links to mailing lists or web sites
> >
> >  '''Details:'''
> >  * Skill level: beginner or intermediate or advanced
> >  * Language: C
> >  * Mentor: Email address and IRC nick
> >  * Suggested by: Person who suggested the idea
> >
> > Once you have written down the project idea, please post it under
> > Internships/ProjectIdeas/MultiCPUGDBStub and then add it to the
> > Google_Summer_of_Code_2018 wiki page using the
> > "{{:Internships/ProjectIdeas/MultiCPUGDBStub}}" inlining syntax.
> >
> > Or if you prefer, just reply with the project idea to this email and
> > I'll post it on the wiki for you.
> >
> > Can you think of a co-mentor who would be willing to participate?  It
> > makes internships easier when there are multiple mentors - less stress
> > for mentors, faster communication for students.
> 
> Yep, here is my proposal. I don't have wiki access, so I can't add it myself.
> 
> I think Philippe would be a good co-mentor, if he is happy to. I am
> also welcome to mentor other ideas, it doesn't have to be this one.

Paolo and Peter, could you please review this project idea, mainly to
see if this is likely to be mergeable (uncontroversial).

Thanks!

> === Multi-CPU cluster support for GDB server in QEMU ===
> 
> There are many examples in modern computing where multiple CPU
> clusters are grouped together in a single SoC. This is common in the
> ARM world especially. There are numerous examples such as ARM's
> big.LITTLE implementations and Xilinx's 4xA53s and 2xR5s on the ZynqMP
> SoC. The goal of this task is to add support to the GDB server to
> allow users to debug across these clusters.
> 
> This is another step towards single binary QEMU as well.
> 
>  Detailed description of the project.
> 
> Xilinx has an out of tree implementation that can be used as a
> starting point. Work will need to be done on top of this to prepare it
> for upstream submission and to ensure the implementation is more
> generic.
> 
> This will mostly involve extending GDB server to tell GDB about
> different architectures and then allow the user to swap between them.
> 
> The Xilinx implementation can be seen here:
> https://github.com/Xilinx/qemu/blob/master/gdbstub.c
> There has been some steps in preparing the work to go upstream, which
> can be seen here:
> https://github.com/Xilinx/qemu/tree/mainline/alistair/gdb
> 
>  '''Details:'''
>  * Skill level: advanced
>  * Language: C
>  * Mentor: alistair23@gmail.com, Philippe?
>  * Suggested by: Alistair Francis
> 
> >
> > Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On 20/02/2018 11:36, Stefan Hajnoczi wrote:
> === Multi-CPU cluster support for GDB server in QEMU ===
> 
> There are many examples in modern computing where multiple CPU
> clusters are grouped together in a single SoC. This is common in the
> ARM world especially. There are numerous examples such as ARM's
> big.LITTLE implementations and Xilinx's 4xA53s and 2xR5s on the ZynqMP
> SoC. The goal of this task is to add support to the GDB server to
> allow users to debug across these clusters.
> 
> This is another step towards single binary QEMU as well.
> 
>  Detailed description of the project.
> 
> Xilinx has an out of tree implementation that can be used as a
> starting point. Work will need to be done on top of this to prepare it
> for upstream submission and to ensure the implementation is more
> generic.
> 
> This will mostly involve extending GDB server to tell GDB about
> different architectures and then allow the user to swap between them.
> 
> The Xilinx implementation can be seen here:
> https://github.com/Xilinx/qemu/blob/master/gdbstub.c
> There has been some steps in preparing the work to go upstream, which
> can be seen here:
> https://github.com/Xilinx/qemu/tree/mainline/alistair/gdb

I agree this is interesting.  Another related idea is to resume the
multi-arch work that Peter Crosthwaite was working on before he left Xilinx.

Paolo


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Alistair Francis]

On Tue, Feb 20, 2018 at 3:13 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 20/02/2018 11:36, Stefan Hajnoczi wrote:
>> === Multi-CPU cluster support for GDB server in QEMU ===
>>
>> There are many examples in modern computing where multiple CPU
>> clusters are grouped together in a single SoC. This is common in the
>> ARM world especially. There are numerous examples such as ARM's
>> big.LITTLE implementations and Xilinx's 4xA53s and 2xR5s on the ZynqMP
>> SoC. The goal of this task is to add support to the GDB server to
>> allow users to debug across these clusters.
>>
>> This is another step towards single binary QEMU as well.
>>
>>  Detailed description of the project.
>>
>> Xilinx has an out of tree implementation that can be used as a
>> starting point. Work will need to be done on top of this to prepare it
>> for upstream submission and to ensure the implementation is more
>> generic.
>>
>> This will mostly involve extending GDB server to tell GDB about
>> different architectures and then allow the user to swap between them.
>>
>> The Xilinx implementation can be seen here:
>> https://github.com/Xilinx/qemu/blob/master/gdbstub.c
>> There has been some steps in preparing the work to go upstream, which
>> can be seen here:
>> https://github.com/Xilinx/qemu/tree/mainline/alistair/gdb
>
> I agree this is interesting.  Another related idea is to resume the
> multi-arch work that Peter Crosthwaite was working on before he left Xilinx.

That would be great! But it seems a little open ended for this type of
thing. Someone doing that will need to touch a large amount of QEMU
code.

Alistair

>
> Paolo
>

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Stefan Hajnoczi]

On Tue, Feb 20, 2018 at 11:13 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 20/02/2018 11:36, Stefan Hajnoczi wrote:
>> === Multi-CPU cluster support for GDB server in QEMU ===
>>
>> There are many examples in modern computing where multiple CPU
>> clusters are grouped together in a single SoC. This is common in the
>> ARM world especially. There are numerous examples such as ARM's
>> big.LITTLE implementations and Xilinx's 4xA53s and 2xR5s on the ZynqMP
>> SoC. The goal of this task is to add support to the GDB server to
>> allow users to debug across these clusters.
>>
>> This is another step towards single binary QEMU as well.
>>
>>  Detailed description of the project.
>>
>> Xilinx has an out of tree implementation that can be used as a
>> starting point. Work will need to be done on top of this to prepare it
>> for upstream submission and to ensure the implementation is more
>> generic.
>>
>> This will mostly involve extending GDB server to tell GDB about
>> different architectures and then allow the user to swap between them.
>>
>> The Xilinx implementation can be seen here:
>> https://github.com/Xilinx/qemu/blob/master/gdbstub.c
>> There has been some steps in preparing the work to go upstream, which
>> can be seen here:
>> https://github.com/Xilinx/qemu/tree/mainline/alistair/gdb
>
> I agree this is interesting.

Thanks!  I have added it to the wiki:

https://wiki.qemu.org/Google_Summer_of_Code_2018#Multi-CPU_cluster_support_for_GDB_server_in_QEMU

Stefan

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Philippe Mathieu-Daudé]

On 02/14/2018 04:00 PM, Alistair Francis wrote:
> On Mon, Jan 15, 2018 at 4:59 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> On Thu, Jan 11, 2018 at 03:25:56PM -0800, Alistair Francis wrote:
>>> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>>> On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
>>>>> Can anyone who has done this before chime in.
>>>>>
>>>>> What do you think about getting someone to cleanup and improve the GDB
>>>>> support in QEMU? Would that be the right difficulty of task for a GSoC
>>>>> project?
>>>>
>>>> There is not enough information to give feedback on whether this
>>>> project idea is suitable.  What are the specific tasks you'd like the
>>>> student to work on?
>>>>
>>>> In general, I'm sure there are well-defined 12-week project ideas
>>>> around the GDB stub.  New features are easy to propose and are usually
>>>> well-defined (e.g. implement these commands that are documented in the
>>>> GDB protocol documentation).  Cleaning up code is less clear and it
>>>> would depend on exactly what needs to be done.  Interns will not have
>>>> a background in the QEMU codebase and may not be able to make
>>>> judgements about how to structure things, so I would be more careful
>>>> about refactoring/cleanup projects.
>>>>
>>>> Please see my talk about QEMU GSoC for guidelines on project ideas:
>>>> https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
>>>> http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
>>>
>>> That helps a lot, thanks for that.
>>>
>>> So for a more concrete solution, how would adding support for multi
>>> CPU support to the GDB server sound?
>>>
>>> This would allow GDB debugging for the A53 and the R5 on the Xilinx
>>> ZynqMP for example. This is something we have in the Xilinx tree, but
>>> it is in no state to go upstream and really needs to be re-write to be
>>> upstreamable and more generic.
>>
>> Excellent.  Then they'll already have an idea of "how" it can be
>> achieved but have the freedom to write code that is most suitable for
>> upstream.  That is a good starting point for a project.
>>
>> Here is the project idea template:
>>
>> === TITLE ===
>>
>>  '''Summary:''' Short description of the project
>>
>>  Detailed description of the project.
>>
>>  '''Links:'''
>>  * Wiki links to relevant material
>>  * External links to mailing lists or web sites
>>
>>  '''Details:'''
>>  * Skill level: beginner or intermediate or advanced
>>  * Language: C
>>  * Mentor: Email address and IRC nick
>>  * Suggested by: Person who suggested the idea
>>
>> Once you have written down the project idea, please post it under
>> Internships/ProjectIdeas/MultiCPUGDBStub and then add it to the
>> Google_Summer_of_Code_2018 wiki page using the
>> "{{:Internships/ProjectIdeas/MultiCPUGDBStub}}" inlining syntax.
>>
>> Or if you prefer, just reply with the project idea to this email and
>> I'll post it on the wiki for you.
>>
>> Can you think of a co-mentor who would be willing to participate?  It
>> makes internships easier when there are multiple mentors - less stress
>> for mentors, faster communication for students.
> 
> Yep, here is my proposal. I don't have wiki access, so I can't add it myself.
> 
> I think Philippe would be a good co-mentor, if he is happy to. I am
> also welcome to mentor other ideas, it doesn't have to be this one.

I'm very happy to co-mentor with Alistair, I can manage at least 2h/w on it.

> 
> === Multi-CPU cluster support for GDB server in QEMU ===
> 
> There are many examples in modern computing where multiple CPU
> clusters are grouped together in a single SoC. This is common in the
> ARM world especially. There are numerous examples such as ARM's
> big.LITTLE implementations and Xilinx's 4xA53s and 2xR5s on the ZynqMP
> SoC. The goal of this task is to add support to the GDB server to
> allow users to debug across these clusters.
> 
> This is another step towards single binary QEMU as well.
> 
>  Detailed description of the project.
> 
> Xilinx has an out of tree implementation that can be used as a
> starting point. Work will need to be done on top of this to prepare it
> for upstream submission and to ensure the implementation is more
> generic.
> 
> This will mostly involve extending GDB server to tell GDB about
> different architectures and then allow the user to swap between them.
> 
> The Xilinx implementation can be seen here:
> https://github.com/Xilinx/qemu/blob/master/gdbstub.c
> There has been some steps in preparing the work to go upstream, which
> can be seen here:
> https://github.com/Xilinx/qemu/tree/mainline/alistair/gdb
> 
>  '''Details:'''
>  * Skill level: advanced
>  * Language: C
>  * Mentor: alistair23@gmail.com, Philippe?
>  * Suggested by: Alistair Francis
> 
>>
>> Stefan

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 3923 bytes --]

On Tue, Feb 27, 2018 at 08:54:11PM -0300, Philippe Mathieu-Daudé wrote:
> On 02/14/2018 04:00 PM, Alistair Francis wrote:
> > On Mon, Jan 15, 2018 at 4:59 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >> On Thu, Jan 11, 2018 at 03:25:56PM -0800, Alistair Francis wrote:
> >>> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >>>> On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
> >>>>> Can anyone who has done this before chime in.
> >>>>>
> >>>>> What do you think about getting someone to cleanup and improve the GDB
> >>>>> support in QEMU? Would that be the right difficulty of task for a GSoC
> >>>>> project?
> >>>>
> >>>> There is not enough information to give feedback on whether this
> >>>> project idea is suitable.  What are the specific tasks you'd like the
> >>>> student to work on?
> >>>>
> >>>> In general, I'm sure there are well-defined 12-week project ideas
> >>>> around the GDB stub.  New features are easy to propose and are usually
> >>>> well-defined (e.g. implement these commands that are documented in the
> >>>> GDB protocol documentation).  Cleaning up code is less clear and it
> >>>> would depend on exactly what needs to be done.  Interns will not have
> >>>> a background in the QEMU codebase and may not be able to make
> >>>> judgements about how to structure things, so I would be more careful
> >>>> about refactoring/cleanup projects.
> >>>>
> >>>> Please see my talk about QEMU GSoC for guidelines on project ideas:
> >>>> https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
> >>>> http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> >>>
> >>> That helps a lot, thanks for that.
> >>>
> >>> So for a more concrete solution, how would adding support for multi
> >>> CPU support to the GDB server sound?
> >>>
> >>> This would allow GDB debugging for the A53 and the R5 on the Xilinx
> >>> ZynqMP for example. This is something we have in the Xilinx tree, but
> >>> it is in no state to go upstream and really needs to be re-write to be
> >>> upstreamable and more generic.
> >>
> >> Excellent.  Then they'll already have an idea of "how" it can be
> >> achieved but have the freedom to write code that is most suitable for
> >> upstream.  That is a good starting point for a project.
> >>
> >> Here is the project idea template:
> >>
> >> === TITLE ===
> >>
> >>  '''Summary:''' Short description of the project
> >>
> >>  Detailed description of the project.
> >>
> >>  '''Links:'''
> >>  * Wiki links to relevant material
> >>  * External links to mailing lists or web sites
> >>
> >>  '''Details:'''
> >>  * Skill level: beginner or intermediate or advanced
> >>  * Language: C
> >>  * Mentor: Email address and IRC nick
> >>  * Suggested by: Person who suggested the idea
> >>
> >> Once you have written down the project idea, please post it under
> >> Internships/ProjectIdeas/MultiCPUGDBStub and then add it to the
> >> Google_Summer_of_Code_2018 wiki page using the
> >> "{{:Internships/ProjectIdeas/MultiCPUGDBStub}}" inlining syntax.
> >>
> >> Or if you prefer, just reply with the project idea to this email and
> >> I'll post it on the wiki for you.
> >>
> >> Can you think of a co-mentor who would be willing to participate?  It
> >> makes internships easier when there are multiple mentors - less stress
> >> for mentors, faster communication for students.
> > 
> > Yep, here is my proposal. I don't have wiki access, so I can't add it myself.
> > 
> > I think Philippe would be a good co-mentor, if he is happy to. I am
> > also welcome to mentor other ideas, it doesn't have to be this one.
> 
> I'm very happy to co-mentor with Alistair, I can manage at least 2h/w on it.

I've added you to the wiki page.

BTW, if you and Alistair don't have wiki accounts yet, let me know and
I'll set it up for you.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[David Hildenbrand]

On 12.01.2018 00:25, Alistair Francis wrote:
> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
>>> Can anyone who has done this before chime in.
>>>
>>> What do you think about getting someone to cleanup and improve the GDB
>>> support in QEMU? Would that be the right difficulty of task for a GSoC
>>> project?

Don't understand that sentence. We already support multiple CPUs
(represented and switchable just like threads in GDB), no?

An interesting thing to look at could be tracepoint support in GDB.

>>
>> There is not enough information to give feedback on whether this
>> project idea is suitable.  What are the specific tasks you'd like the
>> student to work on?
>>
>> In general, I'm sure there are well-defined 12-week project ideas
>> around the GDB stub.  New features are easy to propose and are usually
>> well-defined (e.g. implement these commands that are documented in the
>> GDB protocol documentation).  Cleaning up code is less clear and it
>> would depend on exactly what needs to be done.  Interns will not have
>> a background in the QEMU codebase and may not be able to make
>> judgements about how to structure things, so I would be more careful
>> about refactoring/cleanup projects.
>>
>> Please see my talk about QEMU GSoC for guidelines on project ideas:
>> https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
>> http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
> 
> That helps a lot, thanks for that.
> 
> So for a more concrete solution, how would adding support for multi
> CPU support to the GDB server sound?
> 
> This would allow GDB debugging for the A53 and the R5 on the Xilinx
> ZynqMP for example. This is something we have in the Xilinx tree, but
> it is in no state to go upstream and really needs to be re-write to be
> upstreamable and more generic.
> 
> Alistair
> 
>>
>> Hope this helps,
>> Stefan


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] Call for GSoC & Outreachy 2018 mentors & project ideas

[Alistair Francis]

On Thu, Jan 18, 2018 at 8:49 AM, David Hildenbrand <david@redhat.com> wrote:
> On 12.01.2018 00:25, Alistair Francis wrote:
>> On Wed, Jan 10, 2018 at 4:52 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>> On Tue, Jan 9, 2018 at 9:45 PM, Alistair Francis <alistair23@gmail.com> wrote:
>>>> Can anyone who has done this before chime in.
>>>>
>>>> What do you think about getting someone to cleanup and improve the GDB
>>>> support in QEMU? Would that be the right difficulty of task for a GSoC
>>>> project?
>
> Don't understand that sentence. We already support multiple CPUs
> (represented and switchable just like threads in GDB), no?

We support multiple of the same CPU, such as multiple cores. What we
don't support is multiple of different types of CPUs. Something like
ARMs bit.LITTLE or Xilinx's 4xA53s and 2xR5s.

Alistair

>
> An interesting thing to look at could be tracepoint support in GDB.
>
>>>
>>> There is not enough information to give feedback on whether this
>>> project idea is suitable.  What are the specific tasks you'd like the
>>> student to work on?
>>>
>>> In general, I'm sure there are well-defined 12-week project ideas
>>> around the GDB stub.  New features are easy to propose and are usually
>>> well-defined (e.g. implement these commands that are documented in the
>>> GDB protocol documentation).  Cleaning up code is less clear and it
>>> would depend on exactly what needs to be done.  Interns will not have
>>> a background in the QEMU codebase and may not be able to make
>>> judgements about how to structure things, so I would be more careful
>>> about refactoring/cleanup projects.
>>>
>>> Please see my talk about QEMU GSoC for guidelines on project ideas:
>>> https://www.youtube.com/watch?v=xNVCX7YMUL8&t=19m11s
>>> http://vmsplice.net/~stefan/stefanha-kvm-forum-2016.pdf
>>
>> That helps a lot, thanks for that.
>>
>> So for a more concrete solution, how would adding support for multi
>> CPU support to the GDB server sound?
>>
>> This would allow GDB debugging for the A53 and the R5 on the Xilinx
>> ZynqMP for example. This is something we have in the Xilinx tree, but
>> it is in no state to go upstream and really needs to be re-write to be
>> upstreamable and more generic.
>>
>> Alistair
>>
>>>
>>> Hope this helps,
>>> Stefan
>
>
> --
>
> Thanks,
>
> David / dhildenb