Re: [Qemu-devel] [PATCH v2 00/13] add support for Hypervisor.framework in QEMU

[Sergio Andrés Gómez del Real]

Guys, I'm almost done with the new version of the patchset (hopefully the
definite one).
What I am missing essentially are presenting a few tests as suggested by
Stefan. Paolo and I only ran the eventinj test from the kvm suite. If I
modify this boot-serial-test to include hvf, should I send these changes
first before the patchset so it could be reproduced? would these be
sufficient, or should I consider some further tests?

On Thu, Aug 31, 2017 at 4:34 AM, Stefan Hajnoczi  wrote:

> On Wed, Aug 30, 2017 at 03:26:49AM -0500, Sergio Andres Gomez Del Real
> wrote:
> > 
> > Changes in v2:
> >  (1) Removed legacy option "-enable-hvf" in favor of "-M accel=hvf"
> >  (2) Added missing copyright headers; replace fprintfs for error_report;
> >  improved commit description.
> >  (3) Moved patch that adds compilation rules in Makefile.objs right after
> >  the patch that adds the new files from Google's repo.
> >  (4) Removed conditional macros from cpus.c and cpu.c
> >  (5) Moved patch that fixes coding style to patch # 3
> >  (6) Fix commit message in apic patch
> >  (7) Squash some commits to avoid code churn
> > 
> >
> > The following patchset adds to QEMU the supporting for macOS's native
> > hypervisor, Hypervisor.framework (hvf). The code base is taken from
> > Google's Android emulator at
> > https://android.googlesource.com/platform/external/qemu/+/emu-master-dev
> .
> >
> > Apart from general code refactoring, some additional features were
> implemented:
> > retrieve the set of features supported by host cpu and hvf (cpuid);
> > dirty page tracking for VGA memory area; reimplementation of the event
> > injection mechanism to allow injection of exceptions during vmexits,
> which is
> > exemplified by the injection of a GP fault when the guest vmexits due to
> > execution of the vmcall instruction; changing the emulator's use of
> CPUState
> > structure in favor of CPUX86State, so as to in the future remove data
> structures
> > that are uselessly specific to hvf and unified some of the state between
> kvm/tcg
> > and hvf.
> > Some features initially planned to implement that didn't make it include:
> > page fault handling in the emulator and implementing the dummy_signal to
> handle
> > the SIG_IPI signal without race conditions. Hopefully these can be
> implemented
> > in the near future.
>
> I have done a brief review (mainly style issues) of the whole series.
>
> A test case is required.  Maybe the easiest option is to extend
> tests/boot-serial-test.c to try hvf (if available).  That way an
> automated test will verify that the BIOS executes inside the guest.
>
> Stefan
>

Re: [Qemu-devel] [PATCH v3 08/14] hvf: add compilation rules to Makefile.objs

[Sergio Andrés Gómez del Real]

Stefan, is this acceptable? I mean delaying the compiling; up until patch 7
no hvf code is compiled. Or should I just squash everything from patch 2 to
7?

El 4/09/2017 23:03, "Sergio Andrés Gómez del Real" <
sergio.g.delr...@gmail.com> escribió:

Note that until this patch (8/14) there is no compiling. I tried to put
this patch earlier in the patchset but found difficulties because some
things need to be done before the hvf code compiles well.
Also, the commit message needs to be updated (remove the -enable-hvf part).

On Mon, Sep 4, 2017 at 10:54 PM, Sergio Andres Gomez Del Real <
sergio.g.delr...@gmail.com> wrote:

> This commit adds to target/i386/Makefile.objs the necessary rules so
> that the new files for hvf are compiled by the build system.
> It also adds handling of the -enable-hvf argument in the main function
> in vl.c.
>
> Signed-off-by: Sergio Andres Gomez Del Real <sergio.g.delr...@gmail.com>
> ---
>  target/i386/Makefile.objs | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
> index 6a26e9d9f0..0bef89c099 100644
> --- a/target/i386/Makefile.objs
> +++ b/target/i386/Makefile.objs
> @@ -12,4 +12,5 @@ obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-windows.o
>  endif
>  ifdef CONFIG_DARWIN
>  obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-darwin.o
> +obj-$(CONFIG_HVF) += hvf-utils/ hvf-all.o
>  endif
> --
> 2.14.1
>
>

