QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
@ 2019-09-19 10:59 Philippe Mathieu-Daudé
  2019-09-19 10:59 ` [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
                   ` (3 more replies)
  0 siblings, 4 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 10:59 UTC (permalink / raw)
  To: qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Philippe Mathieu-Daudé,
	Justin Terry, Stefan Weil, Alex Bennée, Ilias Maratos

Add a job to cross-build QEMU with WHPX enabled.

Use the Win10SDK headers from the Android Project, as commented
in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html

Based-on: <20190918121101.30690-1-philmd@redhat.com>
https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html

Philippe Mathieu-Daudé (2):
  tests/docker: Add fedora-win10sdk-cross image
  .shippable.yml: Build WHPX enabled binaries

 .shippable.yml                                |  2 ++
 tests/docker/Makefile.include                 |  1 +
 .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
 3 files changed, 24 insertions(+)
 create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker

-- 
2.20.1



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image
  2019-09-19 10:59 [Qemu-devel] [PATCH 0/2] " Philippe Mathieu-Daudé
@ 2019-09-19 10:59 ` Philippe Mathieu-Daudé
  2019-09-19 11:28   ` Alex Bennée
  2019-09-19 10:59 ` [Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries Philippe Mathieu-Daudé
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 10:59 UTC (permalink / raw)
  To: qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Philippe Mathieu-Daudé,
	Justin Terry, Stefan Weil, Alex Bennée, Ilias Maratos

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 tests/docker/Makefile.include                 |  1 +
 .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
 2 files changed, 22 insertions(+)
 create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 50a400b573..0df72a810b 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -125,6 +125,7 @@ docker-image-debian-ppc64-cross: docker-image-debian10
 docker-image-debian-riscv64-cross: docker-image-debian10
 docker-image-debian-sh4-cross: docker-image-debian10
 docker-image-debian-sparc64-cross: docker-image-debian10
+docker-image-fedora-win10sdk-cross: docker-image-fedora
 
 docker-image-travis: NOUSER=1
 
diff --git a/tests/docker/dockerfiles/fedora-win10sdk-cross.docker b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
new file mode 100644
index 0000000000..1aafdad483
--- /dev/null
+++ b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
@@ -0,0 +1,21 @@
+#
+# Docker MinGW64 cross-compiler target with WHPX header installed
+#
+# This docker target builds on the Fedora 30 base image.
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+FROM qemu:fedora
+
+# Install headers extracted by the Android folks from the win10sdk.iso:
+# https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
+ENV WIN10SDK_INCDIR /usr/local/include/win10sdk
+RUN mkdir ${WIN10SDK_INCDIR} && \
+    for hdr in WinHvEmulation.h WinHvPlatformDefs.h WinHvPlatform.h; do \
+        curl -s "https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/+/1bde9c3b14f3a3b081ada6e32da9f2870671b46f/x86_64-w64-mingw32/include/${hdr}?format=TEXT" | base64 --decode > ${WIN10SDK_INCDIR}/${hdr}; \
+    done
+
+ENV QEMU_CONFIGURE_OPTS ${QEMU_CONFIGURE_OPTS} \
+    --cross-prefix=x86_64-w64-mingw32- \
+    --extra-cflags="-I ${WIN10SDK_INCDIR}" --disable-werror \
+    --enable-hax --enable-whpx
-- 
2.20.1



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries
  2019-09-19 10:59 [Qemu-devel] [PATCH 0/2] " Philippe Mathieu-Daudé
  2019-09-19 10:59 ` [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
@ 2019-09-19 10:59 ` Philippe Mathieu-Daudé
  2019-09-19 11:02   ` Philippe Mathieu-Daudé
  2019-09-19 11:09 ` [Qemu-devel] [PATCH 0/2] testing: " Thomas Huth
  2019-09-19 11:18 ` Stefan Weil
  3 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 10:59 UTC (permalink / raw)
  To: qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Philippe Mathieu-Daudé,
	Justin Terry, Stefan Weil, Alex Bennée, Ilias Maratos

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 .shippable.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.shippable.yml b/.shippable.yml
index bbc6f88510..01b33bd034 100644
--- a/.shippable.yml
+++ b/.shippable.yml
@@ -25,6 +25,8 @@ env:
       TARGET_LIST=mips64el-softmmu,mips64el-linux-user
     - IMAGE=debian-ppc64el-cross
       TARGET_LIST=ppc64-softmmu,ppc64-linux-user,ppc64abi32-linux-user
+    - IMAGE=fedora-win10sdk-cross
+      TARGET_LIST=x86_64-softmmu,i386-softmmu
 build:
   pre_ci:
     # usually host ARCH is set by configure
-- 
2.20.1



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries
  2019-09-19 10:59 ` [Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries Philippe Mathieu-Daudé
@ 2019-09-19 11:02   ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 11:02 UTC (permalink / raw)
  To: qemu-devel, Alex Bennée
  Cc: Fam Zheng, Stefan Weil, Lucian Petrut, Ilias Maratos, Justin Terry

On 9/19/19 12:59 PM, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  .shippable.yml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/.shippable.yml b/.shippable.yml
> index bbc6f88510..01b33bd034 100644
> --- a/.shippable.yml
> +++ b/.shippable.yml
> @@ -25,6 +25,8 @@ env:
>        TARGET_LIST=mips64el-softmmu,mips64el-linux-user
>      - IMAGE=debian-ppc64el-cross
>        TARGET_LIST=ppc64-softmmu,ppc64-linux-user,ppc64abi32-linux-user
> +    - IMAGE=fedora-win10sdk-cross
> +      TARGET_LIST=x86_64-softmmu,i386-softmmu

Note for Alex, if this patch is accepted, I think we can remove
x86_64-softmmu from TARGET_LIST in the debian-win64-cross job, since
this one duplicates it (and even covers more).

>  build:
>    pre_ci:
>      # usually host ARCH is set by configure
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 10:59 [Qemu-devel] [PATCH 0/2] " Philippe Mathieu-Daudé
  2019-09-19 10:59 ` [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
  2019-09-19 10:59 ` [Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries Philippe Mathieu-Daudé
@ 2019-09-19 11:09 ` Thomas Huth
  2019-09-19 11:21   ` Philippe Mathieu-Daudé
  2019-09-19 11:18 ` Stefan Weil
  3 siblings, 1 reply; 65+ messages in thread
From: Thomas Huth @ 2019-09-19 11:09 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Stefan Weil, Justin Terry,
	Alex Bennée, Ilias Maratos

On 19/09/2019 12.59, Philippe Mathieu-Daudé wrote:
> Add a job to cross-build QEMU with WHPX enabled.
> 
> Use the Win10SDK headers from the Android Project, as commented
> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
> 
> Based-on: <20190918121101.30690-1-philmd@redhat.com>
> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
> 
> Philippe Mathieu-Daudé (2):
>   tests/docker: Add fedora-win10sdk-cross image
>   .shippable.yml: Build WHPX enabled binaries
> 
>  .shippable.yml                                |  2 ++
>  tests/docker/Makefile.include                 |  1 +
>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>  3 files changed, 24 insertions(+)
>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker

Don't you want to include a fix for the #include "hw/boards.h" problem
in your series? ... or is it not happening with your builds here?

 Thomas


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 10:59 [Qemu-devel] [PATCH 0/2] " Philippe Mathieu-Daudé
                   ` (2 preceding siblings ...)
  2019-09-19 11:09 ` [Qemu-devel] [PATCH 0/2] testing: " Thomas Huth
@ 2019-09-19 11:18 ` Stefan Weil
  2019-09-19 11:26   ` Philippe Mathieu-Daudé
  2019-09-19 11:41   ` [Qemu-devel] " Daniel P. Berrangé
  3 siblings, 2 replies; 65+ messages in thread
From: Stefan Weil @ 2019-09-19 11:18 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Alex Bennée, Ilias Maratos, Justin Terry

Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
> Add a job to cross-build QEMU with WHPX enabled.
>
> Use the Win10SDK headers from the Android Project, as commented
> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
>
> Based-on: <20190918121101.30690-1-philmd@redhat.com>
> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
>
> Philippe Mathieu-Daudé (2):
>   tests/docker: Add fedora-win10sdk-cross image
>   .shippable.yml: Build WHPX enabled binaries
>
>  .shippable.yml                                |  2 ++
>  tests/docker/Makefile.include                 |  1 +
>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>  3 files changed, 24 insertions(+)
>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>

Please note that the required header files are part of the Win10SDK
which is not published under a free license, so I am afraid that they
cannot be used with QEMU code to produce free binaries.

I have addressed that some time ago, and Justin Terry is still looking
for a solution on the Microsoft side.

Regards,
Stefan Weil




^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 11:09 ` [Qemu-devel] [PATCH 0/2] testing: " Thomas Huth
@ 2019-09-19 11:21   ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 11:21 UTC (permalink / raw)
  To: Thomas Huth, qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Stefan Weil, Justin Terry,
	Alex Bennée, Ilias Maratos

On 9/19/19 1:09 PM, Thomas Huth wrote:
> On 19/09/2019 12.59, Philippe Mathieu-Daudé wrote:
>> Add a job to cross-build QEMU with WHPX enabled.
>>
>> Use the Win10SDK headers from the Android Project, as commented
>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
>>
>> Based-on: <20190918121101.30690-1-philmd@redhat.com>
>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
>>
>> Philippe Mathieu-Daudé (2):
>>   tests/docker: Add fedora-win10sdk-cross image
>>   .shippable.yml: Build WHPX enabled binaries
>>
>>  .shippable.yml                                |  2 ++
>>  tests/docker/Makefile.include                 |  1 +
>>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>>  3 files changed, 24 insertions(+)
>>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
> 
> Don't you want to include a fix for the #include "hw/boards.h" problem
> in your series? ... or is it not happening with your builds here?

Ah Based-on is for Patchew, and this series need to be tested by
Shippable... you are right.
Well, this is a good opportunity to see the job catch the WHPX failure
reported :)


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 11:18 ` Stefan Weil
@ 2019-09-19 11:26   ` Philippe Mathieu-Daudé
  2020-05-20 10:25     ` Philippe Mathieu-Daudé
  2019-09-19 11:41   ` [Qemu-devel] " Daniel P. Berrangé
  1 sibling, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 11:26 UTC (permalink / raw)
  To: Stefan Weil, qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Alex Bennée, Ilias Maratos, Justin Terry

On 9/19/19 1:18 PM, Stefan Weil wrote:
> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
>> Add a job to cross-build QEMU with WHPX enabled.
>>
>> Use the Win10SDK headers from the Android Project, as commented
>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
>>
>> Based-on: <20190918121101.30690-1-philmd@redhat.com>
>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
>>
>> Philippe Mathieu-Daudé (2):
>>   tests/docker: Add fedora-win10sdk-cross image
>>   .shippable.yml: Build WHPX enabled binaries
>>
>>  .shippable.yml                                |  2 ++
>>  tests/docker/Makefile.include                 |  1 +
>>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>>  3 files changed, 24 insertions(+)
>>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>>
> 
> Please note that the required header files are part of the Win10SDK
> which is not published under a free license, so I am afraid that they
> cannot be used with QEMU code to produce free binaries.

Yes :S

> I have addressed that some time ago, and Justin Terry is still looking
> for a solution on the Microsoft side.

Oh this is a good news, thanks for caring about this issue,
and thanks Justin for looking for a solution!

Trying to understand how WHPX is used, I noticed there are much many
Windows QEMU users than I thought, and it would be nice if we can have
some upstream CI testing to not break the various projects using it.

Regards,

Phil.



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image
  2019-09-19 10:59 ` [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
@ 2019-09-19 11:28   ` Alex Bennée
  2019-09-19 11:35     ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Alex Bennée @ 2019-09-19 11:28 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Fam Zheng, Lucian Petrut, Stefan Weil, qemu-devel, Justin Terry,
	Ilias Maratos


Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  tests/docker/Makefile.include                 |  1 +
>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>  2 files changed, 22 insertions(+)
>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>
> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
> index 50a400b573..0df72a810b 100644
> --- a/tests/docker/Makefile.include
> +++ b/tests/docker/Makefile.include
> @@ -125,6 +125,7 @@ docker-image-debian-ppc64-cross: docker-image-debian10
>  docker-image-debian-riscv64-cross: docker-image-debian10
>  docker-image-debian-sh4-cross: docker-image-debian10
>  docker-image-debian-sparc64-cross: docker-image-debian10
> +docker-image-fedora-win10sdk-cross: docker-image-fedora
>
>  docker-image-travis: NOUSER=1
>
> diff --git a/tests/docker/dockerfiles/fedora-win10sdk-cross.docker b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
> new file mode 100644
> index 0000000000..1aafdad483
> --- /dev/null
> +++ b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
> @@ -0,0 +1,21 @@
> +#
> +# Docker MinGW64 cross-compiler target with WHPX header installed
> +#
> +# This docker target builds on the Fedora 30 base image.
> +#
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +#
> +FROM qemu:fedora
> +
> +# Install headers extracted by the Android folks from the win10sdk.iso:
> +# https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
> +ENV WIN10SDK_INCDIR /usr/local/include/win10sdk
> +RUN mkdir ${WIN10SDK_INCDIR} && \
> +    for hdr in WinHvEmulation.h WinHvPlatformDefs.h WinHvPlatform.h; do \
> +        curl -s "https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/+/1bde9c3b14f3a3b081ada6e32da9f2870671b46f/x86_64-w64-mingw32/include/${hdr}?format=TEXT" | base64 --decode > ${WIN10SDK_INCDIR}/${hdr}; \
> +    done

Hmm I guess this is a stable URL as Google never deletes anything?

> +
> +ENV QEMU_CONFIGURE_OPTS ${QEMU_CONFIGURE_OPTS} \
> +    --cross-prefix=x86_64-w64-mingw32- \
> +    --extra-cflags="-I ${WIN10SDK_INCDIR}" --disable-werror \
> +    --enable-hax --enable-whpx


--
Alex Bennée


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image
  2019-09-19 11:28   ` Alex Bennée
@ 2019-09-19 11:35     ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 11:35 UTC (permalink / raw)
  To: Alex Bennée
  Cc: Fam Zheng, Thomas Huth, Lucian Petrut, Stefan Weil, qemu-devel,
	Justin Terry, Ilias Maratos

On 9/19/19 1:28 PM, Alex Bennée wrote:
> 
> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> 
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>  tests/docker/Makefile.include                 |  1 +
>>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>>  2 files changed, 22 insertions(+)
>>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>>
>> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
>> index 50a400b573..0df72a810b 100644
>> --- a/tests/docker/Makefile.include
>> +++ b/tests/docker/Makefile.include
>> @@ -125,6 +125,7 @@ docker-image-debian-ppc64-cross: docker-image-debian10
>>  docker-image-debian-riscv64-cross: docker-image-debian10
>>  docker-image-debian-sh4-cross: docker-image-debian10
>>  docker-image-debian-sparc64-cross: docker-image-debian10
>> +docker-image-fedora-win10sdk-cross: docker-image-fedora
>>
>>  docker-image-travis: NOUSER=1
>>
>> diff --git a/tests/docker/dockerfiles/fedora-win10sdk-cross.docker b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>> new file mode 100644
>> index 0000000000..1aafdad483
>> --- /dev/null
>> +++ b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>> @@ -0,0 +1,21 @@
>> +#
>> +# Docker MinGW64 cross-compiler target with WHPX header installed
>> +#
>> +# This docker target builds on the Fedora 30 base image.
>> +#
>> +# SPDX-License-Identifier: GPL-2.0-or-later
>> +#
>> +FROM qemu:fedora
>> +
>> +# Install headers extracted by the Android folks from the win10sdk.iso:
>> +# https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
>> +ENV WIN10SDK_INCDIR /usr/local/include/win10sdk
>> +RUN mkdir ${WIN10SDK_INCDIR} && \
>> +    for hdr in WinHvEmulation.h WinHvPlatformDefs.h WinHvPlatform.h; do \
>> +        curl -s "https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/+/1bde9c3b14f3a3b081ada6e32da9f2870671b46f/x86_64-w64-mingw32/include/${hdr}?format=TEXT" | base64 --decode > ${WIN10SDK_INCDIR}/${hdr}; \
>> +    done
> 
> Hmm I guess this is a stable URL as Google never deletes anything?

This is not ideal indeed, but way less painful than using the msiextract
tools (and much quicker, the win10sdk.iso is >800MiB).

I dunno about the license issue, this file has "Copyright (c) Microsoft
Corporation.  All rights reserved." but we are not storing its content.

>> +
>> +ENV QEMU_CONFIGURE_OPTS ${QEMU_CONFIGURE_OPTS} \
>> +    --cross-prefix=x86_64-w64-mingw32- \
>> +    --extra-cflags="-I ${WIN10SDK_INCDIR}" --disable-werror \
>> +    --enable-hax --enable-whpx
> 
> 
> --
> Alex Bennée
> 


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 11:18 ` Stefan Weil
  2019-09-19 11:26   ` Philippe Mathieu-Daudé
@ 2019-09-19 11:41   ` Daniel P. Berrangé
  2019-09-19 11:54     ` Philippe Mathieu-Daudé
  1 sibling, 1 reply; 65+ messages in thread
From: Daniel P. Berrangé @ 2019-09-19 11:41 UTC (permalink / raw)
  To: Stefan Weil
  Cc: Fam Zheng, Lucian Petrut, Philippe Mathieu-Daudé,
	qemu-devel, Justin Terry, Alex Bennée, Ilias Maratos

On Thu, Sep 19, 2019 at 01:18:57PM +0200, Stefan Weil wrote:
> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
> > Add a job to cross-build QEMU with WHPX enabled.
> >
> > Use the Win10SDK headers from the Android Project, as commented
> > in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
> >
> > Based-on: <20190918121101.30690-1-philmd@redhat.com>
> > https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
> >
> > Philippe Mathieu-Daudé (2):
> >   tests/docker: Add fedora-win10sdk-cross image
> >   .shippable.yml: Build WHPX enabled binaries
> >
> >  .shippable.yml                                |  2 ++
> >  tests/docker/Makefile.include                 |  1 +
> >  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
> >  3 files changed, 24 insertions(+)
> >  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
> >
> 
> Please note that the required header files are part of the Win10SDK
> which is not published under a free license, so I am afraid that they
> cannot be used with QEMU code to produce free binaries.

Can you elaborate on why you think that is the case ?

Looking at the 3 header files used, all they contain are struct
definitions and integer constants, fortunately no functional
code in macros or inline functions. As such, it is questionable
whether the headers alone can be considered copyrightable material.
Any compatible implementation that follows the WHPX API/ABI will by
neccessity be the same, modulo code style.

Further, from a GPL POV, these headers should fall under the system
libraries exception, as WHPX is core low level operating system
functionality.

There's a valid legal question as to how to we got access to the
files in the first place. Assuming they are freely distributable
though, given their hosting on Google Android downloads.

So the fact that the headers are not under an open source / free
license doesn't look like it should impact the ability to distribute
the resulting QEMU binaries.

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


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 11:41   ` [Qemu-devel] " Daniel P. Berrangé
@ 2019-09-19 11:54     ` Philippe Mathieu-Daudé
  2019-09-19 13:25       ` Daniel P. Berrangé
  0 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-19 11:54 UTC (permalink / raw)
  To: Daniel P. Berrangé, Stefan Weil
  Cc: Fam Zheng, Lucian Petrut, qemu-devel, Justin Terry,
	Alex Bennée, Ilias Maratos

On 9/19/19 1:41 PM, Daniel P. Berrangé wrote:
> On Thu, Sep 19, 2019 at 01:18:57PM +0200, Stefan Weil wrote:
>> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
>>> Add a job to cross-build QEMU with WHPX enabled.
>>>
>>> Use the Win10SDK headers from the Android Project, as commented
>>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
>>>
>>> Based-on: <20190918121101.30690-1-philmd@redhat.com>
>>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
>>>
>>> Philippe Mathieu-Daudé (2):
>>>   tests/docker: Add fedora-win10sdk-cross image
>>>   .shippable.yml: Build WHPX enabled binaries
>>>
>>>  .shippable.yml                                |  2 ++
>>>  tests/docker/Makefile.include                 |  1 +
>>>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>>>  3 files changed, 24 insertions(+)
>>>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>>>
>>
>> Please note that the required header files are part of the Win10SDK
>> which is not published under a free license, so I am afraid that they
>> cannot be used with QEMU code to produce free binaries.
> 
> Can you elaborate on why you think that is the case ?
> 
> Looking at the 3 header files used, all they contain are struct
> definitions and integer constants, fortunately no functional
> code in macros or inline functions. As such, it is questionable
> whether the headers alone can be considered copyrightable material.
> Any compatible implementation that follows the WHPX API/ABI will by
> neccessity be the same, modulo code style.
> 
> Further, from a GPL POV, these headers should fall under the system
> libraries exception, as WHPX is core low level operating system
> functionality.
> 
> There's a valid legal question as to how to we got access to the
> files in the first place. Assuming they are freely distributable
> though, given their hosting on Google Android downloads.
> 
> So the fact that the headers are not under an open source / free
> license doesn't look like it should impact the ability to distribute
> the resulting QEMU binaries.

Are we distributing the resulting binaries?
I don't think so, we only build until linking in a scratch container and
discard its content, we don't have access to the container storage via
Shippable (also Travis). We only use the exit code and the console
output from the build.

We are not distributing those headers neither, as we currently do not
distribute the docker images.

Regards,

Phil.


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 11:54     ` Philippe Mathieu-Daudé
@ 2019-09-19 13:25       ` Daniel P. Berrangé
  0 siblings, 0 replies; 65+ messages in thread
From: Daniel P. Berrangé @ 2019-09-19 13:25 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Fam Zheng, Lucian Petrut, Stefan Weil, qemu-devel, Justin Terry,
	Alex Bennée, Ilias Maratos

On Thu, Sep 19, 2019 at 01:54:40PM +0200, Philippe Mathieu-Daudé wrote:
> On 9/19/19 1:41 PM, Daniel P. Berrangé wrote:
> > On Thu, Sep 19, 2019 at 01:18:57PM +0200, Stefan Weil wrote:
> >> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
> >>> Add a job to cross-build QEMU with WHPX enabled.
> >>>
> >>> Use the Win10SDK headers from the Android Project, as commented
> >>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
> >>>
> >>> Based-on: <20190918121101.30690-1-philmd@redhat.com>
> >>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
> >>>
> >>> Philippe Mathieu-Daudé (2):
> >>>   tests/docker: Add fedora-win10sdk-cross image
> >>>   .shippable.yml: Build WHPX enabled binaries
> >>>
> >>>  .shippable.yml                                |  2 ++
> >>>  tests/docker/Makefile.include                 |  1 +
> >>>  .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
> >>>  3 files changed, 24 insertions(+)
> >>>  create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
> >>>
> >>
> >> Please note that the required header files are part of the Win10SDK
> >> which is not published under a free license, so I am afraid that they
> >> cannot be used with QEMU code to produce free binaries.
> > 
> > Can you elaborate on why you think that is the case ?
> > 
> > Looking at the 3 header files used, all they contain are struct
> > definitions and integer constants, fortunately no functional
> > code in macros or inline functions. As such, it is questionable
> > whether the headers alone can be considered copyrightable material.
> > Any compatible implementation that follows the WHPX API/ABI will by
> > neccessity be the same, modulo code style.
> > 
> > Further, from a GPL POV, these headers should fall under the system
> > libraries exception, as WHPX is core low level operating system
> > functionality.
> > 
> > There's a valid legal question as to how to we got access to the
> > files in the first place. Assuming they are freely distributable
> > though, given their hosting on Google Android downloads.
> > 
> > So the fact that the headers are not under an open source / free
> > license doesn't look like it should impact the ability to distribute
> > the resulting QEMU binaries.
> 
> Are we distributing the resulting binaries?
> I don't think so, we only build until linking in a scratch container and
> discard its content, we don't have access to the container storage via
> Shippable (also Travis). We only use the exit code and the console
> output from the build.
> 
> We are not distributing those headers neither, as we currently do not
> distribute the docker images.

No, but I think its none the less useful to consider what impact is
on distribution of binaries. Currently Stefan builds & distributes
the QEMU Windows binaries for each release. I think the ideal would
be for Windows builds to be a core deliverable of the upstram release
process. So this docker CI job can be viewed as a stepping stone to
that point, especially if it is made to run the full NSIS installer
build, not just standalone binary build.

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


^ permalink raw reply	[flat|nested] 65+ messages in thread

* [PATCH v2 0/3] testing: Build WHPX enabled binaries
@ 2019-09-20 11:33 Philippe Mathieu-Daudé
  2019-09-20 11:33 ` [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled Philippe Mathieu-Daudé
                   ` (4 more replies)
  0 siblings, 5 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 11:33 UTC (permalink / raw)
  To: qemu-devel, Justin Terry
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Alex Bennée, Stefan Weil, Paolo Bonzini,
	Philippe Mathieu-Daudé,
	Richard Henderson

Add a job to cross-build QEMU with WHPX enabled.

Since the WHPX is currently broken, include the patch required to have
successful Shippable build.

I previously included the WHPX headers shared by the Android project,
and Daniel asked me to check the EULA. While trying to manually
install the Windows SDK, I noticed the installer fetches archives
directly, kindly asking where they are stored via the /fwlink API.
Do the same, fetch the required archives and extract them. No need
to accept EULA...

Docker build the image first, then build QEMU in a instance of this
image. The image is internal to Shippable, the instances are not
reachable and are thrown once the build is finished. What we collect
from Shippable is the console output of QEMU build process, and if
the build process succeed or failed. So far we do not redistribute
the image or built binaries.

Philippe Mathieu-Daudé (3):
  target/i386: Fix broken build with WHPX enabled
  tests/docker: Add fedora-win10sdk-cross image
  .shippable.yml: Build WHPX enabled binaries

 .shippable.yml                                |  2 ++
 target/i386/whpx-all.c                        |  1 +
 tests/docker/Makefile.include                 |  2 ++
 .../dockerfiles/fedora-win10sdk-cross.docker  | 23 ++++++++++++++++
 tests/docker/dockerfiles/win10sdk-dl.sh       | 27 +++++++++++++++++++
 5 files changed, 55 insertions(+)
 create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
 create mode 100755 tests/docker/dockerfiles/win10sdk-dl.sh

-- 
2.20.1



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled
  2019-09-20 11:33 [PATCH v2 0/3] testing: Build WHPX enabled binaries Philippe Mathieu-Daudé
@ 2019-09-20 11:33 ` Philippe Mathieu-Daudé
  2019-09-20 11:37   ` Paolo Bonzini
  2019-09-20 11:33 ` [PATCH v2 2/3] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 11:33 UTC (permalink / raw)
  To: qemu-devel, Justin Terry
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Alex Bennée, Stefan Weil, Paolo Bonzini,
	Philippe Mathieu-Daudé,
	Ilias Maratos, Richard Henderson

The WHPX build is broken since commit 12e9493df92 which removed the
"hw/boards.h" where MachineState is declared:

  $ ./configure \
     --enable-hax --enable-whpx

  $ make x86_64-softmmu/all
  [...]
    CC      x86_64-softmmu/target/i386/whpx-all.o
  target/i386/whpx-all.c: In function 'whpx_accel_init':
  target/i386/whpx-all.c:1378:25: error: dereferencing pointer to
  incomplete type 'MachineState' {aka 'struct MachineState'}
       whpx->mem_quota = ms->ram_size;
                           ^~
  make[1]: *** [rules.mak:69: target/i386/whpx-all.o] Error 1
    CC      x86_64-softmmu/trace/generated-helpers.o
  make[1]: Target 'all' not remade because of errors.
  make: *** [Makefile:471: x86_64-softmmu/all] Error 2

Restore this header, partially reverting commit 12e9493df92.

Fixes: 12e9493df92
Reported-by: Ilias Maratos <i.maratos@gmail.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 target/i386/whpx-all.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/i386/whpx-all.c b/target/i386/whpx-all.c
index 0c15241ae4..def0c28480 100644
--- a/target/i386/whpx-all.c
+++ b/target/i386/whpx-all.c
@@ -18,6 +18,7 @@
 #include "sysemu/cpus.h"
 #include "sysemu/runstate.h"
 #include "qemu/main-loop.h"
+#include "hw/boards.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "migration/blocker.h"
-- 
2.20.1



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [PATCH v2 2/3] tests/docker: Add fedora-win10sdk-cross image
  2019-09-20 11:33 [PATCH v2 0/3] testing: Build WHPX enabled binaries Philippe Mathieu-Daudé
  2019-09-20 11:33 ` [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled Philippe Mathieu-Daudé
@ 2019-09-20 11:33 ` Philippe Mathieu-Daudé
  2019-09-20 11:33 ` [PATCH v2 3/3] .shippable.yml: Build WHPX enabled binaries Philippe Mathieu-Daudé
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 11:33 UTC (permalink / raw)
  To: qemu-devel, Justin Terry
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Alex Bennée, Stefan Weil, Paolo Bonzini,
	Philippe Mathieu-Daudé,
	Richard Henderson

To build WHPX (Windows Hypervisor) binaries, we need the WHPX
headers provided by the Windows SDK.

Add a script that fetches the required MSI/CAB files from the
latest SDK (currently 10.0.18362.1).

Headers are accessible under /opt/win10sdk/include.

Set the QEMU_CONFIGURE_OPTS environment variable accordingly,
enabling HAX and WHPX. Due to CPP warnings related to Microsoft
specific #pragmas, we also need to use the '--disable-werror'
configure flag.

Cc: Justin Terry <juterry@microsoft.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 tests/docker/Makefile.include                 |  2 ++
 .../dockerfiles/fedora-win10sdk-cross.docker  | 23 ++++++++++++++++
 tests/docker/dockerfiles/win10sdk-dl.sh       | 27 +++++++++++++++++++
 3 files changed, 52 insertions(+)
 create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
 create mode 100755 tests/docker/dockerfiles/win10sdk-dl.sh

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index 50a400b573..aa2e4e56dd 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -125,6 +125,8 @@ docker-image-debian-ppc64-cross: docker-image-debian10
 docker-image-debian-riscv64-cross: docker-image-debian10
 docker-image-debian-sh4-cross: docker-image-debian10
 docker-image-debian-sparc64-cross: docker-image-debian10
+docker-image-fedora-win10sdk-cross: docker-image-fedora
+docker-image-fedora-win10sdk-cross: EXTRA_FILES:=$(DOCKER_FILES_DIR)/win10sdk-dl.sh
 
 docker-image-travis: NOUSER=1
 
diff --git a/tests/docker/dockerfiles/fedora-win10sdk-cross.docker b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
new file mode 100644
index 0000000000..55ca933d40
--- /dev/null
+++ b/tests/docker/dockerfiles/fedora-win10sdk-cross.docker
@@ -0,0 +1,23 @@
+#
+# Docker MinGW64 cross-compiler target with WHPX header installed
+#
+# This docker target builds on the Fedora 30 base image.
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+FROM qemu:fedora
+
+RUN dnf install -y \
+        cabextract \
+        msitools \
+        wget
+
+# Install WHPX headers from Windows Software Development Kit:
+# https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
+ADD win10sdk-dl.sh /usr/local/bin/win10sdk-dl.sh
+RUN /usr/local/bin/win10sdk-dl.sh
+
+ENV QEMU_CONFIGURE_OPTS ${QEMU_CONFIGURE_OPTS} \
+    --cross-prefix=x86_64-w64-mingw32- \
+    --extra-cflags=-I/opt/win10sdk/include --disable-werror \
+    --enable-hax --enable-whpx
diff --git a/tests/docker/dockerfiles/win10sdk-dl.sh b/tests/docker/dockerfiles/win10sdk-dl.sh
new file mode 100755
index 0000000000..1c35c2a252
--- /dev/null
+++ b/tests/docker/dockerfiles/win10sdk-dl.sh
@@ -0,0 +1,27 @@
+#!/bin/bash
+#
+# Install WHPX headers from Windows Software Development Kit
+# https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+WINDIR=/opt/win10sdk
+mkdir -p ${WINDIR}
+pushd ${WINDIR}
+# Get the bundle base for Windows SDK v10.0.18362.1
+BASE_URL=$(curl --silent --include 'http://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&clcid=0x409&ar=Windows10&sar=SDK&o1=10.0.18362.1' | sed -nE 's_Location: (.*)/\r_\1_p')/Installers
+# Fetch the MSI containing the headers
+wget --no-verbose ${BASE_URL}/'Windows SDK Desktop Headers x86-x86_en-us.msi'
+while true; do
+    # Fetch all cabinets required by this MSI
+    CAB_NAME=$(msiextract Windows\ SDK\ Desktop\ Headers\ x86-x86_en-us.msi 3>&1 2>&3 3>&-| sed -nE "s_.*Error opening file $PWD/(.*): No such file or directory_\1_p")
+    test -z "${CAB_NAME}" && break
+    wget --no-verbose ${BASE_URL}/${CAB_NAME}
+done
+rm *.{cab,msi}
+mkdir /opt/win10sdk/include
+# Only keep the WHPX headers
+for inc in "${WINDIR}/Program Files/Windows Kits/10/Include/10.0.18362.0/um"/WinHv*; do
+    ln -s "${inc}" /opt/win10sdk/include
+done
+popd > /dev/null
-- 
2.20.1



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [PATCH v2 3/3] .shippable.yml: Build WHPX enabled binaries
  2019-09-20 11:33 [PATCH v2 0/3] testing: Build WHPX enabled binaries Philippe Mathieu-Daudé
  2019-09-20 11:33 ` [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled Philippe Mathieu-Daudé
  2019-09-20 11:33 ` [PATCH v2 2/3] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
@ 2019-09-20 11:33 ` Philippe Mathieu-Daudé
  2019-09-20 15:17 ` [PATCH v2 0/3] testing: " Philippe Mathieu-Daudé
  2019-09-21  6:34 ` no-reply
  4 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 11:33 UTC (permalink / raw)
  To: qemu-devel, Justin Terry
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Alex Bennée, Stefan Weil, Paolo Bonzini,
	Philippe Mathieu-Daudé,
	Richard Henderson

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 .shippable.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.shippable.yml b/.shippable.yml
index bbc6f88510..01b33bd034 100644
--- a/.shippable.yml
+++ b/.shippable.yml
@@ -25,6 +25,8 @@ env:
       TARGET_LIST=mips64el-softmmu,mips64el-linux-user
     - IMAGE=debian-ppc64el-cross
       TARGET_LIST=ppc64-softmmu,ppc64-linux-user,ppc64abi32-linux-user
+    - IMAGE=fedora-win10sdk-cross
+      TARGET_LIST=x86_64-softmmu,i386-softmmu
 build:
   pre_ci:
     # usually host ARCH is set by configure
-- 
2.20.1



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled
  2019-09-20 11:33 ` [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled Philippe Mathieu-Daudé
@ 2019-09-20 11:37   ` Paolo Bonzini
  0 siblings, 0 replies; 65+ messages in thread
From: Paolo Bonzini @ 2019-09-20 11:37 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, qemu-devel, Justin Terry
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Stefan Weil, Alex Bennée, Ilias Maratos,
	Richard Henderson

On 20/09/19 13:33, Philippe Mathieu-Daudé wrote:
> The WHPX build is broken since commit 12e9493df92 which removed the
> "hw/boards.h" where MachineState is declared:
> 
>   $ ./configure \
>      --enable-hax --enable-whpx
> 
>   $ make x86_64-softmmu/all
>   [...]
>     CC      x86_64-softmmu/target/i386/whpx-all.o
>   target/i386/whpx-all.c: In function 'whpx_accel_init':
>   target/i386/whpx-all.c:1378:25: error: dereferencing pointer to
>   incomplete type 'MachineState' {aka 'struct MachineState'}
>        whpx->mem_quota = ms->ram_size;
>                            ^~
>   make[1]: *** [rules.mak:69: target/i386/whpx-all.o] Error 1
>     CC      x86_64-softmmu/trace/generated-helpers.o
>   make[1]: Target 'all' not remade because of errors.
>   make: *** [Makefile:471: x86_64-softmmu/all] Error 2
> 
> Restore this header, partially reverting commit 12e9493df92.
> 
> Fixes: 12e9493df92
> Reported-by: Ilias Maratos <i.maratos@gmail.com>
> Reviewed-by: Stefan Weil <sw@weilnetz.de>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  target/i386/whpx-all.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/target/i386/whpx-all.c b/target/i386/whpx-all.c
> index 0c15241ae4..def0c28480 100644
> --- a/target/i386/whpx-all.c
> +++ b/target/i386/whpx-all.c
> @@ -18,6 +18,7 @@
>  #include "sysemu/cpus.h"
>  #include "sysemu/runstate.h"
>  #include "qemu/main-loop.h"
> +#include "hw/boards.h"
>  #include "qemu/error-report.h"
>  #include "qapi/error.h"
>  #include "migration/blocker.h"
> 

Queued, thanks.

Paolo


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2019-09-20 11:33 [PATCH v2 0/3] testing: Build WHPX enabled binaries Philippe Mathieu-Daudé
                   ` (2 preceding siblings ...)
  2019-09-20 11:33 ` [PATCH v2 3/3] .shippable.yml: Build WHPX enabled binaries Philippe Mathieu-Daudé
@ 2019-09-20 15:17 ` Philippe Mathieu-Daudé
  2019-09-20 16:53   ` Justin Terry (VM)
  2019-09-21  6:34 ` no-reply
  4 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-09-20 15:17 UTC (permalink / raw)
  To: qemu-devel, Justin Terry
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Stefan Weil, Paolo Bonzini, Alex Bennée,
	Richard Henderson

On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote:
> Add a job to cross-build QEMU with WHPX enabled.
> 
> Since the WHPX is currently broken, include the patch required to have
> successful Shippable build.
> 
> I previously included the WHPX headers shared by the Android project,
> and Daniel asked me to check the EULA. While trying to manually
> install the Windows SDK, I noticed the installer fetches archives
> directly, kindly asking where they are stored via the /fwlink API.
> Do the same, fetch the required archives and extract them. No need
> to accept EULA...
> 
> Docker build the image first, then build QEMU in a instance of this
> image. The image is internal to Shippable, the instances are not
> reachable and are thrown once the build is finished. What we collect
> from Shippable is the console output of QEMU build process, and if
> the build process succeed or failed. So far we do not redistribute
> the image or built binaries.
> 
> Philippe Mathieu-Daudé (3):
>   target/i386: Fix broken build with WHPX enabled
>   tests/docker: Add fedora-win10sdk-cross image
>   .shippable.yml: Build WHPX enabled binaries

FWIW here is the result of this series:
https://app.shippable.com/github/philmd/qemu/runs/516/11/console
Duration 17 minutes (1076 seconds)

4m49s building the qemu:fedora-win10sdk-cross docker image,
11m10s building WHPX QEMU.


^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2019-09-20 15:17 ` [PATCH v2 0/3] testing: " Philippe Mathieu-Daudé
@ 2019-09-20 16:53   ` Justin Terry (VM)
  2020-05-20 10:26     ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Justin Terry (VM) @ 2019-09-20 16:53 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, qemu-devel
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Stefan Weil, Paolo Bonzini, Alex Bennée,
	Richard Henderson

Hey Phil,

I have contacted our legal department for guidance on this specific use case and will update you when I hear back. Thank you for your patience.

Justin Terry

> -----Original Message-----
> From: Philippe Mathieu-Daudé <philmd@redhat.com>
> Sent: Friday, September 20, 2019 8:18 AM
> To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com>
> Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng
> <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini
> <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard
> Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>;
> Stefan Weil <sw@weilnetz.de>
> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
> 
> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote:
> > Add a job to cross-build QEMU with WHPX enabled.
> >
> > Since the WHPX is currently broken, include the patch required to have
> > successful Shippable build.
> >
> > I previously included the WHPX headers shared by the Android project,
> > and Daniel asked me to check the EULA. While trying to manually
> > install the Windows SDK, I noticed the installer fetches archives
> > directly, kindly asking where they are stored via the /fwlink API.
> > Do the same, fetch the required archives and extract them. No need to
> > accept EULA...
> >
> > Docker build the image first, then build QEMU in a instance of this
> > image. The image is internal to Shippable, the instances are not
> > reachable and are thrown once the build is finished. What we collect
> > from Shippable is the console output of QEMU build process, and if the
> > build process succeed or failed. So far we do not redistribute the
> > image or built binaries.
> >
> > Philippe Mathieu-Daudé (3):
> >   target/i386: Fix broken build with WHPX enabled
> >   tests/docker: Add fedora-win10sdk-cross image
> >   .shippable.yml: Build WHPX enabled binaries
> 
> FWIW here is the result of this series:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.
> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon
> sole&amp;data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427
> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> 37045894733463150&amp;sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv
> nfCSdv%2FNaWDAw%3D&amp;reserved=0
> Duration 17 minutes (1076 seconds)
> 
> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s
> building WHPX QEMU.

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2019-09-20 11:33 [PATCH v2 0/3] testing: Build WHPX enabled binaries Philippe Mathieu-Daudé
                   ` (3 preceding siblings ...)
  2019-09-20 15:17 ` [PATCH v2 0/3] testing: " Philippe Mathieu-Daudé
@ 2019-09-21  6:34 ` no-reply
  4 siblings, 0 replies; 65+ messages in thread
From: no-reply @ 2019-09-21  6:34 UTC (permalink / raw)
  To: philmd
  Cc: fam, thuth, berrange, ehabkost, sw, philmd, qemu-devel, juterry,
	pbonzini, alex.bennee, rth

Patchew URL: https://patchew.org/QEMU/20190920113329.16787-1-philmd@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 20190920113329.16787-1-philmd@redhat.com
Subject: [PATCH v2 0/3] testing: Build WHPX enabled binaries
Type: series

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
87eaddb .shippable.yml: Build WHPX enabled binaries
e5d4b91 tests/docker: Add fedora-win10sdk-cross image
52ca140 target/i386: Fix broken build with WHPX enabled

=== OUTPUT BEGIN ===
1/3 Checking commit 52ca14097b01 (target/i386: Fix broken build with WHPX enabled)
2/3 Checking commit e5d4b91b58ca (tests/docker: Add fedora-win10sdk-cross image)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#38: 
new file mode 100644

ERROR: line over 90 characters
#83: FILE: tests/docker/dockerfiles/win10sdk-dl.sh:12:
+BASE_URL=$(curl --silent --include 'http://go.microsoft.com/fwlink/?prd=11966&pver=1.0&plcid=0x409&clcid=0x409&ar=Windows10&sar=SDK&o1=10.0.18362.1' | sed -nE 's_Location: (.*)/\r_\1_p')/Installers

ERROR: line over 90 characters
#88: FILE: tests/docker/dockerfiles/win10sdk-dl.sh:17:
+    CAB_NAME=$(msiextract Windows\ SDK\ Desktop\ Headers\ x86-x86_en-us.msi 3>&1 2>&3 3>&-| sed -nE "s_.*Error opening file $PWD/(.*): No such file or directory_\1_p")

WARNING: line over 80 characters
#95: FILE: tests/docker/dockerfiles/win10sdk-dl.sh:24:
+for inc in "${WINDIR}/Program Files/Windows Kits/10/Include/10.0.18362.0/um"/WinHv*; do

total: 2 errors, 2 warnings, 58 lines checked

Patch 2/3 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

3/3 Checking commit 87eaddbdd398 (.shippable.yml: Build WHPX enabled binaries)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190920113329.16787-1-philmd@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

^ permalink raw reply	[flat|nested] 65+ messages in thread

* [PATCH v2] WHPX: support for xcr0
@ 2019-11-07 19:48 Sunil Muthuswamy
  2019-11-07 20:05 ` Stefan Weil
  2019-11-12 18:52 ` Sunil Muthuswamy
  0 siblings, 2 replies; 65+ messages in thread
From: Sunil Muthuswamy @ 2019-11-07 19:48 UTC (permalink / raw)
  To: Paolo Bonzini, Richard Henderson, Eduardo Habkost; +Cc: qemu-devel

Support for xcr0 to be able to enable xsave/xrstor. This by itself
is not sufficient to enable xsave/xrstor. WHPX XSAVE API's also
needs to be hooked up.

Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
---
You will need the Windows 10 SDK for RS5 (build 17763) or above to
to be able to compile this patch because of the definition of the
XCR0 register.

Changes since v1:
- Added a sign-off line in the patch.

 target/i386/whp-dispatch.h |  3 ++
 target/i386/whpx-all.c     | 88 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 91 insertions(+)

diff --git a/target/i386/whp-dispatch.h b/target/i386/whp-dispatch.h
index 23791fbb47..b5d56b22a3 100644
--- a/target/i386/whp-dispatch.h
+++ b/target/i386/whp-dispatch.h
@@ -6,6 +6,9 @@
 #include <WinHvPlatform.h>
 #include <WinHvEmulation.h>
 
+/* This should eventually come from the Windows SDK */
+#define WHV_E_UNKNOWN_PROPERTY 0x80370302
+
 #define LIST_WINHVPLATFORM_FUNCTIONS(X) \
   X(HRESULT, WHvGetCapability, (WHV_CAPABILITY_CODE CapabilityCode, VOID* CapabilityBuffer, UINT32 CapabilityBufferSizeInBytes, UINT32* WrittenSizeInBytes)) \
   X(HRESULT, WHvCreatePartition, (WHV_PARTITION_HANDLE* Partition)) \
diff --git a/target/i386/whpx-all.c b/target/i386/whpx-all.c
index ed95105eae..1abaac70db 100644
--- a/target/i386/whpx-all.c
+++ b/target/i386/whpx-all.c
@@ -161,10 +161,15 @@ struct whpx_vcpu {
 static bool whpx_allowed;
 static bool whp_dispatch_initialized;
 static HMODULE hWinHvPlatform, hWinHvEmulation;
+static WHV_PROCESSOR_XSAVE_FEATURES whpx_xsave_cap;
 
 struct whpx_state whpx_global;
 struct WHPDispatch whp_dispatch;
 
+static bool whpx_has_xsave(void)
+{
+    return whpx_xsave_cap.XsaveSupport;
+}
 
 /*
  * VP support
@@ -216,6 +221,28 @@ static SegmentCache whpx_seg_h2q(const WHV_X64_SEGMENT_REGISTER *hs)
     return qs;
 }
 
+/* X64 Extended Control Registers */
+static void whpx_set_xcrs(CPUState *cpu)
+{
+    struct CPUX86State *env = (CPUArchState *)(cpu->env_ptr);
+    HRESULT hr;
+    struct whpx_state *whpx = &whpx_global;
+    WHV_REGISTER_VALUE xcr0;
+    WHV_REGISTER_NAME xcr0_name = WHvX64RegisterXCr0;
+
+    if (!whpx_has_xsave()) {
+        return;
+    }
+
+    /* Only xcr0 is supported by the hypervisor currently */
+    xcr0.Reg64 = env->xcr0;
+    hr = whp_dispatch.WHvSetVirtualProcessorRegisters(
+        whpx->partition, cpu->cpu_index, &xcr0_name, 1, &xcr0);
+    if (FAILED(hr)) {
+        error_report("WHPX: Failed to set register xcr0, hr=%08lx", hr);
+    }
+}
+
 static void whpx_set_registers(CPUState *cpu)
 {
     struct whpx_state *whpx = &whpx_global;
@@ -291,6 +318,12 @@ static void whpx_set_registers(CPUState *cpu)
 
     /* 8 Debug Registers - Skipped */
 
+    /*
+     * Extended control registers needs to be handled separately depending
+     * on whether xsave is supported/enabled or not.
+     */
+    whpx_set_xcrs(cpu);
+
     /* 16 XMM registers */
     assert(whpx_register_names[idx] == WHvX64RegisterXmm0);
     idx_next = idx + 16;
@@ -380,6 +413,30 @@ static void whpx_set_registers(CPUState *cpu)
     return;
 }
 
+/* X64 Extended Control Registers */
+static void whpx_get_xcrs(CPUState *cpu)
+{
+    struct CPUX86State *env = (CPUArchState *)(cpu->env_ptr);
+    HRESULT hr;
+    struct whpx_state *whpx = &whpx_global;
+    WHV_REGISTER_VALUE xcr0;
+    WHV_REGISTER_NAME xcr0_name = WHvX64RegisterXCr0;
+
+    if (!whpx_has_xsave()) {
+        return;
+    }
+
+    /* Only xcr0 is supported by the hypervisor currently */
+    hr = whp_dispatch.WHvGetVirtualProcessorRegisters(
+        whpx->partition, cpu->cpu_index, &xcr0_name, 1, &xcr0);
+    if (FAILED(hr)) {
+        error_report("WHPX: Failed to get register xcr0, hr=%08lx", hr);
+        return;
+    }
+
+    env->xcr0 = xcr0.Reg64;
+}
+
 static void whpx_get_registers(CPUState *cpu)
 {
     struct whpx_state *whpx = &whpx_global;
@@ -457,6 +514,12 @@ static void whpx_get_registers(CPUState *cpu)
 
     /* 8 Debug Registers - Skipped */
 
+    /*
+     * Extended control registers needs to be handled separately depending
+     * on whether xsave is supported/enabled or not.
+     */
+    whpx_get_xcrs(cpu);
+
     /* 16 XMM registers */
     assert(whpx_register_names[idx] == WHvX64RegisterXmm0);
     idx_next = idx + 16;
@@ -1395,6 +1458,31 @@ static int whpx_accel_init(MachineState *ms)
         goto error;
     }
 
+    /*
+     * Query the XSAVE capability of the partition. Any error here is not
+     * considered fatal.
+     */
+    hr = whp_dispatch.WHvGetPartitionProperty(
+        whpx->partition,
+        WHvPartitionPropertyCodeProcessorXsaveFeatures,
+        &whpx_xsave_cap,
+        sizeof(whpx_xsave_cap),
+        &whpx_cap_size);
+
+    /*
+     * Windows version which don't support this property will return with the
+     * specific error code.
+     */
+    if (FAILED(hr) && hr != WHV_E_UNKNOWN_PROPERTY) {
+        error_report("WHPX: Failed to query XSAVE capability, hr=%08lx", hr);
+    }
+
+    if (whpx_has_xsave()) {
+        printf("WHPX: Partition XSAVE capable\n");
+    } else {
+        printf("WHPX: Partition is not XSAVE capable\n");
+    }
+
     memset(&prop, 0, sizeof(WHV_PARTITION_PROPERTY));
     prop.ProcessorCount = ms->smp.cpus;
     hr = whp_dispatch.WHvSetPartitionProperty(
-- 
2.16.4



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2] WHPX: support for xcr0
  2019-11-07 19:48 [PATCH v2] WHPX: support for xcr0 Sunil Muthuswamy
@ 2019-11-07 20:05 ` Stefan Weil
  2019-11-07 22:52   ` Sunil Muthuswamy
  2019-11-12 18:52 ` Sunil Muthuswamy
  1 sibling, 1 reply; 65+ messages in thread
From: Stefan Weil @ 2019-11-07 20:05 UTC (permalink / raw)
  To: Sunil Muthuswamy, Paolo Bonzini, Richard Henderson, Eduardo Habkost
  Cc: qemu-devel

Am 07.11.19 um 20:48 schrieb Sunil Muthuswamy:

> Support for xcr0 to be able to enable xsave/xrstor. This by itself
> is not sufficient to enable xsave/xrstor. WHPX XSAVE API's also
> needs to be hooked up.
>
> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
> ---
> You will need the Windows 10 SDK for RS5 (build 17763) or above to
> to be able to compile this patch because of the definition of the
> XCR0 register.
>
> Changes since v1:
> - Added a sign-off line in the patch.


I am not very happy with the current situation which suggests using non
free header files from the Microsoft Windows SDK, thus making it
impossible to produce QEMU executables for Windows with WHPX support
without having legal complications.

Could you please add the required headers with a suitable license to the
QEMU source code? That would clarify the license issue and make builds
with WHPX much easier because those files would not have to be extracted
from a very large SDK installation.

It would also be acceptable if Microsoft could update the license
comments in those files and use a QEMU compatible license.

Kind regards
Stefan Weil





^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [PATCH v2] WHPX: support for xcr0
  2019-11-07 20:05 ` Stefan Weil
@ 2019-11-07 22:52   ` Sunil Muthuswamy
  2020-05-20 10:27     ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Sunil Muthuswamy @ 2019-11-07 22:52 UTC (permalink / raw)
  To: Stefan Weil, Paolo Bonzini, Richard Henderson, Eduardo Habkost; +Cc: qemu-devel

> > You will need the Windows 10 SDK for RS5 (build 17763) or above to
> > to be able to compile this patch because of the definition of the
> > XCR0 register.
> >
> > Changes since v1:
> > - Added a sign-off line in the patch.
> 
> 
> I am not very happy with the current situation which suggests using non
> free header files from the Microsoft Windows SDK, thus making it
> impossible to produce QEMU executables for Windows with WHPX support
> without having legal complications.
> 
> Could you please add the required headers with a suitable license to the
> QEMU source code? That would clarify the license issue and make builds
> with WHPX much easier because those files would not have to be extracted
> from a very large SDK installation.
> 
> It would also be acceptable if Microsoft could update the license
> comments in those files and use a QEMU compatible license.
>
I agree in principle that there should be an easier way to consume the Windows
SDK headers without having to play around with the licenses. I also agree that
that will make life lot easier for many developers. I am reaching out
internally here to see what can be done about this, but, that might take some
time. Meanwhile, is it possible to make some progress on this patch?

> Kind regards
> Stefan Weil
> 
> 


^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [PATCH v2] WHPX: support for xcr0
  2019-11-07 19:48 [PATCH v2] WHPX: support for xcr0 Sunil Muthuswamy
  2019-11-07 20:05 ` Stefan Weil
@ 2019-11-12 18:52 ` Sunil Muthuswamy
  2019-11-13 14:56   ` Paolo Bonzini
  1 sibling, 1 reply; 65+ messages in thread
From: Sunil Muthuswamy @ 2019-11-12 18:52 UTC (permalink / raw)
  To: Paolo Bonzini, Richard Henderson, Eduardo Habkost; +Cc: qemu-devel



> -----Original Message-----
> From: Sunil Muthuswamy
> Sent: Thursday, November 7, 2019 11:49 AM
> To: Paolo Bonzini <pbonzini@redhat.com>; Richard Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>
> Cc: qemu-devel@nongnu.org
> Subject: [PATCH v2] WHPX: support for xcr0
> 
> Support for xcr0 to be able to enable xsave/xrstor. This by itself
> is not sufficient to enable xsave/xrstor. WHPX XSAVE API's also
> needs to be hooked up.
> 
> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
> ---
> You will need the Windows 10 SDK for RS5 (build 17763) or above to
> to be able to compile this patch because of the definition of the
> XCR0 register.
> 
> Changes since v1:
> - Added a sign-off line in the patch.
> 

Is it possible to get some eyes on this?


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2] WHPX: support for xcr0
  2019-11-12 18:52 ` Sunil Muthuswamy
@ 2019-11-13 14:56   ` Paolo Bonzini
  0 siblings, 0 replies; 65+ messages in thread
From: Paolo Bonzini @ 2019-11-13 14:56 UTC (permalink / raw)
  To: Sunil Muthuswamy, Richard Henderson, Eduardo Habkost; +Cc: qemu-devel

On 12/11/19 19:52, Sunil Muthuswamy wrote:
> 
> 
>> -----Original Message-----
>> From: Sunil Muthuswamy
>> Sent: Thursday, November 7, 2019 11:49 AM
>> To: Paolo Bonzini <pbonzini@redhat.com>; Richard Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>
>> Cc: qemu-devel@nongnu.org
>> Subject: [PATCH v2] WHPX: support for xcr0
>>
>> Support for xcr0 to be able to enable xsave/xrstor. This by itself
>> is not sufficient to enable xsave/xrstor. WHPX XSAVE API's also
>> needs to be hooked up.
>>
>> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
>> ---
>> You will need the Windows 10 SDK for RS5 (build 17763) or above to
>> to be able to compile this patch because of the definition of the
>> XCR0 register.
>>
>> Changes since v1:
>> - Added a sign-off line in the patch.
>>
> 
> Is it possible to get some eyes on this?
> 

Sure, we're currently in freeze and I was also busy with yesterday's
processor CVEs.  But I will review the patch soon.

Thanks,

Paolo



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
@ 2020-02-18 20:38 Sunil Muthuswamy
  2020-02-18 20:51 ` Justin Terry (SF)
  2020-02-21 17:15 ` Paolo Bonzini
  0 siblings, 2 replies; 65+ messages in thread
From: Sunil Muthuswamy @ 2020-02-18 20:38 UTC (permalink / raw)
  To: Eduardo Habkost, Paolo Bonzini, Richard Henderson
  Cc: Stefan Weil, qemu-devel, Justin Terry (SF)

Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1740a4fddc..9b3ba4e1b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -404,6 +404,14 @@ S: Supported
 F: target/i386/kvm.c
 F: scripts/kvm/vmxcap
 
+WHPX CPUs
+M: Sunil Muthuswamy <sunilmut@microsoft.com>
+S: Supported
+F: target/i386/whpx-all.c
+F: target/i386/whp-dispatch.h
+F: accel/stubs/whpx-stub.c
+F: include/sysemu/whpx.h
+
 Guest CPU Cores (Xen)
 ---------------------
 X86 Xen CPUs
-- 
2.17.1


^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-18 20:38 [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform Sunil Muthuswamy
@ 2020-02-18 20:51 ` Justin Terry (SF)
  2020-02-19  8:31   ` Philippe Mathieu-Daudé
  2020-02-21 17:15 ` Paolo Bonzini
  1 sibling, 1 reply; 65+ messages in thread
From: Justin Terry (SF) @ 2020-02-18 20:51 UTC (permalink / raw)
  To: Sunil Muthuswamy, Eduardo Habkost, Paolo Bonzini, Richard Henderson
  Cc: Stefan Weil, qemu-devel

Looks good to me! Thanks Sunil.

Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

> -----Original Message-----
> From: Sunil Muthuswamy <sunilmut@microsoft.com>
> Sent: Tuesday, February 18, 2020 12:39 PM
> To: Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini
> <pbonzini@redhat.com>; Richard Henderson <rth@twiddle.net>
> Cc: Stefan Weil <sw@weilnetz.de>; qemu-devel@nongnu.org; Justin Terry
> (SF) <juterry@microsoft.com>
> Subject: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor
> Platform
> 
> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
> ---
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1740a4fddc..9b3ba4e1b5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -404,6 +404,14 @@ S: Supported
>  F: target/i386/kvm.c
>  F: scripts/kvm/vmxcap
> 
> +WHPX CPUs
> +M: Sunil Muthuswamy <sunilmut@microsoft.com>
> +S: Supported
> +F: target/i386/whpx-all.c
> +F: target/i386/whp-dispatch.h
> +F: accel/stubs/whpx-stub.c
> +F: include/sysemu/whpx.h
> +
>  Guest CPU Cores (Xen)
>  ---------------------
>  X86 Xen CPUs
> --
> 2.17.1


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-18 20:51 ` Justin Terry (SF)
@ 2020-02-19  8:31   ` Philippe Mathieu-Daudé
  2020-02-19 15:50     ` [EXTERNAL] " Justin Terry (SF)
  0 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-02-19  8:31 UTC (permalink / raw)
  To: Justin Terry (SF),
	Sunil Muthuswamy, Eduardo Habkost, Paolo Bonzini,
	Richard Henderson
  Cc: Stefan Weil, qemu-devel

Thank you Sunil!

On 2/18/20 9:51 PM, Justin Terry (SF) wrote:
> Looks good to me! Thanks Sunil.
> 
> Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>

Justin, I suppose you meant:
Reviewed-by: Justin Terry (VM) <juterry@microsoft.com>

> 
>> -----Original Message-----
>> From: Sunil Muthuswamy <sunilmut@microsoft.com>
>> Sent: Tuesday, February 18, 2020 12:39 PM
>> To: Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini
>> <pbonzini@redhat.com>; Richard Henderson <rth@twiddle.net>
>> Cc: Stefan Weil <sw@weilnetz.de>; qemu-devel@nongnu.org; Justin Terry
>> (SF) <juterry@microsoft.com>
>> Subject: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor
>> Platform
>>
>> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
>> ---
>>   MAINTAINERS | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 1740a4fddc..9b3ba4e1b5 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -404,6 +404,14 @@ S: Supported
>>   F: target/i386/kvm.c
>>   F: scripts/kvm/vmxcap
>>
>> +WHPX CPUs

Using "X86 WHPX CPUs" instead:

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

>> +M: Sunil Muthuswamy <sunilmut@microsoft.com>
>> +S: Supported
>> +F: target/i386/whpx-all.c
>> +F: target/i386/whp-dispatch.h
>> +F: accel/stubs/whpx-stub.c
>> +F: include/sysemu/whpx.h
>> +
>>   Guest CPU Cores (Xen)
>>   ---------------------
>>   X86 Xen CPUs
>> --
>> 2.17.1
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-19  8:31   ` Philippe Mathieu-Daudé
@ 2020-02-19 15:50     ` Justin Terry (SF)
  2020-02-21  7:54       ` Stefan Weil
  0 siblings, 1 reply; 65+ messages in thread
From: Justin Terry (SF) @ 2020-02-19 15:50 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé,
	Sunil Muthuswamy, Eduardo Habkost, Paolo Bonzini,
	Richard Henderson
  Cc: Stefan Weil, qemu-devel

Ha yes. LGTM Thanks!

Reviewed-by: Justin Terry (VM) <juterry@microsoft.com>

> -----Original Message-----
> From: Philippe Mathieu-Daudé <philmd@redhat.com>
> Sent: Wednesday, February 19, 2020 12:32 AM
> To: Justin Terry (SF) <juterry@microsoft.com>; Sunil Muthuswamy
> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>;
> Paolo Bonzini <pbonzini@redhat.com>; Richard Henderson
> <rth@twiddle.net>
> Cc: Stefan Weil <sw@weilnetz.de>; qemu-devel@nongnu.org
> Subject: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows
> Hypervisor Platform
> 
> Thank you Sunil!
> 
> On 2/18/20 9:51 PM, Justin Terry (SF) wrote:
> > Looks good to me! Thanks Sunil.
> >
> > Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
> 
> Justin, I suppose you meant:
> Reviewed-by: Justin Terry (VM) <juterry@microsoft.com>
> 
> >
> >> -----Original Message-----
> >> From: Sunil Muthuswamy <sunilmut@microsoft.com>
> >> Sent: Tuesday, February 18, 2020 12:39 PM
> >> To: Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini
> >> <pbonzini@redhat.com>; Richard Henderson <rth@twiddle.net>
> >> Cc: Stefan Weil <sw@weilnetz.de>; qemu-devel@nongnu.org; Justin
> Terry
> >> (SF) <juterry@microsoft.com>
> >> Subject: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor
> >> Platform
> >>
> >> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
> >> ---
> >>   MAINTAINERS | 8 ++++++++
> >>   1 file changed, 8 insertions(+)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS index 1740a4fddc..9b3ba4e1b5
> >> 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -404,6 +404,14 @@ S: Supported
> >>   F: target/i386/kvm.c
> >>   F: scripts/kvm/vmxcap
> >>
> >> +WHPX CPUs
> 
> Using "X86 WHPX CPUs" instead:
> 
> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> 
> >> +M: Sunil Muthuswamy <sunilmut@microsoft.com>
> >> +S: Supported
> >> +F: target/i386/whpx-all.c
> >> +F: target/i386/whp-dispatch.h
> >> +F: accel/stubs/whpx-stub.c
> >> +F: include/sysemu/whpx.h
> >> +
> >>   Guest CPU Cores (Xen)
> >>   ---------------------
> >>   X86 Xen CPUs
> >> --
> >> 2.17.1
> >



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-19 15:50     ` [EXTERNAL] " Justin Terry (SF)
@ 2020-02-21  7:54       ` Stefan Weil
  2020-02-24 19:43         ` Sunil Muthuswamy
  2020-05-19 21:59         ` Sunil Muthuswamy
  0 siblings, 2 replies; 65+ messages in thread
From: Stefan Weil @ 2020-02-21  7:54 UTC (permalink / raw)
  To: Justin Terry (SF), Philippe Mathieu-Daudé,
	Sunil Muthuswamy, Eduardo Habkost, Paolo Bonzini,
	Richard Henderson
  Cc: qemu-devel

Am 19.02.20 um 16:50 schrieb Justin Terry (SF):

> Ha yes. LGTM Thanks!
>
> Reviewed-by: Justin Terry (VM) <juterry@microsoft.com>
>
>> -----Original Message-----
>> From: Philippe Mathieu-Daudé <philmd@redhat.com>
>> Sent: Wednesday, February 19, 2020 12:32 AM
>> To: Justin Terry (SF) <juterry@microsoft.com>; Sunil Muthuswamy
>> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>;
>> Paolo Bonzini <pbonzini@redhat.com>; Richard Henderson
>> <rth@twiddle.net>
>> Cc: Stefan Weil <sw@weilnetz.de>; qemu-devel@nongnu.org
>> Subject: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows
>> Hypervisor Platform
>>
>> Thank you Sunil!
>>
>> On 2/18/20 9:51 PM, Justin Terry (SF) wrote:
>>> Looks good to me! Thanks Sunil.
>>>
>>> Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>


Hello Justin, hello Sunil,

just a reminder: we still have the problem with the proprietary license
for the required Microsoft header files.

Can you estimate when this will be solved?

Regards,
Stefan




^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-18 20:38 [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform Sunil Muthuswamy
  2020-02-18 20:51 ` Justin Terry (SF)
@ 2020-02-21 17:15 ` Paolo Bonzini
  1 sibling, 0 replies; 65+ messages in thread
From: Paolo Bonzini @ 2020-02-21 17:15 UTC (permalink / raw)
  To: Sunil Muthuswamy, Eduardo Habkost, Richard Henderson
  Cc: Stefan Weil, qemu-devel, Justin Terry (SF)

On 18/02/20 21:38, Sunil Muthuswamy wrote:
> Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
> ---
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1740a4fddc..9b3ba4e1b5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -404,6 +404,14 @@ S: Supported
>  F: target/i386/kvm.c
>  F: scripts/kvm/vmxcap
>  
> +WHPX CPUs
> +M: Sunil Muthuswamy <sunilmut@microsoft.com>
> +S: Supported
> +F: target/i386/whpx-all.c
> +F: target/i386/whp-dispatch.h
> +F: accel/stubs/whpx-stub.c
> +F: include/sysemu/whpx.h
> +
>  Guest CPU Cores (Xen)
>  ---------------------
>  X86 Xen CPUs
> 

Queued.  Patches can still go through my tree while you get up to speed.
 Thanks!

Paolo



^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-21  7:54       ` Stefan Weil
@ 2020-02-24 19:43         ` Sunil Muthuswamy
  2020-05-20 10:29           ` Philippe Mathieu-Daudé
  2020-05-19 21:59         ` Sunil Muthuswamy
  1 sibling, 1 reply; 65+ messages in thread
From: Sunil Muthuswamy @ 2020-02-24 19:43 UTC (permalink / raw)
  To: Stefan Weil, Justin Terry (SF), Philippe Mathieu-Daudé,
	Eduardo Habkost, Paolo Bonzini, Richard Henderson
  Cc: qemu-devel

> -----Original Message-----
> From: Stefan Weil <sw@weilnetz.de>
> Sent: Thursday, February 20, 2020 11:54 PM
> To: Justin Terry (SF) <juterry@microsoft.com>; Philippe Mathieu-Daudé <philmd@redhat.com>; Sunil Muthuswamy
> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard Henderson
> <rth@twiddle.net>
> Cc: qemu-devel@nongnu.org
> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
> 
> Am 19.02.20 um 16:50 schrieb Justin Terry (SF):
> 
> 
> Hello Justin, hello Sunil,
> 
> just a reminder: we still have the problem with the proprietary license
> for the required Microsoft header files.
> 
> Can you estimate when this will be solved?
> 

Thanks for the reminder, Stefan. Yes, agreed this problem still exists. We followed up with
the SDK team and the legal team end of last year. I will nudge them again for an update
here.

> Regards,
> Stefan
> 


^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-21  7:54       ` Stefan Weil
  2020-02-24 19:43         ` Sunil Muthuswamy
@ 2020-05-19 21:59         ` Sunil Muthuswamy
  2020-05-20 10:29           ` Philippe Mathieu-Daudé
  1 sibling, 1 reply; 65+ messages in thread
From: Sunil Muthuswamy @ 2020-05-19 21:59 UTC (permalink / raw)
  To: Stefan Weil, Justin Terry (SF), Philippe Mathieu-Daudé,
	Eduardo Habkost, Paolo Bonzini, Richard Henderson, Mike Battista
  Cc: qemu-devel



> -----Original Message-----
> From: Stefan Weil <sw@weilnetz.de>
> Sent: Thursday, February 20, 2020 11:54 PM
> To: Justin Terry (SF) <juterry@microsoft.com>; Philippe Mathieu-Daudé <philmd@redhat.com>; Sunil Muthuswamy
> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard
> Henderson <rth@twiddle.net>
> Cc: qemu-devel@nongnu.org
> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
> 
> Am 19.02.20 um 16:50 schrieb Justin Terry (SF):
> 
> Hello Justin, hello Sunil,
> 
> just a reminder: we still have the problem with the proprietary license
> for the required Microsoft header files.
> 
> Can you estimate when this will be solved?
> 
> Regards,
> Stefan
> 

Adding Mike Battista, who is on the SDK team and can help provide some clarity around the questions about SDK licensing.

^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] [NEW] QEMU installer with WHPX support
@ 2020-05-20 10:14 Philippe Mathieu-Daudé
  2020-05-20 10:25 ` [Bug 1879672] " Daniel Berrange
                   ` (2 more replies)
  0 siblings, 3 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:14 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

People often ask the community to add WHPX support to the QEMU installer for Windows,
but it is impossible due to the license limitations of the WHPX SDK.

The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
rights reserved".

However these headers only contain struct definitions and integer constants,
no functional code in macros or inline functions. See:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
It is questionable whether the headers alone can be considered copyrightable material.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH 0/2] testing: Build WHPX enabled binaries
  2019-09-19 11:26   ` Philippe Mathieu-Daudé
@ 2020-05-20 10:25     ` Philippe Mathieu-Daudé
  2020-05-20 10:25       ` [Bug 1879672] " Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:25 UTC (permalink / raw)
  To: Stefan Weil, qemu-devel
  Cc: Fam Zheng, Lucian Petrut, Justin Terry, 1879672,
	Alex Bennée, Ilias Maratos

+launchpad ticket

On 9/19/19 1:26 PM, Philippe Mathieu-Daudé wrote:
> On 9/19/19 1:18 PM, Stefan Weil wrote:
>> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
>>> Add a job to cross-build QEMU with WHPX enabled.
>>>
>>> Use the Win10SDK headers from the Android Project, as commented
>>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
>>>
>>> Based-on: <20190918121101.30690-1-philmd@redhat.com>
>>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
>>>
>>> Philippe Mathieu-Daudé (2):
>>>    tests/docker: Add fedora-win10sdk-cross image
>>>    .shippable.yml: Build WHPX enabled binaries
>>>
>>>   .shippable.yml                                |  2 ++
>>>   tests/docker/Makefile.include                 |  1 +
>>>   .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>>>   3 files changed, 24 insertions(+)
>>>   create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>>>
>>
>> Please note that the required header files are part of the Win10SDK
>> which is not published under a free license, so I am afraid that they
>> cannot be used with QEMU code to produce free binaries.
> 
> Yes :S
> 
>> I have addressed that some time ago, and Justin Terry is still looking
>> for a solution on the Microsoft side.
> 
> Oh this is a good news, thanks for caring about this issue,
> and thanks Justin for looking for a solution!
> 
> Trying to understand how WHPX is used, I noticed there are much many
> Windows QEMU users than I thought, and it would be nice if we can have
> some upstream CI testing to not break the various projects using it.
> 
> Regards,
> 
> Phil.
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [PATCH 0/2] testing: Build WHPX enabled binaries
  2020-05-20 10:25     ` Philippe Mathieu-Daudé
@ 2020-05-20 10:25       ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:25 UTC (permalink / raw)
  To: qemu-devel

+launchpad ticket

On 9/19/19 1:26 PM, Philippe Mathieu-Daudé wrote:
> On 9/19/19 1:18 PM, Stefan Weil wrote:
>> Am 19.09.2019 um 12:59 schrieb Philippe Mathieu-Daudé:
>>> Add a job to cross-build QEMU with WHPX enabled.
>>>
>>> Use the Win10SDK headers from the Android Project, as commented
>>> in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03842.html
>>>
>>> Based-on: <20190918121101.30690-1-philmd@redhat.com>
>>> https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03844.html
>>>
>>> Philippe Mathieu-Daudé (2):
>>>    tests/docker: Add fedora-win10sdk-cross image
>>>    .shippable.yml: Build WHPX enabled binaries
>>>
>>>   .shippable.yml                                |  2 ++
>>>   tests/docker/Makefile.include                 |  1 +
>>>   .../dockerfiles/fedora-win10sdk-cross.docker  | 21 +++++++++++++++++++
>>>   3 files changed, 24 insertions(+)
>>>   create mode 100644 tests/docker/dockerfiles/fedora-win10sdk-cross.docker
>>>
>>
>> Please note that the required header files are part of the Win10SDK
>> which is not published under a free license, so I am afraid that they
>> cannot be used with QEMU code to produce free binaries.
> 
> Yes :S
> 
>> I have addressed that some time ago, and Justin Terry is still looking
>> for a solution on the Microsoft side.
> 
> Oh this is a good news, thanks for caring about this issue,
> and thanks Justin for looking for a solution!
> 
> Trying to understand how WHPX is used, I noticed there are much many
> Windows QEMU users than I thought, and it would be nice if we can have
> some upstream CI testing to not break the various projects using it.
> 
> Regards,
> 
> Phil.
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: QEMU installer with WHPX support
  2020-05-20 10:14 [Bug 1879672] [NEW] QEMU installer with WHPX support Philippe Mathieu-Daudé
@ 2020-05-20 10:25 ` Daniel Berrange
  2020-05-20 12:30 ` Stefan Weil
  2020-06-08  7:18 ` Philippe Mathieu-Daudé
  2 siblings, 0 replies; 65+ messages in thread
From: Daniel Berrange @ 2020-05-20 10:25 UTC (permalink / raw)
  To: qemu-devel

Has anyone raised an RFE with the mingw64 project to provide these
headers / APIs ? That's what provides the interfaces we usually rely on
for Windows builds, and they're likely familiar with what they can &
can't do from a legal POV. I don't see this as something QEMU needs to
solve itself.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2019-09-20 16:53   ` Justin Terry (VM)
@ 2020-05-20 10:26     ` Philippe Mathieu-Daudé
  2020-05-20 10:26       ` [Bug 1879672] " Philippe Mathieu-Daudé
  2020-07-31  8:33       ` Philippe Mathieu-Daudé
  0 siblings, 2 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:26 UTC (permalink / raw)
  To: Justin Terry (VM), qemu-devel
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Stefan Weil, Paolo Bonzini, 1879672,
	Alex Bennée, Richard Henderson

+launchpad ticket

On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
> Hey Phil,
> 
> I have contacted our legal department for guidance on this specific use case and will update you when I hear back. Thank you for your patience.
> 
> Justin Terry
> 
>> -----Original Message-----
>> From: Philippe Mathieu-Daudé <philmd@redhat.com>
>> Sent: Friday, September 20, 2019 8:18 AM
>> To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com>
>> Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng
>> <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini
>> <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard
>> Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>;
>> Stefan Weil <sw@weilnetz.de>
>> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
>>
>> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote:
>>> Add a job to cross-build QEMU with WHPX enabled.
>>>
>>> Since the WHPX is currently broken, include the patch required to have
>>> successful Shippable build.
>>>
>>> I previously included the WHPX headers shared by the Android project,
>>> and Daniel asked me to check the EULA. While trying to manually
>>> install the Windows SDK, I noticed the installer fetches archives
>>> directly, kindly asking where they are stored via the /fwlink API.
>>> Do the same, fetch the required archives and extract them. No need to
>>> accept EULA...
>>>
>>> Docker build the image first, then build QEMU in a instance of this
>>> image. The image is internal to Shippable, the instances are not
>>> reachable and are thrown once the build is finished. What we collect
>>> from Shippable is the console output of QEMU build process, and if the
>>> build process succeed or failed. So far we do not redistribute the
>>> image or built binaries.
>>>
>>> Philippe Mathieu-Daudé (3):
>>>    target/i386: Fix broken build with WHPX enabled
>>>    tests/docker: Add fedora-win10sdk-cross image
>>>    .shippable.yml: Build WHPX enabled binaries
>>
>> FWIW here is the result of this series:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.
>> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon
>> sole&amp;data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427
>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> 37045894733463150&amp;sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv
>> nfCSdv%2FNaWDAw%3D&amp;reserved=0
>> Duration 17 minutes (1076 seconds)
>>
>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s
>> building WHPX QEMU.



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-05-20 10:26     ` Philippe Mathieu-Daudé
@ 2020-05-20 10:26       ` Philippe Mathieu-Daudé
  2020-07-31  8:33       ` Philippe Mathieu-Daudé
  1 sibling, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:26 UTC (permalink / raw)
  To: qemu-devel

+launchpad ticket

On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
> Hey Phil,
> 
> I have contacted our legal department for guidance on this specific use case and will update you when I hear back. Thank you for your patience.
> 
> Justin Terry
> 
>> -----Original Message-----
>> From: Philippe Mathieu-Daudé <philmd@redhat.com>
>> Sent: Friday, September 20, 2019 8:18 AM
>> To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com>
>> Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng
>> <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini
>> <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard
>> Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>;
>> Stefan Weil <sw@weilnetz.de>
>> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
>>
>> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote:
>>> Add a job to cross-build QEMU with WHPX enabled.
>>>
>>> Since the WHPX is currently broken, include the patch required to have
>>> successful Shippable build.
>>>
>>> I previously included the WHPX headers shared by the Android project,
>>> and Daniel asked me to check the EULA. While trying to manually
>>> install the Windows SDK, I noticed the installer fetches archives
>>> directly, kindly asking where they are stored via the /fwlink API.
>>> Do the same, fetch the required archives and extract them. No need to
>>> accept EULA...
>>>
>>> Docker build the image first, then build QEMU in a instance of this
>>> image. The image is internal to Shippable, the instances are not
>>> reachable and are thrown once the build is finished. What we collect
>>> from Shippable is the console output of QEMU build process, and if the
>>> build process succeed or failed. So far we do not redistribute the
>>> image or built binaries.
>>>
>>> Philippe Mathieu-Daudé (3):
>>>    target/i386: Fix broken build with WHPX enabled
>>>    tests/docker: Add fedora-win10sdk-cross image
>>>    .shippable.yml: Build WHPX enabled binaries
>>
>> FWIW here is the result of this series:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.
>> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon
>> sole&amp;data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427
>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>> 37045894733463150&amp;sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv
>> nfCSdv%2FNaWDAw%3D&amp;reserved=0
>> Duration 17 minutes (1076 seconds)
>>
>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s
>> building WHPX QEMU.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2] WHPX: support for xcr0
  2019-11-07 22:52   ` Sunil Muthuswamy
@ 2020-05-20 10:27     ` Philippe Mathieu-Daudé
  2020-05-20 10:27       ` [Bug 1879672] " Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:27 UTC (permalink / raw)
  To: Sunil Muthuswamy, Stefan Weil, Paolo Bonzini, Richard Henderson,
	Eduardo Habkost
  Cc: 1879672, qemu-devel

+launchpad ticket

On 11/7/19 11:52 PM, Sunil Muthuswamy wrote:
>>> You will need the Windows 10 SDK for RS5 (build 17763) or above to
>>> to be able to compile this patch because of the definition of the
>>> XCR0 register.
>>>
>>> Changes since v1:
>>> - Added a sign-off line in the patch.
>>
>>
>> I am not very happy with the current situation which suggests using non
>> free header files from the Microsoft Windows SDK, thus making it
>> impossible to produce QEMU executables for Windows with WHPX support
>> without having legal complications.
>>
>> Could you please add the required headers with a suitable license to the
>> QEMU source code? That would clarify the license issue and make builds
>> with WHPX much easier because those files would not have to be extracted
>> from a very large SDK installation.
>>
>> It would also be acceptable if Microsoft could update the license
>> comments in those files and use a QEMU compatible license.
>>
> I agree in principle that there should be an easier way to consume the Windows
> SDK headers without having to play around with the licenses. I also agree that
> that will make life lot easier for many developers. I am reaching out
> internally here to see what can be done about this, but, that might take some
> time. Meanwhile, is it possible to make some progress on this patch?
> 
>> Kind regards
>> Stefan Weil
>>
>>
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [PATCH v2] WHPX: support for xcr0
  2020-05-20 10:27     ` Philippe Mathieu-Daudé
@ 2020-05-20 10:27       ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:27 UTC (permalink / raw)
  To: qemu-devel

+launchpad ticket

On 11/7/19 11:52 PM, Sunil Muthuswamy wrote:
>>> You will need the Windows 10 SDK for RS5 (build 17763) or above to
>>> to be able to compile this patch because of the definition of the
>>> XCR0 register.
>>>
>>> Changes since v1:
>>> - Added a sign-off line in the patch.
>>
>>
>> I am not very happy with the current situation which suggests using non
>> free header files from the Microsoft Windows SDK, thus making it
>> impossible to produce QEMU executables for Windows with WHPX support
>> without having legal complications.
>>
>> Could you please add the required headers with a suitable license to the
>> QEMU source code? That would clarify the license issue and make builds
>> with WHPX much easier because those files would not have to be extracted
>> from a very large SDK installation.
>>
>> It would also be acceptable if Microsoft could update the license
>> comments in those files and use a QEMU compatible license.
>>
> I agree in principle that there should be an easier way to consume the Windows
> SDK headers without having to play around with the licenses. I also agree that
> that will make life lot easier for many developers. I am reaching out
> internally here to see what can be done about this, but, that might take some
> time. Meanwhile, is it possible to make some progress on this patch?
> 
>> Kind regards
>> Stefan Weil
>>
>>
> 


** Tags added: windows

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-02-24 19:43         ` Sunil Muthuswamy
@ 2020-05-20 10:29           ` Philippe Mathieu-Daudé
  2020-05-20 10:29             ` [Bug 1879672] " Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:29 UTC (permalink / raw)
  To: Sunil Muthuswamy, Stefan Weil, Justin Terry (SF),
	Eduardo Habkost, Paolo Bonzini, Richard Henderson
  Cc: 1879672, Mike Battista, qemu-devel

+Mike Battista & lanchpad ticket

On 2/24/20 8:43 PM, Sunil Muthuswamy wrote:
>> -----Original Message-----
>> From: Stefan Weil <sw@weilnetz.de>
>> Sent: Thursday, February 20, 2020 11:54 PM
>> To: Justin Terry (SF) <juterry@microsoft.com>; Philippe Mathieu-Daudé <philmd@redhat.com>; Sunil Muthuswamy
>> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard Henderson
>> <rth@twiddle.net>
>> Cc: qemu-devel@nongnu.org
>> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
>>
>> Am 19.02.20 um 16:50 schrieb Justin Terry (SF):
>>
>>
>> Hello Justin, hello Sunil,
>>
>> just a reminder: we still have the problem with the proprietary license
>> for the required Microsoft header files.
>>
>> Can you estimate when this will be solved?
>>
> 
> Thanks for the reminder, Stefan. Yes, agreed this problem still exists. We followed up with
> the SDK team and the legal team end of last year. I will nudge them again for an update
> here.
> 
>> Regards,
>> Stefan
>>
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-05-20 10:29           ` Philippe Mathieu-Daudé
@ 2020-05-20 10:29             ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:29 UTC (permalink / raw)
  To: qemu-devel

+Mike Battista & lanchpad ticket

On 2/24/20 8:43 PM, Sunil Muthuswamy wrote:
>> -----Original Message-----
>> From: Stefan Weil <sw@weilnetz.de>
>> Sent: Thursday, February 20, 2020 11:54 PM
>> To: Justin Terry (SF) <juterry@microsoft.com>; Philippe Mathieu-Daudé <philmd@redhat.com>; Sunil Muthuswamy
>> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard Henderson
>> <rth@twiddle.net>
>> Cc: qemu-devel@nongnu.org
>> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
>>
>> Am 19.02.20 um 16:50 schrieb Justin Terry (SF):
>>
>>
>> Hello Justin, hello Sunil,
>>
>> just a reminder: we still have the problem with the proprietary license
>> for the required Microsoft header files.
>>
>> Can you estimate when this will be solved?
>>
> 
> Thanks for the reminder, Stefan. Yes, agreed this problem still exists. We followed up with
> the SDK team and the legal team end of last year. I will nudge them again for an update
> here.
> 
>> Regards,
>> Stefan
>>
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-05-19 21:59         ` Sunil Muthuswamy
@ 2020-05-20 10:29           ` Philippe Mathieu-Daudé
  2020-05-20 10:29             ` [Bug 1879672] " Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:29 UTC (permalink / raw)
  To: Sunil Muthuswamy, Stefan Weil, Justin Terry (SF),
	Eduardo Habkost, Paolo Bonzini, Richard Henderson, Mike Battista
  Cc: 1879672, qemu-devel

Hi Sunil,

On 5/19/20 11:59 PM, Sunil Muthuswamy wrote:
>> -----Original Message-----
>> From: Stefan Weil <sw@weilnetz.de>
>> Sent: Thursday, February 20, 2020 11:54 PM
>> To: Justin Terry (SF) <juterry@microsoft.com>; Philippe Mathieu-Daudé <philmd@redhat.com>; Sunil Muthuswamy
>> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard
>> Henderson <rth@twiddle.net>
>> Cc: qemu-devel@nongnu.org
>> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
>>
>> Am 19.02.20 um 16:50 schrieb Justin Terry (SF):
>>
>> Hello Justin, hello Sunil,
>>
>> just a reminder: we still have the problem with the proprietary license
>> for the required Microsoft header files.
>>
>> Can you estimate when this will be solved?
>>
>> Regards,
>> Stefan
>>
> 
> Adding Mike Battista, who is on the SDK team and can help provide some clarity around the questions about SDK licensing.
> 

To ease communication and track the changes over time regarding this 
problem, I opened a ticket on Launchpad:
https://bugs.launchpad.net/qemu/+bug/1879672

Last time (Sept 2019) Justin Terry contacted Microsoft legal department 
for guidance but no update since.
This is unfortunate as we can not let the community use this feature, 
neither can we keep testing WHPX to avoid code bitrot.

Can you meanwhile provide Azure CI builds using WHPX enabled?

Regards,

Phil.



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
  2020-05-20 10:29           ` Philippe Mathieu-Daudé
@ 2020-05-20 10:29             ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-20 10:29 UTC (permalink / raw)
  To: qemu-devel

Hi Sunil,

On 5/19/20 11:59 PM, Sunil Muthuswamy wrote:
>> -----Original Message-----
>> From: Stefan Weil <sw@weilnetz.de>
>> Sent: Thursday, February 20, 2020 11:54 PM
>> To: Justin Terry (SF) <juterry@microsoft.com>; Philippe Mathieu-Daudé <philmd@redhat.com>; Sunil Muthuswamy
>> <sunilmut@microsoft.com>; Eduardo Habkost <ehabkost@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard
>> Henderson <rth@twiddle.net>
>> Cc: qemu-devel@nongnu.org
>> Subject: Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform
>>
>> Am 19.02.20 um 16:50 schrieb Justin Terry (SF):
>>
>> Hello Justin, hello Sunil,
>>
>> just a reminder: we still have the problem with the proprietary license
>> for the required Microsoft header files.
>>
>> Can you estimate when this will be solved?
>>
>> Regards,
>> Stefan
>>
> 
> Adding Mike Battista, who is on the SDK team and can help provide some clarity around the questions about SDK licensing.
> 

To ease communication and track the changes over time regarding this 
problem, I opened a ticket on Launchpad:
https://bugs.launchpad.net/qemu/+bug/1879672

Last time (Sept 2019) Justin Terry contacted Microsoft legal department 
for guidance but no update since.
This is unfortunate as we can not let the community use this feature, 
neither can we keep testing WHPX to avoid code bitrot.

Can you meanwhile provide Azure CI builds using WHPX enabled?

Regards,

Phil.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: QEMU installer with WHPX support
  2020-05-20 10:14 [Bug 1879672] [NEW] QEMU installer with WHPX support Philippe Mathieu-Daudé
  2020-05-20 10:25 ` [Bug 1879672] " Daniel Berrange
@ 2020-05-20 12:30 ` Stefan Weil
  2020-06-08  7:18 ` Philippe Mathieu-Daudé
  2 siblings, 0 replies; 65+ messages in thread
From: Stefan Weil @ 2020-05-20 12:30 UTC (permalink / raw)
  To: qemu-devel

> Has anyone raised an RFE with the mingw64 project to provide these
headers / APIs?

I had asked a long time ago on IRC (#mingw-w64 IRC channel on
irc.oftc.net), but got no answer.

Regards,
Stefan

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  New

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: QEMU installer with WHPX support
  2020-05-20 10:14 [Bug 1879672] [NEW] QEMU installer with WHPX support Philippe Mathieu-Daudé
  2020-05-20 10:25 ` [Bug 1879672] " Daniel Berrange
  2020-05-20 12:30 ` Stefan Weil
@ 2020-06-08  7:18 ` Philippe Mathieu-Daudé
  2 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-06-08  7:18 UTC (permalink / raw)
  To: qemu-devel

** Changed in: qemu
       Status: New => Opinion

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Opinion

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-05-20 10:26     ` Philippe Mathieu-Daudé
  2020-05-20 10:26       ` [Bug 1879672] " Philippe Mathieu-Daudé
@ 2020-07-31  8:33       ` Philippe Mathieu-Daudé
  2020-07-31  8:33         ` [Bug 1879672] " Philippe Mathieu-Daudé
  2020-07-31 23:31         ` [EXTERNAL] " Sunil Muthuswamy
  1 sibling, 2 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-07-31  8:33 UTC (permalink / raw)
  To: Justin Terry (VM), qemu-devel
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Stefan Weil, Paolo Bonzini, 1879672,
	Alex Bennée, Sunil Muthuswamy, Richard Henderson

Hi Justin, Sunil,

On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote:
> +launchpad ticket
> 
> On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
>> Hey Phil,
>>
>> I have contacted our legal department for guidance on this specific
>> use case and will update you when I hear back. Thank you for your
>> patience.

I recently understood legal changes can be very complex, thus it is
implicit it can take years before getting updates.

Since the project is still actively developed, maybe you could provide
a Azure CI job to build a WHPX binary. We don't need to have access to
the binary, just to the exit status (success/fail) and build logs.

Do you think it is doable?

Thanks,

Phil.

>>
>> Justin Terry
>>
>>> -----Original Message-----
>>> From: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> Sent: Friday, September 20, 2019 8:18 AM
>>> To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com>
>>> Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng
>>> <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini
>>> <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard
>>> Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>;
>>> Stefan Weil <sw@weilnetz.de>
>>> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
>>>
>>> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote:
>>>> Add a job to cross-build QEMU with WHPX enabled.
>>>>
>>>> Since the WHPX is currently broken, include the patch required to have
>>>> successful Shippable build.
>>>>
>>>> I previously included the WHPX headers shared by the Android project,
>>>> and Daniel asked me to check the EULA. While trying to manually
>>>> install the Windows SDK, I noticed the installer fetches archives
>>>> directly, kindly asking where they are stored via the /fwlink API.
>>>> Do the same, fetch the required archives and extract them. No need to
>>>> accept EULA...
>>>>
>>>> Docker build the image first, then build QEMU in a instance of this
>>>> image. The image is internal to Shippable, the instances are not
>>>> reachable and are thrown once the build is finished. What we collect
>>>> from Shippable is the console output of QEMU build process, and if the
>>>> build process succeed or failed. So far we do not redistribute the
>>>> image or built binaries.
>>>>
>>>> Philippe Mathieu-Daudé (3):
>>>>    target/i386: Fix broken build with WHPX enabled
>>>>    tests/docker: Add fedora-win10sdk-cross image
>>>>    .shippable.yml: Build WHPX enabled binaries
>>>
>>> FWIW here is the result of this series:
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.
>>> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon
>>> sole&amp;data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427
>>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>>> 37045894733463150&amp;sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv
>>> nfCSdv%2FNaWDAw%3D&amp;reserved=0
>>> Duration 17 minutes (1076 seconds)
>>>
>>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s
>>> building WHPX QEMU.
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-07-31  8:33       ` Philippe Mathieu-Daudé
@ 2020-07-31  8:33         ` Philippe Mathieu-Daudé
  2020-07-31 23:31         ` [EXTERNAL] " Sunil Muthuswamy
  1 sibling, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-07-31  8:33 UTC (permalink / raw)
  To: qemu-devel

Hi Justin, Sunil,

On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote:
> +launchpad ticket
> 
> On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
>> Hey Phil,
>>
>> I have contacted our legal department for guidance on this specific
>> use case and will update you when I hear back. Thank you for your
>> patience.

I recently understood legal changes can be very complex, thus it is
implicit it can take years before getting updates.

Since the project is still actively developed, maybe you could provide
a Azure CI job to build a WHPX binary. We don't need to have access to
the binary, just to the exit status (success/fail) and build logs.

Do you think it is doable?

Thanks,

Phil.

>>
>> Justin Terry
>>
>>> -----Original Message-----
>>> From: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> Sent: Friday, September 20, 2019 8:18 AM
>>> To: qemu-devel@nongnu.org; Justin Terry (VM) <juterry@microsoft.com>
>>> Cc: Daniel P . Berrangé <berrange@redhat.com>; Fam Zheng
>>> <fam@euphon.net>; Thomas Huth <thuth@redhat.com>; Paolo Bonzini
>>> <pbonzini@redhat.com>; Alex Bennée <alex.bennee@linaro.org>; Richard
>>> Henderson <rth@twiddle.net>; Eduardo Habkost <ehabkost@redhat.com>;
>>> Stefan Weil <sw@weilnetz.de>
>>> Subject: Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
>>>
>>> On 9/20/19 1:33 PM, Philippe Mathieu-Daudé wrote:
>>>> Add a job to cross-build QEMU with WHPX enabled.
>>>>
>>>> Since the WHPX is currently broken, include the patch required to have
>>>> successful Shippable build.
>>>>
>>>> I previously included the WHPX headers shared by the Android project,
>>>> and Daniel asked me to check the EULA. While trying to manually
>>>> install the Windows SDK, I noticed the installer fetches archives
>>>> directly, kindly asking where they are stored via the /fwlink API.
>>>> Do the same, fetch the required archives and extract them. No need to
>>>> accept EULA...
>>>>
>>>> Docker build the image first, then build QEMU in a instance of this
>>>> image. The image is internal to Shippable, the instances are not
>>>> reachable and are thrown once the build is finished. What we collect
>>>> from Shippable is the console output of QEMU build process, and if the
>>>> build process succeed or failed. So far we do not redistribute the
>>>> image or built binaries.
>>>>
>>>> Philippe Mathieu-Daudé (3):
>>>>    target/i386: Fix broken build with WHPX enabled
>>>>    tests/docker: Add fedora-win10sdk-cross image
>>>>    .shippable.yml: Build WHPX enabled binaries
>>>
>>> FWIW here is the result of this series:
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.
>>> shippable.com%2Fgithub%2Fphilmd%2Fqemu%2Fruns%2F516%2F11%2Fcon
>>> sole&amp;data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427
>>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
>>> 37045894733463150&amp;sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv
>>> nfCSdv%2FNaWDAw%3D&amp;reserved=0
>>> Duration 17 minutes (1076 seconds)
>>>
>>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s
>>> building WHPX QEMU.
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Opinion

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* RE: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-07-31  8:33       ` Philippe Mathieu-Daudé
  2020-07-31  8:33         ` [Bug 1879672] " Philippe Mathieu-Daudé
@ 2020-07-31 23:31         ` Sunil Muthuswamy
  2020-08-03 10:51           ` Philippe Mathieu-Daudé
  1 sibling, 1 reply; 65+ messages in thread
From: Sunil Muthuswamy @ 2020-07-31 23:31 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, qemu-devel
  Cc: Daniel P . Berrangé,
	Fam Zheng, Thomas Huth, Paolo Bonzini, Alex Bennée,
	Richard Henderson, Eduardo Habkost, Stefan Weil, 1879672

> Hi Justin, Sunil,

Justin has moved to a different team is no longer working with WHPX. Moving him
to bcc.

> 
> On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote:
> > +launchpad ticket
> >
> > On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
> >> Hey Phil,
> >>
> >> I have contacted our legal department for guidance on this specific
> >> use case and will update you when I hear back. Thank you for your
> >> patience.
> 
> I recently understood legal changes can be very complex, thus it is
> implicit it can take years before getting updates.
> 
> Since the project is still actively developed, maybe you could provide
> a Azure CI job to build a WHPX binary. We don't need to have access to
> the binary, just to the exit status (success/fail) and build logs.
> 
> Do you think it is doable?
> 
> Thanks,
> 
> Phil.
> 
The ask generally sounds reasonable. But, can you help me understand the full
scope of the ask. Few questions:
1. Stefan has a CI pipeline to build WHPX. What's the benefit of having another CI
job, that doesn't export the binary, but, just the status?
2. Which branch is the CI pipeline expected to build?
3. Is the expectation also that it will build WHPX patches that are submitted to the
WHPX branch?

^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-07-31 23:31         ` [EXTERNAL] " Sunil Muthuswamy
@ 2020-08-03 10:51           ` Philippe Mathieu-Daudé
  2020-08-03 10:51             ` [Bug 1879672] " Philippe Mathieu-Daudé
  2020-08-03 11:28             ` Stefan Weil
  0 siblings, 2 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-03 10:51 UTC (permalink / raw)
  To: Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Stefan Weil, Paolo Bonzini, 1879672,
	Alex Bennée, Richard Henderson

Hi Sunil,

On 8/1/20 1:31 AM, Sunil Muthuswamy wrote:
>> Hi Justin, Sunil,
> 
> Justin has moved to a different team is no longer working with WHPX. Moving him
> to bcc.

OK. Does that mean you are the new responsible of updating the ticket
regarding the WHPX headers and their license?

> 
>>
>> On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote:
>>> +launchpad ticket
>>>
>>> On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
>>>> Hey Phil,
>>>>
>>>> I have contacted our legal department for guidance on this specific
>>>> use case and will update you when I hear back. Thank you for your
>>>> patience.
>>
>> I recently understood legal changes can be very complex, thus it is
>> implicit it can take years before getting updates.
>>
>> Since the project is still actively developed, maybe you could provide
>> a Azure CI job to build a WHPX binary. We don't need to have access to
>> the binary, just to the exit status (success/fail) and build logs.
>>
>> Do you think it is doable?
>>
>> Thanks,
>>
>> Phil.
>>
> The ask generally sounds reasonable. But, can you help me understand the full
> scope of the ask. Few questions:
> 1. Stefan has a CI pipeline to build WHPX.

Great! I didn't know Stefan already did it :)
Can you share the URL please, so we can integrate it with mainstream CI?

> What's the benefit of having another CI
> job, that doesn't export the binary, but, just the status?

As usual, we do not want to circumvent the license. IANAL but IIUC we
can not force a CI job to accept the EULA when installing it, even to
test it. So the best we can do is check if the build succeeded (exit
status).

> 2. Which branch is the CI pipeline expected to build?

'master', to be sure no regressions are introduced.

> 3. Is the expectation also that it will build WHPX patches that are submitted to the
> WHPX branch?

You describe a "downstream CI" testing, which is out of scope of the
community public CI.

Regards,

Phil.



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-03 10:51           ` Philippe Mathieu-Daudé
@ 2020-08-03 10:51             ` Philippe Mathieu-Daudé
  2020-08-03 11:28             ` Stefan Weil
  1 sibling, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-03 10:51 UTC (permalink / raw)
  To: qemu-devel

Hi Sunil,

On 8/1/20 1:31 AM, Sunil Muthuswamy wrote:
>> Hi Justin, Sunil,
> 
> Justin has moved to a different team is no longer working with WHPX. Moving him
> to bcc.

OK. Does that mean you are the new responsible of updating the ticket
regarding the WHPX headers and their license?

> 
>>
>> On 5/20/20 12:26 PM, Philippe Mathieu-Daudé wrote:
>>> +launchpad ticket
>>>
>>> On 9/20/19 6:53 PM, Justin Terry (VM) wrote:
>>>> Hey Phil,
>>>>
>>>> I have contacted our legal department for guidance on this specific
>>>> use case and will update you when I hear back. Thank you for your
>>>> patience.
>>
>> I recently understood legal changes can be very complex, thus it is
>> implicit it can take years before getting updates.
>>
>> Since the project is still actively developed, maybe you could provide
>> a Azure CI job to build a WHPX binary. We don't need to have access to
>> the binary, just to the exit status (success/fail) and build logs.
>>
>> Do you think it is doable?
>>
>> Thanks,
>>
>> Phil.
>>
> The ask generally sounds reasonable. But, can you help me understand the full
> scope of the ask. Few questions:
> 1. Stefan has a CI pipeline to build WHPX.

Great! I didn't know Stefan already did it :)
Can you share the URL please, so we can integrate it with mainstream CI?

> What's the benefit of having another CI
> job, that doesn't export the binary, but, just the status?

As usual, we do not want to circumvent the license. IANAL but IIUC we
can not force a CI job to accept the EULA when installing it, even to
test it. So the best we can do is check if the build succeeded (exit
status).

> 2. Which branch is the CI pipeline expected to build?

'master', to be sure no regressions are introduced.

> 3. Is the expectation also that it will build WHPX patches that are submitted to the
> WHPX branch?

You describe a "downstream CI" testing, which is out of scope of the
community public CI.

Regards,

Phil.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Opinion

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-03 10:51           ` Philippe Mathieu-Daudé
  2020-08-03 10:51             ` [Bug 1879672] " Philippe Mathieu-Daudé
@ 2020-08-03 11:28             ` Stefan Weil
  2020-08-03 20:25               ` Stefan Weil
  1 sibling, 1 reply; 65+ messages in thread
From: Stefan Weil @ 2020-08-03 11:28 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

Am 03.08.20 um 12:51 schrieb Philippe Mathieu-Daudé:

> Hi Sunil,
>
> On 8/1/20 1:31 AM, Sunil Muthuswamy wrote:
>> The ask generally sounds reasonable. But, can you help me understand the full
>> scope of the ask. Few questions:
>> 1. Stefan has a CI pipeline to build WHPX.
> Great! I didn't know Stefan already did it :)
> Can you share the URL please, so we can integrate it with mainstream CI?


I am sorry, but I don't have such a CI pipeline.

Stefan





^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-03 11:28             ` Stefan Weil
@ 2020-08-03 20:25               ` Stefan Weil
  2020-08-04  6:43                 ` Thomas Huth
  0 siblings, 1 reply; 65+ messages in thread
From: Stefan Weil @ 2020-08-03 20:25 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Peter Maydell, Thomas Huth, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

Am 03.08.20 um 13:28 schrieb Stefan Weil:

> Am 03.08.20 um 12:51 schrieb Philippe Mathieu-Daudé:
>
>> Hi Sunil,
>>
>> On 8/1/20 1:31 AM, Sunil Muthuswamy wrote:
>>> The ask generally sounds reasonable. But, can you help me understand the full
>>> scope of the ask. Few questions:
>>> 1. Stefan has a CI pipeline to build WHPX.
>> Great! I didn't know Stefan already did it :)
>> Can you share the URL please, so we can integrate it with mainstream CI?
>
> I am sorry, but I don't have such a CI pipeline.
>
> Stefan


We can add a CI pipeline on Microsoft infrastructure by using a GitHub
action.

Here is an example: https://github.com/stweil/qemu/actions.

I just sent a patch which adds the GitHub action for
https://github.com/qemu/qemu.

Peter, maybe you can add that patch even for 5.1.

Kind regards,

Stefan




^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-03 20:25               ` Stefan Weil
@ 2020-08-04  6:43                 ` Thomas Huth
  2020-08-04  6:55                   ` Stefan Weil
  0 siblings, 1 reply; 65+ messages in thread
From: Thomas Huth @ 2020-08-04  6:43 UTC (permalink / raw)
  To: Stefan Weil, Philippe Mathieu-Daudé, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Peter Maydell, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

On 03/08/2020 22.25, Stefan Weil wrote:
> Am 03.08.20 um 13:28 schrieb Stefan Weil:
> 
>> Am 03.08.20 um 12:51 schrieb Philippe Mathieu-Daudé:
>>
>>> Hi Sunil,
>>>
>>> On 8/1/20 1:31 AM, Sunil Muthuswamy wrote:
>>>> The ask generally sounds reasonable. But, can you help me understand the full
>>>> scope of the ask. Few questions:
>>>> 1. Stefan has a CI pipeline to build WHPX.
>>> Great! I didn't know Stefan already did it :)
>>> Can you share the URL please, so we can integrate it with mainstream CI?
>>
>> I am sorry, but I don't have such a CI pipeline.
>>
>> Stefan
> 
> 
> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
> action.

Sorry for being ignorant, but how does that solve the legal questions
just because it is running on GitHub instead of a different CI?

 Thomas



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  6:43                 ` Thomas Huth
@ 2020-08-04  6:55                   ` Stefan Weil
  2020-08-04  7:23                     ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 65+ messages in thread
From: Stefan Weil @ 2020-08-04  6:55 UTC (permalink / raw)
  To: Thomas Huth, Philippe Mathieu-Daudé, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Peter Maydell, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

Am 04.08.20 um 08:43 schrieb Thomas Huth:

> On 03/08/2020 22.25, Stefan Weil wrote:
>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
>> action.
> Sorry for being ignorant, but how does that solve the legal questions
> just because it is running on GitHub instead of a different CI?
>
>  Thomas
>

Sorry, I though that would be clear by looking at the included shell script.

The build does not use the Microsoft SDK. It gets the required header
files from Mingw-w64. They added them in git master.

See
https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50
for code details.

It's still shameful that MS is forcing developers to waste time
rewriting API headers, just because the MS legal departments are not
able to understand the needs of Open Source development.

Stefan





^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  6:55                   ` Stefan Weil
@ 2020-08-04  7:23                     ` Philippe Mathieu-Daudé
  2020-08-04  7:23                       ` [Bug 1879672] " Philippe Mathieu-Daudé
  2020-08-04  7:42                       ` Stefan Weil
  0 siblings, 2 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-04  7:23 UTC (permalink / raw)
  To: Stefan Weil, Thomas Huth, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Peter Maydell, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

On 8/4/20 8:55 AM, Stefan Weil wrote:
> Am 04.08.20 um 08:43 schrieb Thomas Huth:
> 
>> On 03/08/2020 22.25, Stefan Weil wrote:
>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
>>> action.
>> Sorry for being ignorant, but how does that solve the legal questions
>> just because it is running on GitHub instead of a different CI?
>>
>>  Thomas
>>
> 
> Sorry, I though that would be clear by looking at the included shell script.
> 
> The build does not use the Microsoft SDK. It gets the required header
> files from Mingw-w64. They added them in git master.

Oh, so we can do that with GitLab too now, we don't need to rely on the
GitHub 'Actions' CI in particular, right?

> 
> See
> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50
> for code details.
> 
> It's still shameful that MS is forcing developers to waste time
> rewriting API headers, just because the MS legal departments are not
> able to understand the needs of Open Source development.

There has be a big switch from Microsoft toward Open Source, I attended
some of there talk at the Open Source Summit in 2018. Maybe we simply
haven't contacted the right persons to make the changes...?

> 
> Stefan
> 
> 
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  7:23                     ` Philippe Mathieu-Daudé
@ 2020-08-04  7:23                       ` Philippe Mathieu-Daudé
  2020-08-04  7:42                       ` Stefan Weil
  1 sibling, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-04  7:23 UTC (permalink / raw)
  To: qemu-devel

On 8/4/20 8:55 AM, Stefan Weil wrote:
> Am 04.08.20 um 08:43 schrieb Thomas Huth:
> 
>> On 03/08/2020 22.25, Stefan Weil wrote:
>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
>>> action.
>> Sorry for being ignorant, but how does that solve the legal questions
>> just because it is running on GitHub instead of a different CI?
>>
>>  Thomas
>>
> 
> Sorry, I though that would be clear by looking at the included shell script.
> 
> The build does not use the Microsoft SDK. It gets the required header
> files from Mingw-w64. They added them in git master.

Oh, so we can do that with GitLab too now, we don't need to rely on the
GitHub 'Actions' CI in particular, right?

> 
> See
> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50
> for code details.
> 
> It's still shameful that MS is forcing developers to waste time
> rewriting API headers, just because the MS legal departments are not
> able to understand the needs of Open Source development.

There has be a big switch from Microsoft toward Open Source, I attended
some of there talk at the Open Source Summit in 2018. Maybe we simply
haven't contacted the right persons to make the changes...?

> 
> Stefan
> 
> 
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Opinion

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  7:23                     ` Philippe Mathieu-Daudé
  2020-08-04  7:23                       ` [Bug 1879672] " Philippe Mathieu-Daudé
@ 2020-08-04  7:42                       ` Stefan Weil
  2020-08-04  7:52                         ` Philippe Mathieu-Daudé
  2020-08-04  8:10                         ` Thomas Huth
  1 sibling, 2 replies; 65+ messages in thread
From: Stefan Weil @ 2020-08-04  7:42 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Thomas Huth, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Peter Maydell, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé:

> On 8/4/20 8:55 AM, Stefan Weil wrote:
>> Am 04.08.20 um 08:43 schrieb Thomas Huth:
>>
>>> On 03/08/2020 22.25, Stefan Weil wrote:
>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
>>>> action.
>>> Sorry for being ignorant, but how does that solve the legal questions
>>> just because it is running on GitHub instead of a different CI?
>>>
>>>  Thomas
>>>
>> Sorry, I though that would be clear by looking at the included shell script.
>>
>> The build does not use the Microsoft SDK. It gets the required header
>> files from Mingw-w64. They added them in git master.
> Oh, so we can do that with GitLab too now, we don't need to rely on the
> GitHub 'Actions' CI in particular, right?


That's right. The build script was written for Ubuntu, so depending on
the distribution used for GitLab CI it will need some modifications. If
GitLab already has a recent Mingw-w64, it might be sufficient to fix the
case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU
expects WinHvPlatform.h and so on. I used symbolic links to add the
camel case filenames.


>> See
>> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50
>> for code details.
>>
>> It's still shameful that MS is forcing developers to waste time
>> rewriting API headers, just because the MS legal departments are not
>> able to understand the needs of Open Source development.
> There has be a big switch from Microsoft toward Open Source, I attended
> some of there talk at the Open Source Summit in 2018. Maybe we simply
> haven't contacted the right persons to make the changes...?


Maybe, but it is difficult to find the right person in a large company
like MS, and legal departments are often somehow special.

And yes, they learned that Open Source can help them for their business,
too.

Stefan





^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  7:42                       ` Stefan Weil
@ 2020-08-04  7:52                         ` Philippe Mathieu-Daudé
  2020-08-04  7:52                           ` [Bug 1879672] " Philippe Mathieu-Daudé
  2020-08-04  8:10                         ` Thomas Huth
  1 sibling, 1 reply; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-04  7:52 UTC (permalink / raw)
  To: Stefan Weil, Thomas Huth, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Peter Maydell, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

On 8/4/20 9:42 AM, Stefan Weil wrote:
> Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé:
> 
>> On 8/4/20 8:55 AM, Stefan Weil wrote:
>>> Am 04.08.20 um 08:43 schrieb Thomas Huth:
>>>
>>>> On 03/08/2020 22.25, Stefan Weil wrote:
>>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
>>>>> action.
>>>> Sorry for being ignorant, but how does that solve the legal questions
>>>> just because it is running on GitHub instead of a different CI?
>>>>
>>>>  Thomas
>>>>
>>> Sorry, I though that would be clear by looking at the included shell script.
>>>
>>> The build does not use the Microsoft SDK. It gets the required header
>>> files from Mingw-w64. They added them in git master.
>> Oh, so we can do that with GitLab too now, we don't need to rely on the
>> GitHub 'Actions' CI in particular, right?
> 
> 
> That's right. The build script was written for Ubuntu, so depending on
> the distribution used for GitLab CI it will need some modifications. If
> GitLab already has a recent Mingw-w64, it might be sufficient to fix the
> case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU
> expects WinHvPlatform.h and so on. I used symbolic links to add the
> camel case filenames.
> 
> 
>>> See
>>> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50
>>> for code details.
>>>
>>> It's still shameful that MS is forcing developers to waste time
>>> rewriting API headers, just because the MS legal departments are not
>>> able to understand the needs of Open Source development.
>> There has be a big switch from Microsoft toward Open Source, I attended
>> some of there talk at the Open Source Summit in 2018. Maybe we simply
>> haven't contacted the right persons to make the changes...?
> 
> 
> Maybe, but it is difficult to find the right person in a large company
> like MS, and legal departments are often somehow special.

Sunil seems quite active with the WHPX development, and the section is
listed as "Supported [my Microsoft]" in MAINTAINERS. I'm confident we
have someone else able to help use finding the right contacts in the
company :)

> 
> And yes, they learned that Open Source can help them for their business,
> too.
> 
> Stefan
> 
> 
> 



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  7:52                         ` Philippe Mathieu-Daudé
@ 2020-08-04  7:52                           ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 65+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-08-04  7:52 UTC (permalink / raw)
  To: qemu-devel

On 8/4/20 9:42 AM, Stefan Weil wrote:
> Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé:
> 
>> On 8/4/20 8:55 AM, Stefan Weil wrote:
>>> Am 04.08.20 um 08:43 schrieb Thomas Huth:
>>>
>>>> On 03/08/2020 22.25, Stefan Weil wrote:
>>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
>>>>> action.
>>>> Sorry for being ignorant, but how does that solve the legal questions
>>>> just because it is running on GitHub instead of a different CI?
>>>>
>>>>  Thomas
>>>>
>>> Sorry, I though that would be clear by looking at the included shell script.
>>>
>>> The build does not use the Microsoft SDK. It gets the required header
>>> files from Mingw-w64. They added them in git master.
>> Oh, so we can do that with GitLab too now, we don't need to rely on the
>> GitHub 'Actions' CI in particular, right?
> 
> 
> That's right. The build script was written for Ubuntu, so depending on
> the distribution used for GitLab CI it will need some modifications. If
> GitLab already has a recent Mingw-w64, it might be sufficient to fix the
> case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU
> expects WinHvPlatform.h and so on. I used symbolic links to add the
> camel case filenames.
> 
> 
>>> See
>>> https://github.com/stweil/qemu/blob/master/.github/workflows/build.sh#L50
>>> for code details.
>>>
>>> It's still shameful that MS is forcing developers to waste time
>>> rewriting API headers, just because the MS legal departments are not
>>> able to understand the needs of Open Source development.
>> There has be a big switch from Microsoft toward Open Source, I attended
>> some of there talk at the Open Source Summit in 2018. Maybe we simply
>> haven't contacted the right persons to make the changes...?
> 
> 
> Maybe, but it is difficult to find the right person in a large company
> like MS, and legal departments are often somehow special.

Sunil seems quite active with the WHPX development, and the section is
listed as "Supported [my Microsoft]" in MAINTAINERS. I'm confident we
have someone else able to help use finding the right contacts in the
company :)

