Re: [PATCH v2] WHPX: support for xcr0
Queued, thanks. (It only took 30 months; thanks to Ivan Shcherbakov for bringing it to my attention). Paolo
Re: [PATCH v2] WHPX: support for xcr0
+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
Re: [PATCH v2] WHPX: support for xcr0
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 ; Richard Henderson >> ; Eduardo Habkost >> 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 >> --- >> 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
RE: [PATCH v2] WHPX: support for xcr0
> -Original Message- > From: Sunil Muthuswamy > Sent: Thursday, November 7, 2019 11:49 AM > To: Paolo Bonzini ; Richard Henderson > ; Eduardo Habkost > 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 > --- > 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
> > 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
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 > --- > 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