Re: [Qemu-devel] [PATCH v3 08/14] hvf: add compilation rules to Makefile.objs

[Sergio Andrés Gómez del Real]

Note that until this patch (8/14) there is no compiling. I tried to put
this patch earlier in the patchset but found difficulties because some
things need to be done before the hvf code compiles well.
Also, the commit message needs to be updated (remove the -enable-hvf part).

On Mon, Sep 4, 2017 at 10:54 PM, Sergio Andres Gomez Del Real <
sergio.g.delr...@gmail.com> wrote:

> This commit adds to target/i386/Makefile.objs the necessary rules so
> that the new files for hvf are compiled by the build system.
> It also adds handling of the -enable-hvf argument in the main function
> in vl.c.
>
> Signed-off-by: Sergio Andres Gomez Del Real 
> ---
>  target/i386/Makefile.objs | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
> index 6a26e9d9f0..0bef89c099 100644
> --- a/target/i386/Makefile.objs
> +++ b/target/i386/Makefile.objs
> @@ -12,4 +12,5 @@ obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-windows.o
>  endif
>  ifdef CONFIG_DARWIN
>  obj-$(CONFIG_HAX) += hax-all.o hax-mem.o hax-darwin.o
> +obj-$(CONFIG_HVF) += hvf-utils/ hvf-all.o
>  endif
> --
> 2.14.1
>
>

Re: [Qemu-devel] [PATCH v3 00/14] add support for Hypervisor.framework in QEMU

[Sergio Andrés Gómez del Real]

This patchset didn't address every issue, so it won't be the definite
version.
Hopefully however the licensing issue will get fixed with this version.

On Mon, Sep 4, 2017 at 10:54 PM, Sergio Andres Gomez Del Real <
sergio.g.delr...@gmail.com> wrote:

> 
> Changes in v3:
>  (1) Fixed licensing issues in patch 3.
>  (2) Revert to late adding of compilation rules in Makefile.objs (patch
> 8/14);
>  files aren't ready to compile earlier.
>  (3) Make a single patch just for fixing style (patch 4/14).
>  (4) Fix data type for hvf_fd field.
>  (5) Add comment that return value of -1 in apic function added in 7/14
> means
>  "no interrupt".
> 
>
> 
> Changes in v2:
>  (1) Removed legacy option "-enable-hvf" in favor of "-M accel=hvf"
>  (2) Added missing copyright headers; replace fprintfs for error_report;
>  improved commit description.
>  (3) Moved patch that adds compilation rules in Makefile.objs right after
>  the patch that adds the new files from Google's repo.
>  (4) Removed conditional macros from cpus.c and cpu.c
>  (5) Moved patch that fixes coding style to patch # 3
>  (6) Fix commit message in apic patch
>  (7) Squash some commits to avoid code churn
> 
>
> The following patchset adds to QEMU the supporting for macOS's native
> hypervisor, Hypervisor.framework (hvf). The code base is taken from
> Google's Android emulator at
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev.
>
> Apart from general code refactoring, some additional features were
> implemented:
> retrieve the set of features supported by host cpu and hvf (cpuid);
> dirty page tracking for VGA memory area; reimplementation of the event
> injection mechanism to allow injection of exceptions during vmexits, which
> is
> exemplified by the injection of a GP fault when the guest vmexits due to
> execution of the vmcall instruction; changing the emulator's use of
> CPUState
> structure in favor of CPUX86State, so as to in the future remove data
> structures
> that are uselessly specific to hvf and unified some of the state between
> kvm/tcg
> and hvf.
> Some features initially planned to implement that didn't make it include:
> page fault handling in the emulator and implementing the dummy_signal to
> handle
> the SIG_IPI signal without race conditions. Hopefully these can be
> implemented
> in the near future.
>
> Sergio Andres Gomez Del Real (14):
>   hvf: add support for Hypervisor.framework in the configure script
>   hvf: add code base from Google's QEMU repository
>   hvf: fix licensing issues; isolate task handling code (GPL v2-only)
>   hvf: run hvf code through checkpatch.pl and fix style issues
>   hvf: add code to cpus.c and do refactoring in preparation for
> compiling
>   hvf: handle fields from CPUState and CPUX86State
>   apic: add function to apic that will be used by hvf
>   hvf: add compilation rules to Makefile.objs
>   hvf: use new helper functions for put/get xsave
>   hvf: implement hvf_get_supported_cpuid
>   hvf: refactor cpuid code
>   hvf: implement vga dirty page tracking
>   hvf: refactor event injection code for hvf
>   hvf: inject General Protection Fault when vmexit through vmcall
>
>  configure   |   38 +
>  cpus.c  |   86 ++
>  hw/intc/apic.c  |   12 +
>  include/hw/i386/apic.h  |1 +
>  include/qom/cpu.h   |2 +
>  include/sysemu/hvf.h|  107 ++
>  qemu-options.hx |   10 +-
>  target/i386/Makefile.objs   |1 +
>  target/i386/cpu-qom.h   |4 +-
>  target/i386/cpu.c   |   79 +-
>  target/i386/cpu.h   |   38 +-
>  target/i386/hvf-all.c   |  963 +++
>  target/i386/hvf-i386.h  |   48 +
>  target/i386/hvf-utils/Makefile.objs |1 +
>  target/i386/hvf-utils/README.md |7 +
>  target/i386/hvf-utils/vmcs.h|  371 ++
>  target/i386/hvf-utils/vmx.h |  222 
>  target/i386/hvf-utils/x86.c |  184 +++
>  target/i386/hvf-utils/x86.h |  476 
>  target/i386/hvf-utils/x86_cpuid.c   |  417 +++
>  target/i386/hvf-utils/x86_cpuid.h   |   52 +
>  target/i386/hvf-utils/x86_decode.c  | 2186 ++
> +
>  target/i386/hvf-utils/x86_decode.h  |  325 ++
>  target/i386/hvf-utils/x86_descr.c   |  124 ++
>  target/i386/hvf-utils/x86_descr.h   |   55 +
>  target/i386/hvf-utils/x86_emu.c | 1536 
>  target/i386/hvf-utils/x86_emu.h |   49 +
>  target/i386/hvf-utils/x86_flags.c   |  333 ++
>  target/i386/hvf-utils/x86_flags.h   |  243 
>  target/i386/hvf-utils/x86_gen.h |   53 +
>  target/i386/hvf-utils/x86_mmu.c |  273 +
>  target/i386/hvf-utils/x86_mmu.h |   45 +
>  target/i386/hvf-utils/x86_task.c|  201 
>  target/i386/hvf-utils/x86_task.h|   18 

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Sergio Andrés Gómez del Real]

Just saw your last message. Will wait for Paolo's response.

On Sun, Sep 3, 2017 at 11:33 AM, Sergio Andrés Gómez del Real <
sergio.g.delr...@gmail.com> wrote:

> Izik, sorry for the late response. Tell me if you have any further issue.
> What are the 2 functions that couldn't be relicensed?
>
> Stefan, as soon as relicensing is available I'll send v3 of the patchset.
>
> On Sun, Sep 3, 2017 at 8:00 AM, Izik Eidus <i...@veertu.com> wrote:
>
>>
>>
>> On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini <pbonz...@redhat.com>
>> wrote:
>>
>>> Il 01 set 2017 7:59 PM, "Izik Eidus" <i...@veertu.com> ha scritto:
>>>
>>> Hi,
>>>
>>> Sergio, I was trying to applying patch  1/13 and 2/13 and then I ran:
>>> ./configure and saw: 'HVF support   yes'
>>> after that 'make' was happy
>>> and:
>>>
>>> ./x86_64-softmmu/qemu-system-x86_64 --help | grep accel
>>>
>>> \property accel=accel1[:accel2[:...]] selects accelerator
>>>
>>> supported accelerators are kvm, xen, hax, hvf or tcg
>>> (default: tcg)
>>>
>>> kernel_irqchip=on|off|split controls accelerated irqchip
>>> support (default=off)
>>>
>>>
>>> however:
>>>
>>> ./x86_64-softmmu/qemu-system-x86_64 -cdrom
>>> /Users/izik/Downloads/ubuntu-16.04.3-desktop-amd64.iso -machine
>>> q35,accel=hvf
>>>
>>> qemu-system-x86_64: -machine accel=hvf: No accelerator found
>>>
>>>
>>> What am I doing wrong?
>>>
>>>
>>> Try applying patch 3 too. Most of the early patches will end up squashed.
>>>
>>
>> Yea that did the magic, now I have compilation errors but from here I
>> will take it, and just fix the compilation step for each patch and resend.
>>
>>
>>>
>>> Paolo
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>> On Fri, Sep 1, 2017 at 12:41 AM, Sergio Andrés Gómez del Real <
>>> sergio.g.delr...@gmail.com> wrote:
>>>
>>> > Hello,
>>> > Mr. Frank Yang was the guy at Google that introduced the HVF port to
>>> > Google's Android Emulator QEMU branch.
>>> > Frank, in this thread we are discussing the licensing issue with the
>>> HVF
>>> > files (their being GPL v2-only). Paolo from Red Hat was asking to
>>> Veertu
>>> > developer Izik Eidus if the code in Veertu derived only from QEMU,
>>> Bochs
>>> > and other GPLv2+ or LGPL software. Because the code at Google was
>>> itself
>>> > derived from Veertu, I'd imagine the same licensing terms would apply
>>> in
>>> > your case. Any light you can throw over this issue would be much
>>> > appreciated.
>>> >
>>> > Thank you.
>>> >
>>> > On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini <pbonz...@redhat.com>
>>> > wrote:
>>> >
>>> >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> ha scritto:
>>> >>
>>> >> > Izik, Vincent (assuming you are the right person to contact at
>>> Google),
>>> >> > can you reply to Daniel and Stefan?
>>> >> >
>>> >>
>>> >> Hi,
>>> >>
>>> >> What I suggest is that we will send our patch' again as gpl2+ and
>>> clean
>>> >> the
>>> >> entire stuff to make sure they are falling into the right copyright
>>> >> category as required by QEMU.
>>> >>
>>> >>
>>> >> That's not necessary. Just you and Vincent replying to this thread
>>> with a
>>> >> "Signed-off-by" line would be enough for Sergio to use the right
>>> license in
>>> >> his v3 submission. Sergio already made some non-trivial changes that
>>> are
>>> >> needed for inclusion in QEMU from a supportability (e.g. dirty page
>>> >> tracking for graphics) or maintainability perspective (e.g. -cpu
>>> support),
>>> >> so the simplest thing to do is to retrofit the right license to his
>>> >> submission. You can do so if you can confirm that the code you used
>>> only
>>> >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the
>>> rest
>>> >> was written by Veertu).
>>> >>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Sergio Andrés Gómez del Real]

Izik, sorry for the late response. Tell me if you have any further issue.
What are the 2 functions that couldn't be relicensed?

Stefan, as soon as relicensing is available I'll send v3 of the patchset.

On Sun, Sep 3, 2017 at 8:00 AM, Izik Eidus <i...@veertu.com> wrote:

>
>
> On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:
>
>> Il 01 set 2017 7:59 PM, "Izik Eidus" <i...@veertu.com> ha scritto:
>>
>> Hi,
>>
>> Sergio, I was trying to applying patch  1/13 and 2/13 and then I ran:
>> ./configure and saw: 'HVF support   yes'
>> after that 'make' was happy
>> and:
>>
>> ./x86_64-softmmu/qemu-system-x86_64 --help | grep accel
>>
>> \property accel=accel1[:accel2[:...]] selects accelerator
>>
>> supported accelerators are kvm, xen, hax, hvf or tcg
>> (default: tcg)
>>
>> kernel_irqchip=on|off|split controls accelerated irqchip
>> support (default=off)
>>
>>
>> however:
>>
>> ./x86_64-softmmu/qemu-system-x86_64 -cdrom
>> /Users/izik/Downloads/ubuntu-16.04.3-desktop-amd64.iso -machine
>> q35,accel=hvf
>>
>> qemu-system-x86_64: -machine accel=hvf: No accelerator found
>>
>>
>> What am I doing wrong?
>>
>>
>> Try applying patch 3 too. Most of the early patches will end up squashed.
>>
>
> Yea that did the magic, now I have compilation errors but from here I will
> take it, and just fix the compilation step for each patch and resend.
>
>
>>
>> Paolo
>>
>>
>> Thanks.
>>
>>
>>
>>
>> On Fri, Sep 1, 2017 at 12:41 AM, Sergio Andrés Gómez del Real <
>> sergio.g.delr...@gmail.com> wrote:
>>
>> > Hello,
>> > Mr. Frank Yang was the guy at Google that introduced the HVF port to
>> > Google's Android Emulator QEMU branch.
>> > Frank, in this thread we are discussing the licensing issue with the HVF
>> > files (their being GPL v2-only). Paolo from Red Hat was asking to Veertu
>> > developer Izik Eidus if the code in Veertu derived only from QEMU, Bochs
>> > and other GPLv2+ or LGPL software. Because the code at Google was itself
>> > derived from Veertu, I'd imagine the same licensing terms would apply in
>> > your case. Any light you can throw over this issue would be much
>> > appreciated.
>> >
>> > Thank you.
>> >
>> > On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini <pbonz...@redhat.com>
>> > wrote:
>> >
>> >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> ha scritto:
>> >>
>> >> > Izik, Vincent (assuming you are the right person to contact at
>> Google),
>> >> > can you reply to Daniel and Stefan?
>> >> >
>> >>
>> >> Hi,
>> >>
>> >> What I suggest is that we will send our patch' again as gpl2+ and clean
>> >> the
>> >> entire stuff to make sure they are falling into the right copyright
>> >> category as required by QEMU.
>> >>
>> >>
>> >> That's not necessary. Just you and Vincent replying to this thread
>> with a
>> >> "Signed-off-by" line would be enough for Sergio to use the right
>> license in
>> >> his v3 submission. Sergio already made some non-trivial changes that
>> are
>> >> needed for inclusion in QEMU from a supportability (e.g. dirty page
>> >> tracking for graphics) or maintainability perspective (e.g. -cpu
>> support),
>> >> so the simplest thing to do is to retrofit the right license to his
>> >> submission. You can do so if you can confirm that the code you used
>> only
>> >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the
>> rest
>> >> was written by Veertu).
>> >>
>> >> Google has already contributed the HAXN accelerator, so I am moderately
>> >> optimistic that they can help with HVF too.
>> >>
>> >> BTW, another thing that need to be integrated in order to make this
>> stuff
>> >> useful is the vmnet patch's, it is apple NAT for vms that allow guests
>> to
>> >> have networking...
>> >>
>> >>
>> >> People can always use slirp (or tap with some more effort), so these
>> >> patches are already a minimum viable feature and pretty close to being
>> >> mergeable. But of course any other contribution is welcome!
>> >>
>> >> Paolo
>> >>
>> >>
>> >> (altho that it come with a trick, without certificate it
>> >> will require root permission, while hypverisor framework itself can run
>> >> without root)
>> >>
>> >> What do you guys think?
>> >>
>> >>
>> >> >
>> >> > Sergio worked on completing the QEMU port to Hypervisor.framework.
>> The
>> >> > hvf-all.c file that Daniel pointed out as v2-only is derived from
>> >> kvm-all.c
>> >> > and hax-all.c, and should be under v2-or-later license. The others
>> seem
>> >> to
>> >> > be either original or derived from Bochs, which is LGPL, so they
>> could
>> >> be
>> >> > LGPL or GPLv2+.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Paolo
>> >> >
>> >> >
>> >> > There are benefits to having this code upstream.  If they ever want
>> to
>> >> > rebase on qemu.git there will be less work for them.
>> >> >
>> >> > Stefan
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Sergio Andrés Gómez del Real]