> 
> And yes, they learned that Open Source can help them for their business,
> too.
> 
> Stefan
> 
> 
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Opinion

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  7:42                       ` Stefan Weil
  2020-08-04  7:52                         ` Philippe Mathieu-Daudé
@ 2020-08-04  8:10                         ` Thomas Huth
  2020-08-04  9:23                           ` Daniel P. Berrangé
  1 sibling, 1 reply; 65+ messages in thread
From: Thomas Huth @ 2020-08-04  8:10 UTC (permalink / raw)
  To: Stefan Weil, Philippe Mathieu-Daudé, Sunil Muthuswamy, qemu-devel
  Cc: Fam Zheng, Peter Maydell, Daniel P . Berrangé,
	Eduardo Habkost, Paolo Bonzini, 1879672, Alex Bennée,
	Richard Henderson

On 04/08/2020 09.42, Stefan Weil wrote:
> Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé:
> 
>> On 8/4/20 8:55 AM, Stefan Weil wrote:
>>> Am 04.08.20 um 08:43 schrieb Thomas Huth:
>>>
>>>> On 03/08/2020 22.25, Stefan Weil wrote:
>>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
>>>>> action.
>>>> Sorry for being ignorant, but how does that solve the legal questions
>>>> just because it is running on GitHub instead of a different CI?
>>>>
>>>>  Thomas
>>>>
>>> Sorry, I though that would be clear by looking at the included shell script.
>>>
>>> The build does not use the Microsoft SDK. It gets the required header
>>> files from Mingw-w64. They added them in git master.

