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  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

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Alistair Francis]

On Tue, Jan 2, 2018 at 12:23 PM, Stefan Hajnoczi  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
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading kernel on Non-root cell in jetson-TX2.

[Gustavo Lima Chaves]

* Jan Kiszka  [2018-01-09 07:21:00 +0100]:

> > 
> > I have also started to see these inmate boot stalls. They are random,
> > though, if you try again you may see the boot pass. BTW, why the
> > change "tools: Leave more space between kernel and initrd on x86"? I'm
> > running with it reverted for a while, since it now takes too much
> > space on inmates for typical 8MB kernels.
> 
> Look into next, and you will find both answers and (hopefully) some
> solution.

Awesome, thanks!

> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

-- 
Gustavo Lima Chaves
Intel - Open Source Technology Center

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 1/5] tools: cell-linux: Use minimal decompression space for ARM64

[Jan Kiszka]

On 2018-01-09 10:36, Lokesh Vutla wrote:
> 
> 
> On Tuesday 09 January 2018 12:01 PM, Jan Kiszka wrote:
>> From: Jan Kiszka 
>>
>> Factor out a default decompression factor for ARM because ARM64 does not
>> perform any compression so far, thus has a factor of 1 only. This allows
>> for more compact non-root Linux cell layout during load.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>>  tools/jailhouse-cell-linux | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/jailhouse-cell-linux b/tools/jailhouse-cell-linux
>> index 086d5982..d27951b7 100755
>> --- a/tools/jailhouse-cell-linux
>> +++ b/tools/jailhouse-cell-linux
>> @@ -310,8 +310,10 @@ class ARMCommon:
>>  if args.initrd:
>>  ramdisk_size = 
>> page_align(os.fstat(args.initrd.fileno()).st_size)
>>  # leave sufficient space between the kernel and the initrd
>> -image_size += kernel_size * 4
>> -kernel_size *= 5
>> +decompression_factor = self.default_decompression_factor()
>> +decompression_space = decompression_factor * kernel_size
>> +kernel_size += decompression_space
>> +image_size += decompression_space
>>  
>>  if not args.dtb:
>>  print('No device tree specified', file=sys.stderr)
>> @@ -425,6 +427,10 @@ class ARM(ARMCommon):
>>  def get_kernel_offset(kernel):
>>  return 0
>>  
>> +@staticmethod
>> +def default_decompression_factor():
>> +return 4
> 
> How did we achieve 4. I guess it is the maximum compression ratio
> possible with any methods. Is my understanding right?

The factor is between the binary [z]Image file and the space after that
image to be reserved in RAM. That means it also takes reservations for
the decompression into account, but it may also be based on an overly
large input image (payload + decompressor). It's not necessarily the
factor between, say, arch/arm/boot/compressed/piggy_data and ../piggy.gzip.

> 
> Else:
> Reviewed-by: Lokesh Vutla 
> 

Thanks,
Jan

> Thanks and regards,
> Lokesh
> 
>> +
>>  
>>  class ARM64(ARMCommon):
>>  name = 'arm64'
>> @@ -442,6 +448,10 @@ class ARM64(ARMCommon):
>>  (text_offset,) = struct.unpack_from('>  return text_offset
>>  
>> +@staticmethod
>> +def default_decompression_factor():
>> +return 1
>> +
>>  
>>  def resolve_arch(defined_arch=None):
>>  arch_classes = {'x86': X86, 'arm': ARM, 'arm64': ARM64, None: None}
>>


-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading kernel on Non-root cell in jetson-TX2.

[a . kumar]

Hi Jan,

> jailhouse cell linux --help
> [...]
>   --write-params FILE, -w FILE
> only parse cell configuration, write out parameters
> into the specified file and print required jailhouse
> cell commands to boot Linux to the console
> 
> It also reports the commands you need to issue on the target. Those
> reveal which addresses the images should be loaded to.
> 
> Note that I pushed some updates to the next branch that make the gap
> between kernel and initrd configurable, and they also shrink it for
> ARM64 (because that arch does not do any kernel compression). Maybe
> worth a try.

We tried with new updated jailhouse, but still it gives same behaviour.

We tried with -w option, as like following command.

sudo jailhouse cell linux configs/jetson-tx2-linux-demo.cell /boot/Image_jan -i 
rootfs.cpio -d inmate-jetson-tx2.dtb -c "console=ttyS0,115200" -w FILE 

but output shows

Modified device tree written. Start Linux with the following commands 
(adjusting paths as needed):

jailhouse cell create configs/jetson-tx2-linux-demo.cell
jailhouse cell load jetson-tx2-linux-demo linux-loader.bin -a 0x0 -s 
"kernel=0xe828 dtb=0xe800" -a 0x1000 /boot/Image_jan -a 0xe828
jailhouse cell start jetson-tx2-linux-demo

it seems related to virt.start address provided in config file can someone give 
me idea about how to calculate virtual-address and how that -w FILE option will 
work in jailhouse

Regards
Ashok

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/5] tools: cell-linux: Make kernel decompression factor configurable

