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

[Paolo Bonzini]

Il 03 set 2017 6:54 PM, "Izik Eidus" <address@hidden> ha scritto:

> What code is derived from v2-only sources? IIRC the task switch code is
> derived from KVM, is there anything else?

Yes this is exactly the code that I found as well, however considering the
fact that I didn't even know it was there requires me to go and validate
that other stuff are safe for GPL2v+.


FWIW I didn't find anything else coming from KVM.

The newer implementation is what we are using in Anka to virtluze macOS
(but it is handling windows/linux/*), in my perspective it is more mature
and handle many more corner case, it is currently not plugged into QEMU,
and all the work that need to happen is: plug it like the KVM user space
bits with the ideas of Sergio, and the recommendations of QEMU for this
patch's.

One big advantage is that we will be more than happy to back port fix's as
they come from Anka to QEMU hvf.


It's difficult for me to judge without seeing your code (couldn't find it
from a quick look on GitHub). I expect any code that we merged from Anka
would diverge as QEMU's HVF integration matures (e.g. adding support for
live migration, unifying the page walkers, etc.). On the other hand if you
open-source more hypervisor.framework client code or new instruction
emulator code we can certainly merge it back into QEMU when it makes sense!

I think it's safe to use v2+ for this code once Google agrees. The task
switch code, which is going to go away soon anyway and is isolated from the
rest, can be moved to a separate file for the time being.

Paolo


>
> Paolo
>
> in
> such case all copyright go back to BSD2 and we can license it as GPL2v+ or
> whatever work for QEMU.
> If you want to go in such case what we will do would be the following:
> take kvm user space implemantion of qemu that is GPLv2+, integrate to it
> the hypervisor framework from Anka (in kvm user space style) - this will
> put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the
> rest of Sergio changes to this stuff.
>
> I know this is less than ideal as it requires some changes to the current
> patch set, however it will make it 100% safe to be GPL2v+, what you guys
> think?, we can get this stuff done before the end of this week...
>
> Thanks.
>
>
> On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus <address@hidden> wrote:
>
> >
> >
> > On Fri, Sep 1, 2017 at 12:21 AM, 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).
> >>
> >
> > Hi,
> >
> > Sure fine with us, let me go over all the code and see that all
copyright
> > that are needed are there, and then you can relicense all our code to
> > GPLv2+, I think I saw a a file that was missing Bochs copyright in it,
> so I
> > want to make sure that I fix this before and that all others are fine.
> >
> > Thanks.
> >
> >
> >>
> >> 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.
> >>
> >>
> OK,
>
>
> > >
> >> > Stefan
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
>
>
>