add support for Hypervisor.framework in QEMU

This patch adds to the configure script the code to support the --enable-hvf argument. If the OS is Darwin, it checks for presence of HVF in the system. The patch also adds strings related to HVF in the file qemu-options.hx.
QEMU will only support the modern syntax style '-M accel=hvf' no enable hvf; the legacy '-enable-hvf' will not be supported.

Signed-off-by Sergio Andres Gomez Del Real <[email protected]>

---
 configure       | 38 ++++++++++++++++++++++++++++++++++++++
 qemu-options.hx | 10 +++++-----
 2 files changed, 43 insertions(+), 5 deletions(-)

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.

target/i386/hvf-all.c new file +6 -0

new file mode 100644
index 0000000000..0a1a5134f8
@@ -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
+// 

target/i386/hvf-utils/vmcs.h new file +17 -0

new file mode 100644
index 0000000000..6f7ccb361a
@@ -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

target/i386/hvf-utils/vmx.h new file +10 -0

new file mode 100644
index 0000000000..8a080e6777
@@ -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

target/i386/hvf-utils/x86.c new file +7 -0

new file mode 100644
index 0000000000..e3db2c9c8b
@@ -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

Quoted 13 lines · Sergio Andres Gomez Del Real

target/i386/hvf-utils/x86.c new file +7 -0

new file mode 100644
index 0000000000..e3db2c9c8b
@@ -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

target/i386/hvf-utils/x86.c line 17

Quoted 10 lines

target/i386/hvf-utils/x86.c new file +10 -0

+ * (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 <http://www.gnu.org/licenses/>.
+ */

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

On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real

Quoted 13 lines

target/i386/hvf-utils/x86.c new file +7 -0

new file mode 100644
index 0000000000..e3db2c9c8b
@@ -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

target/i386/hvf-utils/x86.c line 15

Quoted 8 lines

target/i386/hvf-utils/x86.c new file +8 -0

+ * (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

target/i386/hvf-utils/x86.c line 17

Quoted 2 lines

target/i386/hvf-utils/x86.c new file +2 -0

+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */

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

Il 31 ago 2017 9:43 AM, "Stefan Hajnoczi" <[email protected]> ha scritto:

Quoted 1 line · Daniel P. Berrange

On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real

Quoted 13 lines · wrote:

Quoted 13 lines

target/i386/hvf-utils/x86.c new file +7 -0

new file mode 100644
index 0000000000..e3db2c9c8b
@@ -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

Quoted 8 lines

target/i386/hvf-utils/x86.c line 15

Quoted 8 lines

target/i386/hvf-utils/x86.c new file +8 -0

+ * (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

Quoted 11 lines

target/i386/hvf-utils/x86.c line 17

Quoted 2 lines

target/i386/hvf-utils/x86.c new file +2 -0

+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */

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

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

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

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 15 lines

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

Quoted 14 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 42 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 9 lines

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.

Quoted 8 lines

Quoted 5 lines

Stefan

Quoted 8 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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

Hi,

Quoted 8 lines

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

Quoted 3 lines

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

Quoted 5 lines

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

want to make sure that I fix this before and that all others are fine.

Thanks.

Quoted 42 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 9 lines

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.

Quoted 8 lines

Quoted 5 lines

Stefan

Il 03 set 2017 6:17 PM, "Izik Eidus" <[email protected]> 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.

Quoted 8 lines · Izik Eidus

Quoted 3 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 1 line

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

Quoted 7 lines

Quoted 7 lines

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

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 3 lines

Quoted 3 lines

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

Quoted 11 lines

Quoted 5 lines

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

Quoted 10 lines

want to make sure that I fix this before and that all others are fine.

Thanks.

Quoted 5 lines

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

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow guests

to

Quoted 14 lines

Quoted 14 lines

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)

Quoted 8 lines

Quoted 8 lines

What do you guys think?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 7 lines

Quoted 7 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 4 lines

LGPL or GPLv2+.

Thanks,

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

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,

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

Stefan

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

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.

Quoted 8 lines · Izik Eidus

Quoted 3 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 1 line

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 11 lines

Quoted 11 lines

Quoted 2 lines

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.

Quoted 1 line

Quoted 1 line

That's not necessary. Just you and Vincent replying to this thread with

a

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 1 line

Quoted 1 line

his v3 submission. Sergio already made some non-trivial changes that

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

Quoted 6 lines

Quoted 2 lines

was written by Veertu).

Hi,

Sure fine with us, let me go over all the code and see that all

Quoted 2 lines

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

Quoted 6 lines

want to make sure that I fix this before and that all others are fine.

Thanks.

Quoted 1 line

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow guests

to

Quoted 19 lines

Quoted 19 lines

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?

Quoted 2 lines

Sergio worked on completing the QEMU port to Hypervisor.framework.

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

Quoted 9 lines

Quoted 9 lines

be

Quoted 8 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever want

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

rebase on qemu.git there will be less work for them.

OK,

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

Stefan

Il 03 set 2017 6:54 PM, "Izik Eidus" <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> ha scritto:

Quoted 2 lines

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

Quoted 5 lines

Paolo

in
such case all copyright go back to BSD2 and we can license it as GPL2v+

or

Quoted 15 lines

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 <[email protected]

Quoted 4 lines · <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:

Quoted 4 lines

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>>

Quoted 3 lines

Quoted 3 lines

Quoted 1 line · wrote:

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>> ha scritto:

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

What I suggest is that we will send our patch' again as gpl2+ and

clean

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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

Quoted 4 lines

a

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 1 line

Quoted 1 line

his v3 submission. Sergio already made some non-trivial changes that

are

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

rest

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

was written by Veertu).

