[Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[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

-- 
2.20.1

[Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image

[Philippe Mathieu-Daudé]

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

[Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

Re: [Qemu-devel] [PATCH 2/2] .shippable.yml: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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
> 

Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Thomas Huth]

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

Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Stefan Weil]

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

Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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.

Re: [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image

[Alex Bennée]

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

Re: [Qemu-devel] [PATCH 1/2] tests/docker: Add fedora-win10sdk-cross image

[Philippe Mathieu-Daudé]

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
> 

Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Daniel P. Berrangé]

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

Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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.

Re: [Qemu-devel] [PATCH 0/2] testing: Build WHPX enabled binaries

[Daniel P. Berrangé]

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

[PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

[PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled

[Philippe Mathieu-Daudé]

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

[PATCH v2 2/3] tests/docker: Add fedora-win10sdk-cross image

[Philippe Mathieu-Daudé]

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

[PATCH v2 3/3] .shippable.yml: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

Re: [PATCH v2 1/3] target/i386: Fix broken build with WHPX enabled

[Paolo Bonzini]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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.

RE: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Justin Terry (VM)]

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.

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[no-reply]

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

[PATCH v2] WHPX: support for xcr0

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

 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

Re: [PATCH v2] WHPX: support for xcr0

[Stefan Weil]

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

RE: [PATCH v2] WHPX: support for xcr0

[Sunil Muthuswamy]

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

RE: [PATCH v2] WHPX: support for xcr0

[Sunil Muthuswamy]

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

Re: [PATCH v2] WHPX: support for xcr0

[Paolo Bonzini]

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

[PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Sunil Muthuswamy]

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

RE: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Justin Terry (SF)]

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

Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Philippe Mathieu-Daudé]

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
> 

RE: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

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

Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Stefan Weil]

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

Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Paolo Bonzini]

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

RE: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Sunil Muthuswamy]

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

RE: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Sunil Muthuswamy]

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

[Bug 1879672] [NEW] QEMU installer with WHPX support

[Philippe Mathieu-Daudé]

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

Re: [PATCH 0/2] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

[Bug 1879672] Re: [PATCH 0/2] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

+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

[Bug 1879672] Re: QEMU installer with WHPX support

[Daniel Berrange]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

[Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

+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

Re: [PATCH v2] WHPX: support for xcr0

[Philippe Mathieu-Daudé]

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

[Bug 1879672] Re: [PATCH v2] WHPX: support for xcr0

[Philippe Mathieu-Daudé]

+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

Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Philippe Mathieu-Daudé]

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

[Bug 1879672] Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Philippe Mathieu-Daudé]

+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

Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Philippe Mathieu-Daudé]

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.

[Bug 1879672] Re: [EXTERNAL] Re: [PATCH] WHPX: Assigning maintainer for Windows Hypervisor Platform

[Philippe Mathieu-Daudé]

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

[Bug 1879672] Re: QEMU installer with WHPX support

[Stefan Weil]

> 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

[Bug 1879672] Re: QEMU installer with WHPX support

[Philippe Mathieu-Daudé]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

[Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

RE: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Sunil Muthuswamy]

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

Re: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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.

[Bug 1879672] Re: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Stefan Weil]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Thomas Huth]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Stefan Weil]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

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

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

[Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

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

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Stefan Weil]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

[Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Thomas Huth]

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

Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Daniel P. Berrangé]

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

[Bug 1879672] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Daniel Berrange]

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

RE: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Sunil Muthuswamy]

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

Mike Battista is the program manager owner of the SDK license and should be
able to take/respond to any feedback about the SDK licensing for open source
projects (I have added him here). He has also been added to previous threads
about the licensing and is also included in this conversation:
https://bugs.launchpad.net/qemu/+bug/1879672

- Sunil
 

Re: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

On 8/18/20 11:20 PM, Sunil Muthuswamy wrote:
>>>> 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
> 
> Mike Battista is the program manager owner of the SDK license and should be
> able to take/respond to any feedback about the SDK licensing for open source
> projects (I have added him here). He has also been added to previous threads
> about the licensing and is also included in this conversation:
> https://bugs.launchpad.net/qemu/+bug/1879672

Hi Mike, thanks for helping us with this issue!

And thanks a lot Sunil to bring Mike here :)

> 
> - Sunil
>  
> 