Great, thanks for the clarification!

>> Oh, so we can do that with GitLab too now, we don't need to rely on the
>> GitHub 'Actions' CI in particular, right?
> 
> That's right. The build script was written for Ubuntu, so depending on
> the distribution used for GitLab CI it will need some modifications. If
> GitLab already has a recent Mingw-w64, it might be sufficient to fix the
> case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU
> expects WinHvPlatform.h and so on. I used symbolic links to add the
> camel case filenames.

I'm currently working on a patch series for our gitlab-CI that uses our
containers to all possible kinds of cross-compiler builds (basically the
ones that we are doing on shippable.com so far), including the 32-bit
and 64-bit MinGW cross-compilation jobs. I can have a look whether I can
integrate these headers there!

 Thanks,
  Thomas



^ permalink raw reply	[flat|nested] 65+ messages in thread

* Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  8:10                         ` Thomas Huth
@ 2020-08-04  9:23                           ` Daniel P. Berrangé
  2020-08-04  9:23                             ` [Bug 1879672] " Daniel Berrange
  0 siblings, 1 reply; 65+ messages in thread
From: Daniel P. Berrangé @ 2020-08-04  9:23 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Fam Zheng, Peter Maydell, Eduardo Habkost, Stefan Weil,
	qemu-devel, Alex Bennée, Paolo Bonzini, Sunil Muthuswamy,
	Philippe Mathieu-Daudé,
	1879672, Richard Henderson

On Tue, Aug 04, 2020 at 10:10:31AM +0200, Thomas Huth wrote:
> On 04/08/2020 09.42, Stefan Weil wrote:
> > Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé:
> > 
> >> On 8/4/20 8:55 AM, Stefan Weil wrote:
> >>> Am 04.08.20 um 08:43 schrieb Thomas Huth:
> >>>
> >>>> On 03/08/2020 22.25, Stefan Weil wrote:
> >>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
> >>>>> action.
> >>>> Sorry for being ignorant, but how does that solve the legal questions
> >>>> just because it is running on GitHub instead of a different CI?
> >>>>
> >>>>  Thomas
> >>>>
> >>> Sorry, I though that would be clear by looking at the included shell script.
> >>>
> >>> The build does not use the Microsoft SDK. It gets the required header
> >>> files from Mingw-w64. They added them in git master.
> 
> Great, thanks for the clarification!
> 
> >> Oh, so we can do that with GitLab too now, we don't need to rely on the
> >> GitHub 'Actions' CI in particular, right?
> > 
> > That's right. The build script was written for Ubuntu, so depending on
> > the distribution used for GitLab CI it will need some modifications. If
> > GitLab already has a recent Mingw-w64, it might be sufficient to fix the
> > case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU
> > expects WinHvPlatform.h and so on. I used symbolic links to add the
> > camel case filenames.
> 
> I'm currently working on a patch series for our gitlab-CI that uses our
> containers to all possible kinds of cross-compiler builds (basically the
> ones that we are doing on shippable.com so far), including the 32-bit
> and 64-bit MinGW cross-compilation jobs. I can have a look whether I can
> integrate these headers there!

Fedora rawhide carries mingw64 v7.0.0, which was released in Nov 2019

The WHPX headers were added to mingw64 git a week later, so they're
not available in any distro yet. 

The mingw64 release schedule looks "sporadic" so maybe we can just
request a new release to make WPHX stuff available. It'll thus be
available for our CI in rawhide/sid shortly thereafter, which will
be the best solution to let us do this in GitLab.

We certainly don't want to add yet another separate CI system just
for WHPX.

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



^ permalink raw reply	[flat|nested] 65+ messages in thread

* [Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries
  2020-08-04  9:23                           ` Daniel P. Berrangé
