[Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Merten Sach]

Hi,

I'm interested in participating in this years edition of Google Summer of Code.

I the last years I did a lot of work on hypervisors. Currently I'm working with a hypervisor on ARM
for my master degree. On previous projects using x86, the ability to do a quick debugging run using
QEMU with SVM support helped me a lot. However, the ARM version of QEMU is still lacking this useful
feature.

Initially I wanted to propose the implementation of ARMv7 virtualization extensions. I know this is
not supported at the moment. Also based on the documentation I found I thought it is still untouched.
However, when I looked at git log I saw that there is some preparation to include EL2 support (LPAE,
nested paging preparation, etc).
Is there demand for a GSoC project to further ARM virtualization extension support?

I have some experience with the QEMU codebase. In my bachelor thesis I adopted QEMU (1.0 war stable
at the time) to execute guests deterministically (in particular SMP guests).  However, this work was
never submitted upstream due to the different focus.

I appreciate any comments.

Best regards
Merten

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Peter Maydell]

On 20 March 2015 at 17:25, Merten Sach <msach@mailbox.tu-berlin.de> wrote:
> I'm interested in participating in this years edition of Google Summer of Code.

> Initially I wanted to propose the implementation of ARMv7
> virtualization extensions. I know this is not supported at the moment.
> Also based on the documentation I found I thought it is still untouched.
> However, when I looked at git log I saw that there is some preparation
> to include EL2 support (LPAE, nested paging preparation, etc).

Yes, we have put in some initial foundational changes but
actual support is still missing. Edgar, can you remind me
whether you have some pending patches for EL2 support still?

> Is there demand for a GSoC project to further ARM virtualization
> extension support?

We would certainly like to see virtualization emulation
supported in upstream QEMU. I think my main areas of
concern would be:
 * working with any existing code that Edgar has up his sleeve
 * having a project plan that divides the work up into small
   but coherent chunks that can be landed upstream incrementally
   (to avoid the failure mode of "work all summer but don't
   get it finished, and so don't have anything concrete
   to show for it at the end")

thanks
-- PMM

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Sergey Fedorov]

On 20.03.2015 20:44, Peter Maydell wrote:
> On 20 March 2015 at 17:25, Merten Sach <msach@mailbox.tu-berlin.de> wrote:
>> I'm interested in participating in this years edition of Google Summer of Code.
>> Initially I wanted to propose the implementation of ARMv7
>> virtualization extensions. I know this is not supported at the moment.
>> Also based on the documentation I found I thought it is still untouched.
>> However, when I looked at git log I saw that there is some preparation
>> to include EL2 support (LPAE, nested paging preparation, etc).
> Yes, we have put in some initial foundational changes but
> actual support is still missing. Edgar, can you remind me
> whether you have some pending patches for EL2 support still?
>
>> Is there demand for a GSoC project to further ARM virtualization
>> extension support?
> We would certainly like to see virtualization emulation
> supported in upstream QEMU. I think my main areas of
> concern would be:
>  * working with any existing code that Edgar has up his sleeve
>  * having a project plan that divides the work up into small
>    but coherent chunks that can be landed upstream incrementally
>    (to avoid the failure mode of "work all summer but don't
>    get it finished, and so don't have anything concrete
>    to show for it at the end")
>
> thanks
> -- PMM
>

Hi!

I am currently working on AArch64 EL2 support. There is a plan to submit
the changes to the community. Merten, IIUYC, you are going to support
only AArch32 EL2?

Best regards,
Sergey

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Edgar E. Iglesias]

On Sat, Mar 21, 2015 at 06:16:54AM +0300, Sergey Fedorov wrote:
> On 20.03.2015 20:44, Peter Maydell wrote:
> > On 20 March 2015 at 17:25, Merten Sach <msach@mailbox.tu-berlin.de> wrote:
> >> I'm interested in participating in this years edition of Google Summer of Code.
> >> Initially I wanted to propose the implementation of ARMv7
> >> virtualization extensions. I know this is not supported at the moment.
> >> Also based on the documentation I found I thought it is still untouched.
> >> However, when I looked at git log I saw that there is some preparation
> >> to include EL2 support (LPAE, nested paging preparation, etc).
> > Yes, we have put in some initial foundational changes but
> > actual support is still missing. Edgar, can you remind me
> > whether you have some pending patches for EL2 support still?
> >
> >> Is there demand for a GSoC project to further ARM virtualization
> >> extension support?
> > We would certainly like to see virtualization emulation
> > supported in upstream QEMU. I think my main areas of
> > concern would be:
> >  * working with any existing code that Edgar has up his sleeve
> >  * having a project plan that divides the work up into small
> >    but coherent chunks that can be landed upstream incrementally
> >    (to avoid the failure mode of "work all summer but don't
> >    get it finished, and so don't have anything concrete
> >    to show for it at the end")
> >
> > thanks
> > -- PMM
> >
> 
> Hi!
> 
> I am currently working on AArch64 EL2 support. There is a plan to submit
> the changes to the community. Merten, IIUYC, you are going to support
> only AArch32 EL2?
> 

Hi all,

Sergey, that's good to hear!

Peter, Yes I have quite a bit of patch material but unfortunately a lot of
it is not in a state for upstreaming. I know I've promised to clean
it up and submit more but I have not been able to find time for it,
sorry about that...

Patches that I planned to send are around hyp timers, misc bugfixes
here and there and maybe the GIC virt extensions.

The 2 stage MMU code I have is shamefully ugly but it kind of works
so it is useful for understanding some of the problems that need to be
solved. (works well enough to boot XEN and KVM guests).

Sergey and myself communicated a bit off-list a while back ago
and he expressed interest in AArch64 EL2 and my code. Sergey, it would be
very interesting to hear more details on how you are doing on that?

Cheers,
Edgar

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Sergey Fedorov]