[Bug 1879672] Re: [EXTERNAL] Re: [PATCH v2 0/3] testing: Build WHPX enabled binaries

[Philippe Mathieu-Daudé]

On 8/18/20 11:20 PM, Sunil Muthuswamy wrote:
>>>> 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
> 
> Mike Battista is the program manager owner of the SDK license and should be
> able to take/respond to any feedback about the SDK licensing for open source
> projects (I have added him here). He has also been added to previous threads
> about the licensing and is also included in this conversation:
> https://bugs.launchpad.net/qemu/+bug/1879672

Hi Mike, thanks for helping us with this issue!

And thanks a lot Sunil to bring Mike here :)

> 
> - Sunil
>  
>

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

[Bug 1879672] Re: QEMU installer with WHPX support

[John Snow]

Removing 'Opinion' and moving back to 'New'; as 'Opinion' is essentially
the same as "WONTFIX" but allows discussion to continue. I believe you
want a Feature Request tag instead.

If there is still work for us to do, let's move this to
Confirmed/Triaged and add the feature request tag.

Thanks!

** Changed in: qemu
       Status: Opinion => 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

Re: [Bug 1879672] Re: QEMU installer with WHPX support

[Philippe Mathieu-Daudé]

Hi John,

On 11/4/20 9:01 PM, John Snow wrote:
> Removing 'Opinion' and moving back to 'New'; as 'Opinion' is essentially
> the same as "WONTFIX" but allows discussion to continue. I believe you
> want a Feature Request tag instead.
> 
> If there is still work for us to do, let's move this to
> Confirmed/Triaged and add the feature request tag.

It seems Launchpad didn't Cc'ed the interested parties.

Our contact is Mike Battista (see [*]) but so far he never
made any comment regarding this issue.

Cc'ing Sunil who is the active developer (of WHPX in QEMU)
at Microsoft, and Stefan, who does the Open Source packaging.

Regards,

Phil.

[*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg731227.html

Re: [Bug 1879672] Re: QEMU installer with WHPX support

[Philippe Mathieu-Daudé]

Hi John,

On 11/4/20 9:01 PM, John Snow wrote:
> Removing 'Opinion' and moving back to 'New'; as 'Opinion' is essentially
> the same as "WONTFIX" but allows discussion to continue. I believe you
> want a Feature Request tag instead.
> 
> If there is still work for us to do, let's move this to
> Confirmed/Triaged and add the feature request tag.

It seems Launchpad didn't Cc'ed the interested parties.

Our contact is Mike Battista (see [*]) but so far he never
made any comment regarding this issue.

Cc'ing Sunil who is the active developer (of WHPX in QEMU)
at Microsoft, and Stefan, who does the Open Source packaging.

Regards,

Phil.

[*] https://www.mail-archive.com/qemu-devel@nongnu.org/msg731227.html

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

[Bug 1879672] Re: QEMU installer with WHPX support

[Philippe Mathieu-Daudé]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/233


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

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #233
   https://gitlab.com/qemu-project/qemu/-/issues/233

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

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

[Bug 1879672] Re: QEMU installer with WHPX support

[Stefan Weil]

Meanwhile QEMU builds for CI and also my inofficial QEMU installers for
Windows use free WHPX headers instead of the copyrighted MS ones, so
this issue is fixed.

** Changed in: qemu
       Status: Invalid => Fix Released

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

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

[Bug 1879672] Re: QEMU installer with WHPX support

[Philippe Mathieu-Daudé]

But looking at the latest pipeline:
https://gitlab.com/qemu-project/qemu/-/pipelines/310113928
in particular the cross-win64-system job:
https://gitlab.com/qemu-project/qemu/-/jobs/1296341064

WHPX isn't built anymore:

  Targets and accelerators
                      KVM support: NO
                      HAX support: YES
                      HVF support: NO
                     WHPX support: NO
                     NVMM support: NO
                      Xen support: NO
                      TCG support: YES
                      TCG backend: native (x86_64)

We likely lost the coverage with commit 93cc0506f6c
("tests/docker: Use Fedora containers for MinGW cross-builds in the gitlab-CI")

Should we open a new issue?

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

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

Re: [PATCH v2] WHPX: support for xcr0

[Paolo Bonzini]

Queued, thanks.  (It only took 30 months; thanks to Ivan Shcherbakov
for bringing it to my attention).

Paolo