Hello,
Mr. Frank Yang was the guy at Google that introduced the HVF port to
Google's Android Emulator QEMU branch.
Frank, in this thread we are discussing the licensing issue with the HVF
files (their being GPL v2-only). Paolo from Red Hat was asking to Veertu
developer Izik Eidus if the code in Veertu derived only from QEMU, Bochs
and other GPLv2+ or LGPL software. Because the code at Google was itself
derived from Veertu, I'd imagine the same licensing terms would apply in
your case. Any light you can throw over this issue would be much
appreciated.

Thank you.

On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini  wrote:

> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
>
> > Izik, Vincent (assuming you are the right person to contact at Google),
> > can you reply to Daniel and Stefan?
> >
>
> Hi,
>
> What I suggest is that we will send our patch' again as gpl2+ and clean the
> entire stuff to make sure they are falling into the right copyright
> category as required by QEMU.
>
>
> That's not necessary. Just you and Vincent replying to this thread with a
> "Signed-off-by" line would be enough for Sergio to use the right license in
> his v3 submission. Sergio already made some non-trivial changes that are
> needed for inclusion in QEMU from a supportability (e.g. dirty page
> tracking for graphics) or maintainability perspective (e.g. -cpu support),
> so the simplest thing to do is to retrofit the right license to his
> submission. You can do so if you can confirm that the code you used only
> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
> was written by Veertu).
>
> Google has already contributed the HAXN accelerator, so I am moderately
> optimistic that they can help with HVF too.
>
> BTW, another thing that need to be integrated in order to make this stuff
> useful is the vmnet patch's, it is apple NAT for vms that allow guests to
> have networking...
>
>
> People can always use slirp (or tap with some more effort), so these
> patches are already a minimum viable feature and pretty close to being
> mergeable. But of course any other contribution is welcome!
>
> Paolo
>
>
> (altho that it come with a trick, without certificate it
> will require root permission, while hypverisor framework itself can run
> without root)
>
> What do you guys think?
>
>
> >
> > Sergio worked on completing the QEMU port to Hypervisor.framework. The
> > hvf-all.c file that Daniel pointed out as v2-only is derived from
> kvm-all.c
> > and hax-all.c, and should be under v2-or-later license. The others seem
> to
> > be either original or derived from Bochs, which is LGPL, so they could be
> > LGPL or GPLv2+.
> >
> > Thanks,
> >
> > Paolo
> >
> >
> > There are benefits to having this code upstream.  If they ever want to
> > rebase on qemu.git there will be less work for them.
> >
> > Stefan
> >
> >
> >
>
>
>

[Qemu-devel] Interested in GSoC 2017: Add a Hypervisor.framework accelerator

[Sergio Andrés Gómez del Real]

Hello, my name is Sergio Gómez.
It seems that QEMU has been accepted into GSoC 2017. I'm interested in
working with QEMU due to my interest in virtual machines in general.
Particularly, taking into account that I have experience developing a
(simple) emulator, and a (very simple) operating system, and done lots
of C and Assembly Language programming, I find the project proposal
"Add a Hypervisor.framework accelerator", mentored by Mr. Alexander
Graf an ideal and stimulating task for me to tackle.