On 20.03.2015 21:49, Edgar E. Iglesias wrote:
> Hi all,
>
> Sergey, that's good to hear!
>
> Peter, Yes I have quite a bit of patch material but unfortunately a lot of
> it is not in a state for upstreaming. I know I've promised to clean
> it up and submit more but I have not been able to find time for it,
> sorry about that...
>
> Patches that I planned to send are around hyp timers, misc bugfixes
> here and there and maybe the GIC virt extensions.
>
> The 2 stage MMU code I have is shamefully ugly but it kind of works
> so it is useful for understanding some of the problems that need to be
> solved. (works well enough to boot XEN and KVM guests).
>
> Sergey and myself communicated a bit off-list a while back ago
> and he expressed interest in AArch64 EL2 and my code. Sergey, it would be
> very interesting to hear more details on how you are doing on that?
>
> Cheers,
> Edgar

Hi Edgar,

I successfully reproduced your results with running KVM on your patches.
Then I decided to start implementing the features without looking at
your code so that I can get somewhat different view on how to implement
that. Then I plan to compare my and your code and make a final version.

Now I've got patches that allows to boot Linux kernel with KVM enabled.
So KVM initialization is happy. Basically, I added some EL2 registers
required by KVM and adjusted page table walk to support EL2 translation
regime. A colleague of mine has prepared a patch to support
virtualization extensions in generic timer.

Before sending patches here, I will do my best to carefully compare my
final code against yours and credit you appropriately in that patches
for any derivatives found. Anyway, do not hesitate to ask questions or
point out any misses in respect of this matter.

Best regards,
Sergey

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Edgar E. Iglesias]

On Sun, Mar 22, 2015 at 07:30:07AM -0700, Sergey Fedorov wrote:
> On 20.03.2015 21:49, Edgar E. Iglesias wrote:
> > Hi all,
> >
> > Sergey, that's good to hear!
> >
> > Peter, Yes I have quite a bit of patch material but unfortunately a lot of
> > it is not in a state for upstreaming. I know I've promised to clean
> > it up and submit more but I have not been able to find time for it,
> > sorry about that...
> >
> > Patches that I planned to send are around hyp timers, misc bugfixes
> > here and there and maybe the GIC virt extensions.
> >
> > The 2 stage MMU code I have is shamefully ugly but it kind of works
> > so it is useful for understanding some of the problems that need to be
> > solved. (works well enough to boot XEN and KVM guests).
> >
> > Sergey and myself communicated a bit off-list a while back ago
> > and he expressed interest in AArch64 EL2 and my code. Sergey, it would be
> > very interesting to hear more details on how you are doing on that?
> >
> > Cheers,
> > Edgar
> 
> Hi Edgar,
> 
> I successfully reproduced your results with running KVM on your patches.
> Then I decided to start implementing the features without looking at
> your code so that I can get somewhat different view on how to implement
> that. Then I plan to compare my and your code and make a final version.
> 
> Now I've got patches that allows to boot Linux kernel with KVM enabled.
> So KVM initialization is happy. Basically, I added some EL2 registers
> required by KVM and adjusted page table walk to support EL2 translation
> regime. A colleague of mine has prepared a patch to support
> virtualization extensions in generic timer.
> 
> Before sending patches here, I will do my best to carefully compare my
> final code against yours and credit you appropriately in that patches
> for any derivatives found. Anyway, do not hesitate to ask questions or
> point out any misses in respect of this matter.


Thanks Sergey!

Cheers,
Edgar

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Merten Sach]

On 21/03/15 04:16, Sergey Fedorov wrote:
> Hi!
> 
> I am currently working on AArch64 EL2 support. There is a plan to submit
> the changes to the community. Merten, IIUYC, you are going to support
> only AArch32 EL2?
> 
> Best regards,
> Sergey

Hi

Yes, my intention is to focus on AArch32 as I'm more familiar with that
architecture.

Thanks for the insight into the current state. As I understand, some parts of
AArch64 and AArch32 EL2 modes share a some functionality. For example,
* VGIC - compatible
* Exception Routing - different interface but same function
* Pagetable format - implemented with LPAE
* Generic Timer - different interface but same function

Are these assumptions correct? I hope I didn't simplify it to much.

