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

[Izik Eidus]

On Wed, Sep 6, 2017 at 5:28 PM, Paolo Bonzini  wrote:
> Il 06 set 2017 3:29 PM, "Izik Eidus"  ha scritto:
>
> Paolo, I was reviewing more and more our code and found another issue
> regarding licensing of gpl2v+: the file x86_descr.c include:
> #define VMX_SEGMENT_FIELD(seg) that is coming from KVM that is gpl2 code.
>
>
> I don't think that's copyrightable.
>
> unfortunately we had a developer that introduced both this code and the
> task_switch, I am reviewing more and more this now to find if we have any
> other gpl2v only in our code.
>
> Maybe it does worth to reconsider us donating hypervisor.framework
> implemantion that will be clean from such gpl2v only issue? I know it will
> slow little bit the integration but we are willing to put all the
> effort that is needed, including syncing all Sergio later on patch's
> and whatever is needed more.
>
>
> I think we need to be pragmatic and picking the best of the two
> implementations (plus KVM itself) is the best option. There is considerable
> overlap between QEMU and KVM developers, and anyone could say in bad faith
> that people are reusing their KVM knowledge when touching HVF code in QEMU.
>
> What matters more in my non-lawyerly opinion is that we handle HVF code as a
> part of QEMU rather than something bolted on the side. This alone will make
> a lot of functions that _could_ come from external sources go away, as the
> processor emulation stuff from TCG can easily get reused.

OK, fine with me.

Thanks.

>
> Patio
>
> Paolo
>
>
> Thanks.
>
>>
>>
>> Then Izik and Frank can reply with their Signed-off-by to that extra
>> patch.
>>
>> Thanks,
>>
>> Paolo
>>
>>
>>
>> >
>> > 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.
>> >
>>
>>
>> OK, such case would be simpler to me to go if this what you prefer, in
>> such
>> case, i will send the 1|2|3 patches splited from task switch and
>> everything  beside task switch as gpl2v+.
>>
>> Whatever you guys decide...
>>
>> Thanks.
>>
>>
>> >
>> > 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 > > > wrote:
>> > >
>> > > >
>> > > >
>> > > > On Fri, Sep 1, 2017 at 12:21 AM, 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).
>> > > >>
>> > > >
>> > > > 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
>> > > 

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

[Paolo Bonzini]

Il 06 set 2017 3:29 PM, "Izik Eidus"  ha scritto:

Paolo, I was reviewing more and more our code and found another issue
regarding licensing of gpl2v+: the file x86_descr.c include:
#define VMX_SEGMENT_FIELD(seg) that is coming from KVM that is gpl2 code.


I don't think that's copyrightable.

unfortunately we had a developer that introduced both this code and
the task_switch, I am reviewing more and more this now to find if we
have any other gpl2v only in our code.

Maybe it does worth to reconsider us donating hypervisor.framework
implemantion that will be clean from such gpl2v only issue? I know it
will slow little bit the integration but we are willing to put all the
effort that is needed, including syncing all Sergio later on patch's
and whatever is needed more.


I think we need to be pragmatic and picking the best of the two
implementations (plus KVM itself) is the best option. There is considerable
overlap between QEMU and KVM developers, and anyone could say in bad faith
that people are reusing their KVM knowledge when touching HVF code in QEMU.

What matters more in my non-lawyerly opinion is that we handle HVF code as
a part of QEMU rather than something bolted on the side. This alone will
make a lot of functions that _could_ come from external sources go away, as
the processor emulation stuff from TCG can easily get reused.

Patio

Paolo


Thanks.

>
>
> Then Izik and Frank can reply with their Signed-off-by to that extra
patch.
>
> Thanks,
>
> Paolo
>
>
>
> >
> > 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.
> >
>
>
> OK, such case would be simpler to me to go if this what you prefer, in
such
> case, i will send the 1|2|3 patches splited from task switch and
> everything  beside task switch as gpl2v+.
>
> Whatever you guys decide...
>
> Thanks.
>
>
> >
> > 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  > > wrote:
> > >
> > > >
> > > >
> > > > On Fri, Sep 1, 2017 at 12:21 AM, 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).
> > > >>
> > > >
> > > > 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
> > 

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

