qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sergio Andrés Gómez del Real
Subject: Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
Date: Sun, 3 Sep 2017 11:33:52 -0500

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]