And also: does it make sense to work with your code? Are you planing to commit
the changes before May?

Would someone mentor this project?

Best regards,
Merten

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Sergey Fedorov]

On 23.03.2015 04:29, Merten Sach wrote:
> On 21/03/15 04:16, Sergey Fedorov wrote:
>> Hi!
>>
>> I am currently working on AArch64 EL2 support. There is a plan to submit
>> the changes to the community. Merten, IIUYC, you are going to support
>> only AArch32 EL2?
>>
>> Best regards,
>> Sergey
> Hi
>
> Yes, my intention is to focus on AArch32 as I'm more familiar with that
> architecture.
>
> Thanks for the insight into the current state. As I understand, some parts of
> AArch64 and AArch32 EL2 modes share a some functionality. For example,
> * VGIC - compatible
> * Exception Routing - different interface but same function
> * Pagetable format - implemented with LPAE
> * Generic Timer - different interface but same function
>
> Are these assumptions correct? I hope I didn't simplify it to much.
>
> And also: does it make sense to work with your code? Are you planing to commit
> the changes before May?
>
> Would someone mentor this project?
>
> Best regards,
> Merten
>

Hi,

I didn't investigate the difference between AArch64 and AArch32. But I
believe that AArch64 should be better structured. As of GIC and Generic
Timer, I think you are right.

I plan to start committing it in coherent chunks as soon as I can. And
yes, I hope I finish it before May.

Best regards,
Sergey

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Merten Sach]

On 24/03/15 14:47, Sergey Fedorov wrote:
> On 23.03.2015 04:29, Merten Sach wrote:
>> On 21/03/15 04:16, Sergey Fedorov wrote:
>>> Hi!
>>>
>>> I am currently working on AArch64 EL2 support. There is a plan to submit
>>> the changes to the community. Merten, IIUYC, you are going to support
>>> only AArch32 EL2?
>>>
>>> Best regards,
>>> Sergey
>> Hi
>>
>> Yes, my intention is to focus on AArch32 as I'm more familiar with that
>> architecture.
>>
>> Thanks for the insight into the current state. As I understand, some parts of
>> AArch64 and AArch32 EL2 modes share a some functionality. For example,
>> * VGIC - compatible
>> * Exception Routing - different interface but same function
>> * Pagetable format - implemented with LPAE
>> * Generic Timer - different interface but same function
>>
>> Are these assumptions correct? I hope I didn't simplify it to much.
>>
>> And also: does it make sense to work with your code? Are you planing to commit
>> the changes before May?
>>
>> Would someone mentor this project?
>>
>> Best regards,
>> Merten
>>
> 
> Hi,
> 
> I didn't investigate the difference between AArch64 and AArch32. But I
> believe that AArch64 should be better structured. As of GIC and Generic
> Timer, I think you are right.
> 
> I plan to start committing it in coherent chunks as soon as I can. And
> yes, I hope I finish it before May.
> 
> Best regards,
> Sergey
> 
> 

Hi,

thanks for all your answers.

Sorry that I ask the same question again: would someone mentor this project? I
guess if not it makes no sense to hand in the proposal. :-(

After reading the answers by Sergey and Edgar, I'm unsure if the amount of work
is adequate for 12 weeks. Many AArch32 registers just map flat to their AArch64
counterpart and the function are mostly the same. I got the impression that
mostly fixing interfaces is not enough for GSoC.

Best regards
Merten

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Merten Sach]

On 20/03/15 18:44, Peter Maydell wrote:
>  * having a project plan that divides the work up into small
>    but coherent chunks that can be landed upstream incrementally
>    (to avoid the failure mode of "work all summer but don't
>    get it finished, and so don't have anything concrete
>    to show for it at the end")

Hi,

what is the policy for incomplete specification implementations?
For example, I could imagine implementing mode switches and exception routing
without nested paging (though Sergey already implemented it). This would not be
sufficient to run KVM. However one could test it.

Best regards,
Merten

Re: [Qemu-devel] GSoC Proposal: ARM Virtualization Extensions

[Peter Maydell]

On 23 March 2015 at 11:29, Merten Sach <msach@mailbox.tu-berlin.de> wrote:
> On 20/03/15 18:44, Peter Maydell wrote:
>>  * having a project plan that divides the work up into small
>>    but coherent chunks that can be landed upstream incrementally
>>    (to avoid the failure mode of "work all summer but don't
>>    get it finished, and so don't have anything concrete
>>    to show for it at the end")

> what is the policy for incomplete specification implementations?

Basically if it's a correct implementation of a coherent chunk
of the spec (and wouldn't need to be completely rewritten when
the rest is added) than I'm happy to add it to the codebase.
It's much easier to do code review on smaller parts of the
spec at a time (and it means if there are global observations
in code review you can naturally follow them in code you write
in future, rather than having to change a lot of code you've
already written).

Regarding AArch32 vs AArch64, we don't require support for
both to start with, but in general the approach I've found works
best is to at least be aware of the 64-bit spec as you go along,
so that it's clear how the 64-bit parts will fit in when they're
implemented later.

-- PMM