Hi,

Sure fine with us, let me go over all the code and see that all

copyright

Quoted 10 lines

Quoted 2 lines

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

Quoted 7 lines

want to make sure that I fix this before and that all others are fine.

Thanks.

Quoted 2 lines

Google has already contributed the HAXN accelerator, so I am

moderately

Quoted 18 lines

Quoted 3 lines

Quoted 3 lines

optimistic that they can help with HVF too.

BTW, another thing that need to be integrated in order to make this

stuff

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow guests

to

Quoted 12 lines

Quoted 12 lines

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

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

without root)

What do you guys think?

Quoted 2 lines

Sergio worked on completing the QEMU port to Hypervisor.framework.

The

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

could

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

be

Quoted 8 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever want

to

Quoted 18 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

rebase on qemu.git there will be less work for them.

OK,

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

Stefan

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

rest, can be moved to a separate file for the time being.

Paolo

Quoted 1 line

Quoted 4 lines

Paolo

in
such case all copyright go back to BSD2 and we can license it as GPL2v+

or

Quoted 8 lines

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

Quoted 7 lines

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 <[email protected]

Quoted 4 lines · <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:

Quoted 4 lines

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>>

Quoted 3 lines

Quoted 3 lines

Quoted 1 line · wrote:

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>> ha scritto:

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

What I suggest is that we will send our patch' again as gpl2+ and

clean

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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

Quoted 4 lines

a

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 1 line

Quoted 1 line

his v3 submission. Sergio already made some non-trivial changes that

are

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

rest

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

was written by Veertu).

Hi,

Sure fine with us, let me go over all the code and see that all

copyright

Quoted 3 lines

Quoted 2 lines

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

Quoted 7 lines

Quoted 7 lines

want to make sure that I fix this before and that all others are fine.

Thanks.

Quoted 2 lines

Google has already contributed the HAXN accelerator, so I am

moderately

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

optimistic that they can help with HVF too.

BTW, another thing that need to be integrated in order to make this

stuff

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow

Quoted 6 lines

to

Quoted 5 lines

Quoted 5 lines

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

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

without root)

What do you guys think?

Quoted 2 lines

Sergio worked on completing the QEMU port to Hypervisor.framework.

The

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

could

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

be

Quoted 8 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever want

to

Quoted 18 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

rebase on qemu.git there will be less work for them.

OK,

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

Stefan

Il 03 set 2017 8:49 PM, "Izik Eidus" <[email protected]> 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

Quoted 5 lines

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.

Quoted 149 lines

Paolo

Quoted 5 lines

Paolo

in
such case all copyright go back to BSD2 and we can license it as GPL2v+

or

Quoted 15 lines

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 <[email protected]

Quoted 4 lines · <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:

Quoted 4 lines

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>>

