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