[Izik Eidus]

On Mon, Sep 4, 2017 at 9:47 AM, Paolo Bonzini  wrote:
>
>
>
> Il 03 set 2017 8:49 PM, "Izik Eidus"  ha scritto:
>
> For now i want to get hypervisor framework merged into QEMU in required 
> license. I did offer to open source everything needed from anka to the make 
> QEMU being able to run any os using hypervisor.framework.
>
>
> Having such code as open source will certainly help anyone who is going to 
> work more on QEMU HVF so it would be great.
>
> Sergio, in the meanwhile can you post v3 with an extra patch after 2/13 that:
>
> - moves the task switch code to a new file with v2-only header
>
> - changes all v2-only or v2-v3 headers in HVF files to v2-or-later


Hi,

Paolo, I was reviewing more and more our code and found another issue
regarding licensing of gpl2v+:
the file x86_descr.c include:
#define VMX_SEGMENT_FIELD(seg) that is coming from KVM that is gpl2 code.
unfortunately we had a developer that introduced both this code and
the task_switch, I am reviewing more and more this now to find if we
have any other gpl2v only in our code.

Maybe it does worth to reconsider us donating hypervisor.framework
implemantion that will be clean from such gpl2v only issue? I know it
will slow little bit the integration but we are willing to put all the
effort that is needed, including syncing all Sergio later on patch's
and whatever is needed more.

Thanks.

>
>
> Then Izik and Frank can reply with their Signed-off-by to that extra patch.
>
> Thanks,
>
> Paolo
>
>
>
> >
> > 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.
> >
>
>
> OK, such case would be simpler to me to go if this what you prefer, in such
> case, i will send the 1|2|3 patches splited from task switch and
> everything  beside task switch as gpl2v+.
>
> Whatever you guys decide...
>
> Thanks.
>
>
> >
> > 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  > > wrote:
> > >
> > > >
> > > >
> > > > On Fri, Sep 1, 2017 at 12:21 AM, 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).
> > > >>
> > > >
> > > > 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 

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

[Paolo Bonzini]

Il 03 set 2017 8:49 PM, "Izik Eidus"  ha scritto:

For now i want to get hypervisor framework merged into QEMU in required
license. I did offer to open source everything needed from anka to the make
QEMU being able to run any os using hypervisor.framework.


Having such code as open source will certainly help anyone who is going to
work more on QEMU HVF so it would be great.

Sergio, in the meanwhile can you post v3 with an extra patch after 2/13
that:

- moves the task switch code to a new file with v2-only header

- changes all v2-only or v2-v3 headers in HVF files to v2-or-later

Then Izik and Frank can reply with their Signed-off-by to that extra patch.

Thanks,

Paolo



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


OK, such case would be simpler to me to go if this what you prefer, in such
case, i will send the 1|2|3 patches splited from task switch and
everything  beside task switch as gpl2v+.

Whatever you guys decide...

Thanks.


>
> 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  > wrote:
> >
> > >
> > >
> > > On Fri, Sep 1, 2017 at 12:21 AM, 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).
> > >>
> > >
> > > 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+.
> > >> >

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

[Izik Eidus]

On Sun, Sep 3, 2017 at 8:13 PM, Paolo Bonzini > wrote:

>
>
> Il 03 set 2017 6:54 PM, "Izik Eidus"  > 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).
>

Yea, we will have to open source that code in such case.


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

I think you are right.


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

For now i want to get hypervisor framework merged into QEMU in required
license. I did offer to open source everything needed from anka to the make
QEMU being able to run any os using hypervisor.framework.


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


OK, such case would be simpler to me to go if this what you prefer, in such
case, i will send the 1|2|3 patches splited from task switch and
everything  beside task switch as gpl2v+.

Whatever you guys decide...

Thanks.


>
> 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  > wrote:
> >
> > >
> > >
> > > On Fri, Sep 1, 2017 at 12:21 AM, 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).
> > >>
> > >
> > > 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 

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"  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  wrote:
>
> >
> >
> > On Fri, Sep 1, 2017 at 12:21 AM, 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).
> >>
> >
> > 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
> >> > 

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

