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 <
address@hidden> 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 <address@hidden> wrote:
>
>>
>>
>> On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini <address@hidden>
>> wrote:
>>
>>> Il 01 set 2017 7:59 PM, "Izik Eidus" <address@hidden> 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 <
>>> address@hidden> 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 <address@hidden>
>>> > wrote:
>>> >
>>> >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <address@hidden> 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
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>
>