@ 2020-08-04  9:23                             ` Daniel Berrange
  0 siblings, 0 replies; 65+ messages in thread
From: Daniel Berrange @ 2020-08-04  9:23 UTC (permalink / raw)
  To: qemu-devel

On Tue, Aug 04, 2020 at 10:10:31AM +0200, Thomas Huth wrote:
> On 04/08/2020 09.42, Stefan Weil wrote:
> > Am 04.08.20 um 09:23 schrieb Philippe Mathieu-Daudé:
> > 
> >> On 8/4/20 8:55 AM, Stefan Weil wrote:
> >>> Am 04.08.20 um 08:43 schrieb Thomas Huth:
> >>>
> >>>> On 03/08/2020 22.25, Stefan Weil wrote:
> >>>>> We can add a CI pipeline on Microsoft infrastructure by using a GitHub
> >>>>> action.
> >>>> Sorry for being ignorant, but how does that solve the legal questions
> >>>> just because it is running on GitHub instead of a different CI?
> >>>>
> >>>>  Thomas
> >>>>
> >>> Sorry, I though that would be clear by looking at the included shell script.
> >>>
> >>> The build does not use the Microsoft SDK. It gets the required header
> >>> files from Mingw-w64. They added them in git master.
> 
> Great, thanks for the clarification!
> 
> >> Oh, so we can do that with GitLab too now, we don't need to rely on the
> >> GitHub 'Actions' CI in particular, right?
> > 
> > That's right. The build script was written for Ubuntu, so depending on
> > the distribution used for GitLab CI it will need some modifications. If
> > GitLab already has a recent Mingw-w64, it might be sufficient to fix the
> > case of the header file names. Mingw-w64 uses winhvplatform.h while QEMU
> > expects WinHvPlatform.h and so on. I used symbolic links to add the
> > camel case filenames.
> 
> I'm currently working on a patch series for our gitlab-CI that uses our
> containers to all possible kinds of cross-compiler builds (basically the
> ones that we are doing on shippable.com so far), including the 32-bit
> and 64-bit MinGW cross-compilation jobs. I can have a look whether I can
> integrate these headers there!

Fedora rawhide carries mingw64 v7.0.0, which was released in Nov 2019

The WHPX headers were added to mingw64 git a week later, so they're
not available in any distro yet. 

The mingw64 release schedule looks "sporadic" so maybe we can just
request a new release to make WPHX stuff available. It'll thus be
available for our CI in rawhide/sid shortly thereafter, which will
be the best solution to let us do this in GitLab.

We certainly don't want to add yet another separate CI system just
for WHPX.

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879672

Title:
  QEMU installer with WHPX support

Status in QEMU:
  Opinion

Bug description:
  People often ask the community to add WHPX support to the QEMU installer for Windows,
  but it is impossible due to the license limitations of the WHPX SDK.

  The WinHvEmulation.h and WinHvPlatform.h header files needed are "All
  rights reserved".

  However these headers only contain struct definitions and integer constants,
  no functional code in macros or inline functions. See:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg645815.html
  It is questionable whether the headers alone can be considered copyrightable material.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1879672/+subscriptions


^ permalink raw reply	[flat|nested] 65+ messages in thread

end of thread, back to index

Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-20 10:14 [Bug 1879672] [NEW] QEMU installer with WHPX support Philippe Mathieu-Daudé
2020-05-20 10:25 ` [Bug 1879672] " Daniel Berrange
2020-05-20 12:30 ` Stefan Weil
2020-06-08  7:18 ` Philippe Mathieu-Daudé
  -- strict thread matches above, loose matches on Subject: below --