Quoted 3 lines

Quoted 3 lines

Quoted 1 line · wrote:

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>> ha scritto:

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

What I suggest is that we will send our patch' again as gpl2+ and

clean

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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

Quoted 4 lines

a

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 1 line

Quoted 1 line

his v3 submission. Sergio already made some non-trivial changes that

are

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

rest

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

was written by Veertu).

Hi,

Sure fine with us, let me go over all the code and see that all

copyright

Quoted 10 lines

Quoted 2 lines

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

Quoted 7 lines

want to make sure that I fix this before and that all others are fine.

Thanks.

Quoted 2 lines

Google has already contributed the HAXN accelerator, so I am

moderately

Quoted 18 lines

Quoted 3 lines

Quoted 3 lines

optimistic that they can help with HVF too.

BTW, another thing that need to be integrated in order to make this

stuff

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow guests

to

Quoted 12 lines

Quoted 12 lines

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

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

without root)

What do you guys think?

Quoted 2 lines

Sergio worked on completing the QEMU port to Hypervisor.framework.

The

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

could

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

be

Quoted 8 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever want

to

Quoted 18 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

rebase on qemu.git there will be less work for them.

OK,

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

Stefan

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

Thanks,

Paolo

Quoted 3 lines

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

Quoted 2 lines

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

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.

Quoted 9 lines

Paolo

Quoted 5 lines

Paolo

in
such case all copyright go back to BSD2 and we can license it as

Quoted 4 lines

or

Quoted 3 lines

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

Quoted 1 line

Quoted 1 line

the hypervisor framework from Anka (in kvm user space style) - this

Quoted 1 line

Quoted 1 line

put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port

Quoted 3 lines

Quoted 3 lines

rest of Sergio changes to this stuff.

I know this is less than ideal as it requires some changes to the

Quoted 1 line

Quoted 1 line

patch set, however it will make it 100% safe to be GPL2v+, what you

Quoted 32 lines

Quoted 6 lines

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 <[email protected]

Quoted 4 lines · <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:

Quoted 4 lines

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>>

Quoted 3 lines

Quoted 3 lines

Quoted 1 line · wrote:

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>> ha scritto:

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

What I suggest is that we will send our patch' again as gpl2+ and

clean

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

the
entire stuff to make sure they are falling into the right copyright category as required by QEMU.

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

That's not necessary. Just you and Vincent replying to this thread

with

Quoted 4 lines

a

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 1 line

Quoted 1 line

his v3 submission. Sergio already made some non-trivial changes

Quoted 9 lines

are

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

rest

Quoted 8 lines

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

was written by Veertu).

Hi,

Sure fine with us, let me go over all the code and see that all

copyright

Quoted 1 line

Quoted 1 line

that are needed are there, and then you can relicense all our code

Quoted 1 line

Quoted 1 line

Quoted 1 line

GPLv2+, I think I saw a a file that was missing Bochs copyright in

Quoted 2 lines

Quoted 2 lines

so I

Quoted 1 line

want to make sure that I fix this before and that all others are

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Thanks.

Quoted 1 line

Quoted 7 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Google has already contributed the HAXN accelerator, so I am

moderately

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

optimistic that they can help with HVF too.

BTW, another thing that need to be integrated in order to make this

stuff

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow

Quoted 5 lines

Quoted 5 lines

to

Quoted 4 lines

Quoted 4 lines

have networking...

People can always use slirp (or tap with some more effort), so

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

patches are already a minimum viable feature and pretty close to

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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

Quoted 8 lines

run

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

without root)

What do you guys think?

Quoted 2 lines

Sergio worked on completing the QEMU port to

Quoted 4 lines

The

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The

Quoted 5 lines

Quoted 3 lines

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

could

Quoted 1 line

Quoted 1 line

Quoted 1 line

be

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever

Quoted 22 lines

to

Quoted 18 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

rebase on qemu.git there will be less work for them.

OK,

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

Stefan

Il 06 set 2017 3:29 PM, "Izik Eidus" <[email protected]> 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.

Quoted 196 lines

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

Thanks,

Paolo

Quoted 6 lines

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.

Quoted 165 lines

Paolo

Quoted 6 lines

Paolo

in
such case all copyright go back to BSD2 and we can license it as GPL2v+