[Izik Eidus]

On Sun, Sep 3, 2017 at 7:35 PM, Paolo Bonzini  wrote:

>
>
> Il 03 set 2017 6:17 PM, "Izik Eidus"  ha scritto:
>
> Hi,
>
> Paolo, my biggest challenge right now is:
> hvf-all.c
> it include currently the following copyright:
>
> // Copyright 2008 IBM Corporation
>
> //   2008 Red Hat, Inc.
>
> // Copyright 2011 Intel Corporation
>
> // Copyright 2016 Veertu, Inc.
> // Copyright 2017 The Android Open Source Project
>
> and it is GPLv2, However we want to integrate this stuff to QEMU in the
> required license (GPLv2+), I have a suggestion that maybe the safest way
> for us to achieve GPLv2+  would be that we will send you the current
> hypervisor framework implementation of Anka that is derived from
> xhyve/bhyve + our own changes to make it run windows / linux / macOS,
>
>
> 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+.


>
> If you can identify the functions that cannot be v2-or-later that's
> already okay. There is a lot more refactoring to do in the HVF code to
> remove duplication with other parts of the code, and if it's just a couple
> isolated cases we can maybe try to prioritize them. For example it's part
> of the plan to replace the task switch code with the version in
> seg_helper.c. Worst case, QEMU has done clean room reverse engineering a
> couple times in the past to fix licensing issues.
>
> If you think your plan works better and you can devote a week to it, we
> can also try it. But having a clear answer on what code is from v2-only
> sources may help judging on the better approach. I an worried that some of
> the later patches could be tricky to redo/backport. What are the advantages
> of the newer implementation? Does it reuse more KVM userspace bits?
>


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.

>
> 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  wrote:
>
> >
> >
> > On Fri, Sep 1, 2017 at 12:21 AM, 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).
> >>
> >
> > 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 

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

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

[Paolo Bonzini]

Il 03 set 2017 6:17 PM, "Izik Eidus"  ha scritto:

Hi,

Paolo, my biggest challenge right now is:
hvf-all.c
it include currently the following copyright:

// Copyright 2008 IBM Corporation

//   2008 Red Hat, Inc.

// Copyright 2011 Intel Corporation

// Copyright 2016 Veertu, Inc.
// Copyright 2017 The Android Open Source Project

and it is GPLv2, However we want to integrate this stuff to QEMU in the
required license (GPLv2+), I have a suggestion that maybe the safest way
for us to achieve GPLv2+  would be that we will send you the current
hypervisor framework implementation of Anka that is derived from
xhyve/bhyve + our own changes to make it run windows / linux / macOS,


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

If you can identify the functions that cannot be v2-or-later that's already
okay. There is a lot more refactoring to do in the HVF code to remove
duplication with other parts of the code, and if it's just a couple
isolated cases we can maybe try to prioritize them. For example it's part
of the plan to replace the task switch code with the version in
seg_helper.c. Worst case, QEMU has done clean room reverse engineering a
couple times in the past to fix licensing issues.

If you think your plan works better and you can devote a week to it, we can
also try it. But having a clear answer on what code is from v2-only sources
may help judging on the better approach. I an worried that some of the
later patches could be tricky to redo/backport. What are the advantages of
the newer implementation? Does it reuse more KVM userspace bits?

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

>
>
> On Fri, Sep 1, 2017 at 12:21 AM, 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).
>>
>
> 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 

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

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

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

[Izik Eidus]

Hi,

Paolo, my biggest challenge right now is:
hvf-all.c
it include currently the following copyright:

// Copyright 2008 IBM Corporation

//   2008 Red Hat, Inc.

// Copyright 2011 Intel Corporation

// Copyright 2016 Veertu, Inc.
// Copyright 2017 The Android Open Source Project

and it is GPLv2, However we want to integrate this stuff to QEMU in the
required license (GPLv2+), I have a suggestion that maybe the safest way
for us to achieve GPLv2+  would be that we will send you the current
hypervisor framework implementation of Anka that is derived from
xhyve/bhyve + our own changes to make it run windows / linux / macOS, 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  wrote:

>
>
> On Fri, Sep 1, 2017 at 12:21 AM, 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).
>>
>
> 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
>> >
>> >
>> >
>>
>>
>>
>

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

[Izik Eidus]

On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini  wrote:

> Il 01 set 2017 7:59 PM, "Izik Eidus"  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 
> > 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
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
>
>
>

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

[Paolo Bonzini]

Il 01 set 2017 7:59 PM, "Izik Eidus"  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.

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

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

[Izik Eidus]

On Fri, Sep 1, 2017 at 12:21 AM, 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).
>


Hi,

I found 2 functions that can't be licensed as GPLv2+ (only GPLv2) they are
very insignificant and one of them is never being called, As soon as Sergio
reply to me about what I am missing in getting 1/13 and 2/13 patch's to
work, I will send 2/13 again acked by me with full GPLv2+ license code
(without the GPLv2 code) from Veertu and then Google have to approve as
well.

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

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

[Izik Eidus]

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?

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

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

[Daniel P. Berrange]

On Fri, Sep 01, 2017 at 01:10:54AM +0300, Izik Eidus wrote:
> (BTW, I am pretty sure the copyright message that include GPLv2/GPLv3 and
> created all this mess was taken from QEMU itself ... :))

Sigh, you are right there. I've just checked and found a random splattering
of files with "GPL-v2-or-v3-only" license :-(

Just reinforces that we need to do a better (ie automated) job at reviewing
license declarations on submitted code in future.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[Frank Yang via Qemu-devel]

+ our product manager

If I understand correctly, we will need to reconsider things if I included
any additional technology in my port. However, I didn't include any
additional references/source in my port compared to Veertu, that was not in
the qemu code already (e.g., hax-all/kvm-all) so I think we can just change
the QEMU upstream port to use gplv2+.

Izik, are you ok with this assessment?

On Thu, Aug 31, 2017 at 2:41 PM, 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 
> 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!
>>
>
That's what we do with networking in HVF for android emulator, btw; use
slirp.


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

[Izik Eidus]

On Fri, Sep 1, 2017 at 1:02 AM, Frank Yang  wrote:

> + our product manager
>
> If I understand correctly, we will need to reconsider things if I included
> any additional technology in my port. However, I didn't include any
> additional references/source in my port compared to Veertu, that was not in
> the qemu code already (e.g., hax-all/kvm-all) so I think we can just change
> the QEMU upstream port to use gplv2+.
>
> Izik, are you ok with this assessment?
>

Yes we are fine with changing everything to GPLv2+, I am just going over
the code and confirm that all copyright attributions as I saw a file that
was missing Bochs LGPLv2 copyright.



>
> On Thu, Aug 31, 2017 at 2:41 PM, 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 
>> 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!
>>>
>>
> That's what we do with networking in HVF for android emulator, btw; use
> slirp.
>


Yes, you guys can use our vmnet implemantion together proxy that we are
having to allow to run it without root, I think this proxy is making sense
for the android users as they won't required root, but for QEMU I think
only the vmnet implemantion will be wanted.
after this stuff will get merged we will send the vmnet stuff as GPLv2+ as
now it is GPLv2/GPLv3.

(BTW, I am pretty sure the copyright message that include GPLv2/GPLv3 and
created all this mess was taken from QEMU itself ... :))


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

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

[Izik Eidus]

On Fri, Sep 1, 2017 at 12:21 AM, 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).
>

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

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

[Paolo Bonzini]

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

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

[Izik Eidus]

On Thu, Aug 31, 2017 at 2:26 PM, Paolo Bonzini  wrote:

>
>
> Il 31 ago 2017 9:43 AM, "Stefan Hajnoczi"  ha scritto:
>
> On Wed, Aug 30, 2017 at 03:07:38PM +0100, Daniel P. Berrange wrote:
> > On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real
> wrote:
> > > diff --git a/target/i386/hvf-utils/x86.c b/target/i386/hvf-utils/x86.c
> > > new file mode 100644
> > > index 00..e3db2c9c8b
> > > --- /dev/null
> > > +++ b/target/i386/hvf-utils/x86.c
> > > @@ -0,0 +1,174 @@
> > > +/*
> > > + * Copyright (C) 2016 Veertu Inc,
> > > + * Copyright (C) 2017 Google Inc,
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU General Public License as
> > > + * published by the Free Software Foundation; either version 2 or
> > > + * (at your option) version 3 of the License.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public License
> along
> > > + * with this program; if not, see .
> > > + */
> >
> > Again  v2-or-v3-only.
> >
> > There's many more files with this same problem but I'll stop pointing
> > them out now.
> >
> > If this is to be included in QEMU,  Veertu & Google (and any other
> > copyright holders) would have to agree to change these files to
> > v2-or-later
>
> Sergio: Have you or Paolo had any contact with the Veertu or Google
> authors about your Hypervisor.framework project?  If you're already in
> contact with them you could raise the issue and ask them to join this
> email thread.
>
>
> 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.

I think it will be easier to me to just integrate it all to QEMU  however I
need to know if to use the Google code or not (it is anyway not a big issue
from time perspective)

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

[Paolo Bonzini]

Il 31 ago 2017 9:43 AM, "Stefan Hajnoczi"  ha scritto:

On Wed, Aug 30, 2017 at 03:07:38PM +0100, Daniel P. Berrange wrote:
> On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real
wrote:
> > diff --git a/target/i386/hvf-utils/x86.c b/target/i386/hvf-utils/x86.c
> > new file mode 100644
> > index 00..e3db2c9c8b
> > --- /dev/null
> > +++ b/target/i386/hvf-utils/x86.c
> > @@ -0,0 +1,174 @@
> > +/*
> > + * Copyright (C) 2016 Veertu Inc,
> > + * Copyright (C) 2017 Google Inc,
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 or
> > + * (at your option) version 3 of the License.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
along
> > + * with this program; if not, see .
> > + */
>
> Again  v2-or-v3-only.
>
> There's many more files with this same problem but I'll stop pointing
> them out now.
>
> If this is to be included in QEMU,  Veertu & Google (and any other
> copyright holders) would have to agree to change these files to
> v2-or-later

Sergio: Have you or Paolo had any contact with the Veertu or Google
authors about your Hypervisor.framework project?  If you're already in
contact with them you could raise the issue and ask them to join this
email thread.


Izik, Vincent (assuming you are the right person to contact at Google), can
you reply to Daniel and Stefan?

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

[Stefan Hajnoczi]

On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real wrote:
> This file begins tracking the files that will be the code base for HVF
> support in QEMU. This code base is part of Google's QEMU version of
> their Android emulator, and can be found at
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev
> 
> This code is based on Veertu Inc's vdhh (Veertu Desktop Hosted
> Hypervisor), found at https://github.com/veertuinc/vdhh. Everything is
> appropriately licensed under GPL v2.
> 
> This code base already implements a very great deal of functionality,
> although Google's version removed from Vertuu's the support for APIC
> page and hyperv-related stuff. According to the Android Emulator Release
> Notes, Revision 26.1.3 (August 2017), "Hypervisor.framework is now
> enabled by default on macOS for 32-bit x86 images to improve performance
> and macOS compatibility", although we better use with caution for, as the
> same Revision warns us, "If you experience issues with it specifically,
> please file a bug report...". The code hasn't seen much update in the
> last 5 months, so I think that we can further develop the code with
> occasional visiting Google's repository to see if there has been any
> update.
> 
> The code's style isn't aligned to QEMU's standards; this will be fixed
> in a subsequent patch in this series.
> On top of this code base we are implementing the following features: fix
> the code that passes the cpuid features to the guest; implementing dirty
> page tracking for vga memory region; reimplementing the event injection
> mechanism for exception injection and many other minor
> fixes/refactoring that are documented in their respective patches.
> 
> Signed-off-by: Sergio Andres Gomez Del Real 
> ---

This looks like a reasonable approach to getting Hypervisor.framework
support.  I haven't reviewed the details but it contains all the pieces
one would expect.

Which guest OSes have you booted successfully?

Stefan

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

[Stefan Hajnoczi]