Besides considering having the technical knowledge to accomplish what
is proposed, I think that my communication skills would also be very
valuable not only for this project, but to continue involved with QEMU
(which is what I'd like).

I wrote to Mr. Stefan Hajnoczi a while ago showing my interest in QEMU
and GSoC 2017. I've been studying some of the project's code, for
example, the C routines that are 'hooked' into the C runtime before
main() which does some work for initializing the QEMU Object Model
(QOM), which I've also been studying a little bit.

I feel very comfortable writing and debugging low-level code, with all
its intricacies. I would like and opportunity to show these skills.

I am looking forward to his opportunity and full of motivation to get
involved with the QEMU project.

Thank you for your attention, and feedback on how to proceed would be great.

[Qemu-devel] [PATCH] hw/dma: Fix dead code in pl080.c

[Sergio Andrés Gómez Del Real]

The patch fixes dead code in pl080_read() and pl080_write() as reported
in bug #1637974. According to ARM's official Technical Reference Manual,
offsets handled by the switch statement are 0x100, 0x104, 0x108, 0x10C
and 0x110, so the solution suggested by the guy who reported the bug is
right.

Signed-off-by: Sergio Andrés Gómez Del Real <sergio.g.delr...@gmail.com>
---
 hw/dma/pl080.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/dma/pl080.c b/hw/dma/pl080.c
index 7724c93..3b0c20b 100644
--- a/hw/dma/pl080.c
+++ b/hw/dma/pl080.c
@@ -255,7 +255,7 @@ static uint64_t pl080_read(void *opaque, hwaddr offset,
 i = (offset & 0xe0) >> 5;
 if (i >= s->nchannels)
 goto bad_offset;
-switch (offset >> 2) {
+switch ((offset - 0x100) >> 2) {
 case 0: /* SrcAddr */
 return s->chan[i].src;
 case 1: /* DestAddr */
@@ -316,7 +316,7 @@ static void pl080_write(void *opaque, hwaddr offset,
 i = (offset & 0xe0) >> 5;
 if (i >= s->nchannels)
 goto bad_offset;
-switch (offset >> 2) {
+switch ((offset - 0x100) >> 2) {
 case 0: /* SrcAddr */
 s->chan[i].src = value;
 break;
-- 
2.10.2

[Qemu-devel] [PATCH] hw/dma: Fix dead code in pl080.c

[Sergio Andrés Gómez Del Real]

The patch fixes dead code in pl080_read() and pl080_write() as reported
in bug #1637974. According to ARM's official Technical Reference Manual,
offsets handled by the switch statement are 0x100, 0x104, 0x108, 0x10C
and 0x110, so the solution suggested by the guy who reported the bug is
right.

Signed-off-by: Sergio Andrés Gómez Del Real <sergio.g.delr...@gmail.com>
---
 hw/dma/pl080.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/dma/pl080.c b/hw/dma/pl080.c
index 7724c93..8f34f24 100644
--- a/hw/dma/pl080.c
+++ b/hw/dma/pl080.c
@@ -255,7 +255,7 @@ static uint64_t pl080_read(void *opaque, hwaddr offset,
 i = (offset & 0xe0) >> 5;
 if (i >= s->nchannels)
 goto bad_offset;
-switch (offset >> 2) {
+switch ((offset-0x100) >> 2) {
 case 0: /* SrcAddr */
 return s->chan[i].src;
 case 1: /* DestAddr */
@@ -316,7 +316,7 @@ static void pl080_write(void *opaque, hwaddr offset,
 i = (offset & 0xe0) >> 5;
 if (i >= s->nchannels)
 goto bad_offset;
-switch (offset >> 2) {
+switch ((offset-0x100) >> 2) {
 case 0: /* SrcAddr */
 s->chan[i].src = value;
 break;
-- 
2.10.2