['Lokesh Vutla' via Jailhouse]

On Tuesday 09 January 2018 12:01 PM, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> The required factor depends on the chosen compression method, and that
> may vary. Have a large factor to account for aggressive compressions
> (and increased memory needs during decompression) will work - as long as
> there is enough memory assigned to the cell. Using a smaller default
> will address this but break if the user chooses a better compression
> method.
> 
> Let's make this factor configurable in order to give the user some
> control in case our default should not work.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  tools/jailhouse-cell-linux | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/jailhouse-cell-linux b/tools/jailhouse-cell-linux
> index d27951b7..cf9225b2 100755
> --- a/tools/jailhouse-cell-linux
> +++ b/tools/jailhouse-cell-linux
> @@ -248,7 +248,8 @@ class X86:
>  def setup(self, args, config):
>  self._cpu_reset_address = config.cpu_reset_address
>  
> -self._zero_page = X86ZeroPage(args.kernel, args.initrd, config)
> +self._zero_page = X86ZeroPage(args.kernel, args.initrd,
> +  args.kernel_decomp_factor, config)
>  
>  setup_data = x86_gen_setup_data(config)
>  
> @@ -311,6 +312,8 @@ class ARMCommon:
>  ramdisk_size = page_align(os.fstat(args.initrd.fileno()).st_size)
>  # leave sufficient space between the kernel and the initrd
>  decompression_factor = self.default_decompression_factor()
> +if args.kernel_decomp_factor:
> +decompression_factor = args.kernel_decomp_factor

For ARM changes:
Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 1/5] tools: cell-linux: Use minimal decompression space for ARM64

['Lokesh Vutla' via Jailhouse]

On Tuesday 09 January 2018 12:01 PM, Jan Kiszka wrote:
> From: Jan Kiszka 
> 
> Factor out a default decompression factor for ARM because ARM64 does not
> perform any compression so far, thus has a factor of 1 only. This allows
> for more compact non-root Linux cell layout during load.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  tools/jailhouse-cell-linux | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/jailhouse-cell-linux b/tools/jailhouse-cell-linux
> index 086d5982..d27951b7 100755
> --- a/tools/jailhouse-cell-linux
> +++ b/tools/jailhouse-cell-linux
> @@ -310,8 +310,10 @@ class ARMCommon:
>  if args.initrd:
>  ramdisk_size = page_align(os.fstat(args.initrd.fileno()).st_size)
>  # leave sufficient space between the kernel and the initrd
> -image_size += kernel_size * 4
> -kernel_size *= 5
> +decompression_factor = self.default_decompression_factor()
> +decompression_space = decompression_factor * kernel_size
> +kernel_size += decompression_space
> +image_size += decompression_space
>  
>  if not args.dtb:
>  print('No device tree specified', file=sys.stderr)
> @@ -425,6 +427,10 @@ class ARM(ARMCommon):
>  def get_kernel_offset(kernel):
>  return 0
>  
> +@staticmethod
> +def default_decompression_factor():
> +return 4

How did we achieve 4. I guess it is the maximum compression ratio
possible with any methods. Is my understanding right?

Else:
Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> +
>  
>  class ARM64(ARMCommon):
>  name = 'arm64'
> @@ -442,6 +448,10 @@ class ARM64(ARMCommon):
>  (text_offset,) = struct.unpack_from('  return text_offset
>  
> +@staticmethod
> +def default_decompression_factor():
> +return 1
> +
>  
>  def resolve_arch(defined_arch=None):
>  arch_classes = {'x86': X86, 'arm': ARM, 'arm64': ARM64, None: None}
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.