diff options
Diffstat (limited to 'results/classifier/105/semantic/1879672')
| -rw-r--r-- | results/classifier/105/semantic/1879672 | 664 |
1 files changed, 664 insertions, 0 deletions
diff --git a/results/classifier/105/semantic/1879672 b/results/classifier/105/semantic/1879672 new file mode 100644 index 000000000..62d0929f9 --- /dev/null +++ b/results/classifier/105/semantic/1879672 @@ -0,0 +1,664 @@ +semantic: 0.902 +assembly: 0.899 +other: 0.892 +graphic: 0.888 +device: 0.871 +KVM: 0.865 +vnc: 0.863 +mistranslation: 0.853 +network: 0.846 +instruction: 0.834 +boot: 0.808 +socket: 0.796 + +QEMU installer with WHPX support + +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://<email address hidden>/msg645815.html +It is questionable whether the headers alone can be considered copyrightable material. + +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. + ++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: <email address hidden> +>>> 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. +> + + + ++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é <email address hidden> +>> Sent: Friday, September 20, 2019 8:18 AM +>> To: <email address hidden>; Justin Terry (VM) <email address hidden> +>> Cc: Daniel P . Berrangé <email address hidden>; Fam Zheng +>> <email address hidden>; Thomas Huth <email address hidden>; Paolo Bonzini +>> <email address hidden>; Alex Bennée <email address hidden>; Richard +>> Henderson <email address hidden>; Eduardo Habkost <email address hidden>; +>> Stefan Weil <email address hidden> +>> 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&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427 +>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 +>> 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv +>> nfCSdv%2FNaWDAw%3D&reserved=0 +>> Duration 17 minutes (1076 seconds) +>> +>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s +>> building WHPX QEMU. + + + ++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 +>> +>> +> + + + ++Mike Battista & lanchpad ticket + +On 2/24/20 8:43 PM, Sunil Muthuswamy wrote: +>> -----Original Message----- +>> From: Stefan Weil <email address hidden> +>> Sent: Thursday, February 20, 2020 11:54 PM +>> To: Justin Terry (SF) <email address hidden>; Philippe Mathieu-Daudé <email address hidden>; Sunil Muthuswamy +>> <email address hidden>; Eduardo Habkost <email address hidden>; Paolo Bonzini <email address hidden>; Richard Henderson +>> <email address hidden> +>> Cc: <email address hidden> +>> 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 +>> +> + + + +Hi Sunil, + +On 5/19/20 11:59 PM, Sunil Muthuswamy wrote: +>> -----Original Message----- +>> From: Stefan Weil <email address hidden> +>> Sent: Thursday, February 20, 2020 11:54 PM +>> To: Justin Terry (SF) <email address hidden>; Philippe Mathieu-Daudé <email address hidden>; Sunil Muthuswamy +>> <email address hidden>; Eduardo Habkost <email address hidden>; Paolo Bonzini <email address hidden>; Richard +>> Henderson <email address hidden> +>> Cc: <email address hidden> +>> 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. + + + +> 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 + +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é <email address hidden> +>>> Sent: Friday, September 20, 2019 8:18 AM +>>> To: <email address hidden>; Justin Terry (VM) <email address hidden> +>>> Cc: Daniel P . Berrangé <email address hidden>; Fam Zheng +>>> <email address hidden>; Thomas Huth <email address hidden>; Paolo Bonzini +>>> <email address hidden>; Alex Bennée <email address hidden>; Richard +>>> Henderson <email address hidden>; Eduardo Habkost <email address hidden>; +>>> Stefan Weil <email address hidden> +>>> 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&data=02%7C01%7Cjuterry%40microsoft.com%7C733a566f3233427 +>>> 8ae6f08d73dddb39f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6 +>>> 37045894733463150&sdata=55URgDII5r74QMUpLOD%2FWT5%2B5jbzyv +>>> nfCSdv%2FNaWDAw%3D&reserved=0 +>>> Duration 17 minutes (1076 seconds) +>>> +>>> 4m49s building the qemu:fedora-win10sdk-cross docker image, 11m10s +>>> building WHPX QEMU. +> + + + +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. + + + +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 +> +> +> + + + +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 +> +> +> + + + +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 :| + + + +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 +> +> + + + +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! + +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://<email address hidden>/msg731227.html + + + + +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 + + +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. + +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? + |