or

Quoted 20 lines

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 <[email protected]

Quoted 4 lines · <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:

Quoted 4 lines

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>>

Quoted 3 lines

Quoted 3 lines

Quoted 1 line · wrote:

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]

<javascript:_e(%7B%7D,'cvml','[email protected]');>> ha scritto:

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

What I suggest is that we will send our patch' again as gpl2+ and

clean

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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

Quoted 5 lines

a

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 2 lines

Quoted 2 lines

his v3 submission. Sergio already made some non-trivial changes that

are

Quoted 5 lines

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

rest

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

was written by Veertu).

Hi,

Sure fine with us, let me go over all the code and see that all

copyright

Quoted 4 lines

Quoted 4 lines

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,

Quoted 9 lines

so I

Quoted 8 lines

want to make sure that I fix this before and that all others are fine.

Thanks.

Quoted 2 lines

Google has already contributed the HAXN accelerator, so I am

moderately

Quoted 21 lines

Quoted 3 lines

Quoted 3 lines

optimistic that they can help with HVF too.

BTW, another thing that need to be integrated in order to make this

stuff

Quoted 2 lines

Quoted 2 lines

useful is the vmnet patch's, it is apple NAT for vms that allow guests

to

Quoted 14 lines

Quoted 14 lines

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

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

without root)

What do you guys think?

Quoted 3 lines

Sergio worked on completing the QEMU port to
Hypervisor.framework.

The

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 2 lines

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

could

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

be

Quoted 9 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever want

to

Quoted 18 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

rebase on qemu.git there will be less work for them.

OK,

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

Stefan

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 15 lines

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

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.

Quoted 36 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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!

Quoted 36 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 14 lines

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

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

Quoted 48 lines · 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.

Quoted 32 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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

Quoted 5 lines

Quoted 4 lines

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.

Quoted 39 lines

Quoted 38 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 14 lines

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

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

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.

Quoted 71 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 14 lines

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

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.

Quoted 16 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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

Quoted 3 lines

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

Quoted 52 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 14 lines

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

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

Quoted 11 lines · 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.

Quoted 8 lines

Thank you.

Quoted 3 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 1 line

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

Quoted 7 lines

Quoted 7 lines

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

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 3 lines

Quoted 3 lines

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

Quoted 9 lines

Quoted 9 lines

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

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow guests

to

Quoted 14 lines

Quoted 14 lines

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)

Quoted 8 lines

Quoted 8 lines

What do you guys think?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 21 lines

Quoted 20 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they could

be

Quoted 14 lines

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

Quoted 26 lines · Paolo Bonzini

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

Quoted 8 lines

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.

Quoted 116 lines

Paolo

Thanks.

Quoted 11 lines · 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.

Quoted 8 lines

Thank you.

Quoted 3 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 1 line

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 5 lines

Quoted 5 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

Quoted 7 lines

Quoted 7 lines

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

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 1 line

Quoted 1 line

his v3 submission. Sergio already made some non-trivial changes that

are

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

rest

Quoted 6 lines

Quoted 6 lines

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

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow guests

to

Quoted 14 lines

Quoted 14 lines

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)

Quoted 5 lines

Quoted 5 lines

What do you guys think?

Quoted 2 lines

Sergio worked on completing the QEMU port to Hypervisor.framework.

The

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

could

Quoted 9 lines

Quoted 9 lines

be

Quoted 8 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever want

to

Quoted 10 lines

Quoted 9 lines

Quoted 6 lines

rebase on qemu.git there will be less work for them.

Stefan

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.

Quoted 169 lines · Izik Eidus

Quoted 26 lines · Paolo Bonzini

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

Quoted 8 lines

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.

Quoted 124 lines

Paolo

Thanks.

Quoted 4 lines · 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

Quoted 1 line

files (their being GPL v2-only). Paolo from Red Hat was asking to

Veertu

Quoted 1 line

developer Izik Eidus if the code in Veertu derived only from QEMU,

Bochs

Quoted 1 line

and other GPLv2+ or LGPL software. Because the code at Google was

itself

Quoted 1 line

derived from Veertu, I'd imagine the same licensing terms would apply

in

Quoted 11 lines

your case. Any light you can throw over this issue would be much appreciated.