On Wed, Aug 30, 2017 at 03:07:38PM +0100, Daniel P. Berrange wrote:
> On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real wrote:
> > diff --git a/target/i386/hvf-utils/x86.c b/target/i386/hvf-utils/x86.c
> > new file mode 100644
> > index 00..e3db2c9c8b
> > --- /dev/null
> > +++ b/target/i386/hvf-utils/x86.c
> > @@ -0,0 +1,174 @@
> > +/*
> > + * Copyright (C) 2016 Veertu Inc,
> > + * Copyright (C) 2017 Google Inc,
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 or
> > + * (at your option) version 3 of the License.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License along
> > + * with this program; if not, see .
> > + */
> 
> Again  v2-or-v3-only.
> 
> There's many more files with this same problem but I'll stop pointing
> them out now.
> 
> If this is to be included in QEMU,  Veertu & Google (and any other
> copyright holders) would have to agree to change these files to
> v2-or-later

Sergio: Have you or Paolo had any contact with the Veertu or Google
authors about your Hypervisor.framework project?  If you're already in
contact with them you could raise the issue and ask them to join this
email thread.

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

[Daniel P. Berrange]

On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real wrote:
> This file begins tracking the files that will be the code base for HVF
> support in QEMU. This code base is part of Google's QEMU version of
> their Android emulator, and can be found at
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev
> 
> This code is based on Veertu Inc's vdhh (Veertu Desktop Hosted
> Hypervisor), found at https://github.com/veertuinc/vdhh. Everything is
> appropriately licensed under GPL v2.

The licensing seems a little more complicated than that

Per the QEMU LICENSE file new contributions must be  GPL v2-or-later


> diff --git a/target/i386/hvf-all.c b/target/i386/hvf-all.c
> new file mode 100644
> index 00..0a1a5134f8
> --- /dev/null
> +++ b/target/i386/hvf-all.c
> @@ -0,0 +1,999 @@
> +// Copyright 2008 IBM Corporation
> +//   2008 Red Hat, Inc.
> +// Copyright 2011 Intel Corporation
> +// Copyright 2016 Veertu, Inc.
> +// Copyright 2017 The Android Open Source Project
> +// 
> +// QEMU Hypervisor.framework support
> +// 
> +// This software is licensed under the terms of the GNU General Public
> +// License version 2, as published by the Free Software Foundation, and
> +// may be copied, distributed, and modified under those terms.
> +// 
> +// This program is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +// GNU General Public License for more details.

This is v2-only.

If this v2-only license is inherited due to the file being derived
from another pre-existing file in QEMU that was v2-only, we could
possibly make an exception to allow another v2-only file in tree.
Preferably it should be v2-or-later though.

> diff --git a/target/i386/hvf-utils/vmcs.h b/target/i386/hvf-utils/vmcs.h
> new file mode 100644
> index 00..6f7ccb361a
> --- /dev/null
> +++ b/target/i386/hvf-utils/vmcs.h
> @@ -0,0 +1,368 @@
> +/*-
> + * Copyright (c) 2011 NetApp, Inc.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY NETAPP, INC ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL NETAPP, INC OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + *
> + * $FreeBSD$
> + */

A BSD license variant. OK since its GPL compatible and just a header file
copied from a 3rd party project.

> diff --git a/target/i386/hvf-utils/vmx.h b/target/i386/hvf-utils/vmx.h
> new file mode 100644
> index 00..8a080e6777
> --- /dev/null
> +++ b/target/i386/hvf-utils/vmx.h
> @@ -0,0 +1,200 @@
> +/*
> + * Copyright (C) 2016 Veertu Inc,
> + * Copyright (C) 2017 Google Inc,
> + * Based on Veertu vddh/vmm/vmx.h
> + *
> + * Interfaces to Hypervisor.framework to read/write X86 registers and VMCS.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 or
> + * (at your option) version 3 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */

This is  v2-or-v3-only, which is not OK for QEMU.

It needs to be v2-or-later



> diff --git a/target/i386/hvf-utils/x86.c b/target/i386/hvf-utils/x86.c
> new file mode 100644
> index 00..e3db2c9c8b
> --- /dev/null
> +++ b/target/i386/hvf-utils/x86.c
> @@ -0,0 +1,174 @@
> +/*
> + * Copyright (C) 2016 Veertu Inc,
> + *