2020-02-18 20:38 [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform Sunil Muthuswamy
2020-02-18 20:51 ` Justin Terry (SF)
2020-02-19  8:31   ` Philippe Mathieu-Daudé
2020-02-19 15:50     ` [EXTERNAL] " Justin Terry (SF)
2020-02-21  7:54       ` Stefan Weil
2020-02-24 19:43         ` Sunil Muthuswamy
2020-05-20 10:29           ` Philippe Mathieu-Daudé
2020-05-20 10:29             ` [Bug 1879672] " Philippe Mathieu-Daudé
2020-05-19 21:59         ` Sunil Muthuswamy
2020-05-20 10:29           ` Philippe Mathieu-Daudé
2020-05-20 10:29             ` [Bug 1879672] " Philippe Mathieu-Daudé
2020-02-21 17:15 ` Paolo Bonzini
2019-11-07 19:48 [PATCH v2] WHPX: support for xcr0 Sunil Muthuswamy
2019-11-07 20:05 ` Stefan Weil
2019-11-07 22:52   ` Sunil Muthuswamy
2020-05-20 10:27     ` Philippe Mathieu-Daudé
2020-05-20 10:27       ` [Bug 1879672] " Philippe Mathieu-Daudé
2019-11-12 18:52 ` Sunil Muthuswamy
2019-11-13 14:56   ` Paolo Bonzini
2019-09-20 11:33 [PATCH v2 0/3] testing: Build WHPX enabled binaries Philippe Mathieu-Daudé
2019-09-20 11:33 ` [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled Philippe Mathieu-Daudé
2019-09-20 11:37   ` Paolo Bonzini
2019-09-20 11:33 ` [PATCH v2 2/3] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
2019-09-20 11:33 ` [PATCH v2 3/3] .shippable.yml: Build WHPX enabled binaries Philippe Mathieu-Daudé
2019-09-20 15:17 ` [PATCH v2 0/3] testing: " Philippe Mathieu-Daudé
2019-09-20 16:53   ` Justin Terry (VM)
2020-05-20 10:26     ` Philippe Mathieu-Daudé
2020-05-20 10:26       ` [Bug 1879672] " Philippe Mathieu-Daudé
2020-07-31  8:33       ` Philippe Mathieu-Daudé
2020-07-31  8:33         ` [Bug 1879672] " Philippe Mathieu-Daudé
2020-07-31 23:31         ` [EXTERNAL] " Sunil Muthuswamy
2020-08-03 10:51           ` Philippe Mathieu-Daudé
2020-08-03 10:51             ` [Bug 1879672] " Philippe Mathieu-Daudé
2020-08-03 11:28             ` Stefan Weil
2020-08-03 20:25               ` Stefan Weil
2020-08-04  6:43                 ` Thomas Huth
2020-08-04  6:55                   ` Stefan Weil
2020-08-04  7:23                     ` Philippe Mathieu-Daudé
2020-08-04  7:23                       ` [Bug 1879672] " Philippe Mathieu-Daudé
2020-08-04  7:42                       ` Stefan Weil
2020-08-04  7:52                         ` Philippe Mathieu-Daudé
2020-08-04  7:52                           ` [Bug 1879672] " Philippe Mathieu-Daudé
2020-08-04  8:10                         ` Thomas Huth
2020-08-04  9:23                           ` Daniel P. Berrangé
2020-08-04  9:23                             ` [Bug 1879672] " Daniel Berrange
2019-09-21  6:34 ` no-reply
2019-09-19 10:59 [Qemu-devel] [PATCH 0/2] " Philippe Mathieu-Daudé
2019-09-19 10:59 ` [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image Philippe Mathieu-Daudé
2019-09-19 11:28   ` Alex Bennée
2019-09-19 11:35     ` Philippe Mathieu-Daudé
2019-09-19 10:59 ` [Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries Philippe Mathieu-Daudé
2019-09-19 11:02   ` Philippe Mathieu-Daudé
2019-09-19 11:09 ` [Qemu-devel] [PATCH 0/2] testing: " Thomas Huth
2019-09-19 11:21   ` Philippe Mathieu-Daudé
2019-09-19 11:18 ` Stefan Weil
2019-09-19 11:26   ` Philippe Mathieu-Daudé
2020-05-20 10:25     ` Philippe Mathieu-Daudé
2020-05-20 10:25       ` [Bug 1879672] " Philippe Mathieu-Daudé
2019-09-19 11:41   ` [Qemu-devel] " Daniel P. Berrangé
2019-09-19 11:54     ` Philippe Mathieu-Daudé
2019-09-19 13:25       ` Daniel P. Berrangé

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git