Thank you.

Quoted 3 lines · Paolo Bonzini

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 1 line

Izik, Vincent (assuming you are the right person to contact at

Google),

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

can you reply to Daniel and Stefan?

Hi,

What I suggest is that we will send our patch' again as gpl2+ and

clean

Quoted 6 lines

Quoted 6 lines

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

Quoted 1 line

Quoted 1 line

"Signed-off-by" line would be enough for Sergio to use the right

license in

Quoted 1 line

Quoted 1 line

his v3 submission. Sergio already made some non-trivial changes that

are

Quoted 2 lines

Quoted 2 lines

needed for inclusion in QEMU from a supportability (e.g. dirty page tracking for graphics) or maintainability perspective (e.g. -cpu

support),

Quoted 2 lines

Quoted 2 lines

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

Quoted 1 line

Quoted 1 line

came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the

rest

Quoted 3 lines

Quoted 3 lines

was written by Veertu).

Google has already contributed the HAXN accelerator, so I am

moderately

Quoted 3 lines

Quoted 3 lines

optimistic that they can help with HVF too.

BTW, another thing that need to be integrated in order to make this

stuff

Quoted 1 line

Quoted 1 line

useful is the vmnet patch's, it is apple NAT for vms that allow

guests to

Quoted 7 lines

Quoted 7 lines

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!

Quoted 5 lines

Quoted 5 lines

Paolo

(altho that it come with a trick, without certificate it will require root permission, while hypverisor framework itself can

run

Quoted 7 lines

Quoted 7 lines

without root)

What do you guys think?

Quoted 2 lines

Sergio worked on completing the QEMU port to Hypervisor.framework.

The

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

hvf-all.c file that Daniel pointed out as v2-only is derived from

kvm-all.c

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others

seem

Quoted 2 lines

Quoted 2 lines

to

Quoted 1 line

be either original or derived from Bochs, which is LGPL, so they

could

Quoted 9 lines

Quoted 9 lines

be

Quoted 8 lines

LGPL or GPLv2+.

Thanks,

Paolo

There are benefits to having this code upstream. If they ever want

to

Quoted 10 lines

Quoted 9 lines

Quoted 6 lines

rebase on qemu.git there will be less work for them.

Stefan

Il 31 ago 2017 3:54 PM, "Izik Eidus" <[email protected]> ha scritto:

Quoted 3 lines

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?

Quoted 3 lines

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

Quoted 1 line

and hax-all.c, and should be under v2-or-later license. The others seem

to

Quoted 15 lines

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

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 <[email protected]>

---

This commit adds to target/i386/Makefile.objs the necessary rules so that the new files for hvf are compiled by the build system. It also adds handling of the -enable-hvf argument in the main function in vl.c.

Signed-off-by Sergio Andres Gomez Del Real <[email protected]>

---
 target/i386/Makefile.objs | 1 +
 1 file changed, 1 insertion(+)

target/i386/Makefile.objs +0 -0

index 6a26e9d9f0..0bef89c099 100644

This commit adds to target/i386/Makefile.objs the necessary rules so that the new files for hvf are compiled by the build system. It also adds handling of the -enable-hvf argument in the main function in vl.c.

Signed-off-by Sergio Andres Gomez Del Real <[email protected]>

---
 target/i386/Makefile.objs | 1 +
 1 file changed, 1 insertion(+)

target/i386/Makefile.objs +0 -0

index 6a26e9d9f0..0bef89c099 100644

This commit adds some fields specific to hvf in CPUState and CPUX86State. It also adds some handy #defines.

Signed-off-by Sergio Andres Gomez Del Real <[email protected]>

---
 include/qom/cpu.h |  2 ++
 target/i386/cpu.h | 23 +++++++++++++++++++++++
 2 files changed, 25 insertions(+)

This commit adds the function apic_get_highest_priority_irr to apic.c and exports it through the interface in apic.h for use by hvf.

Signed-off-by Sergio Andres Gomez Del Real <[email protected]>

---
 hw/intc/apic.c         | 11 +++++++++++
 include/hw/i386/apic.h |  1 +
 2 files changed, 12 insertions(+)

hw/intc/apic.c +0 -0

index fe15fb6024..3de59d07fd 100644