Hello QEMU Community!

Over the past few months the Hyper-V team at Microsoft has been working hard on
a new user-mode API for our hypervisor that will be released as part of the
upcoming SDK. This new API adds user-mode capabilities to create and manage
partitions at the hypervisor level, configure memory mappings for the
partition, and create and control execution of virtual processors.

With this new API we are now able to bring our hypervisor to the QEMU
community! The following patches implement the Windows Hypervisor Platform
accelerator (WHPX) for QEMU on Windows 10 hosts.

When compiling QEMU for x86_64 passing the --enable-whpx flag will compile the
accelerator for use. At runtime using the '-accel whpx' should see a
significant performance improvement over emulation, much like when using 'hax'
on Windows.

Over the next few days the pre-release version of the documentation for this new
API will be visible at https://docs.microsoft.com/en-us/virtualization under
the 'Windows Hypervisor Platform' section. Here you will see the requirements,
API, and examples.

Thank you for your feedback. 

Justin Terry (VM) (4):
  Add the Windows Hypervisor Platform accelerator.
  Add the WHPX vcpu API
  Introduce the WHPX impl
  Add the WHPX acceleration enlightenments

 accel/stubs/Makefile.objs |    9 +-
 accel/stubs/whpx-stub.c   |   48 ++
 configure                 |   48 +-
 cpus.c                    |   66 ++-
 include/sysemu/hw_accel.h |   13 +
 include/sysemu/whpx.h     |   40 ++
 qemu-options.hx           |    8 +-
 target/i386/Makefile.objs |    1 +
 target/i386/helper.c      |    2 +-
 target/i386/whpx-all.c    | 1395 +++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 1619 insertions(+), 11 deletions(-)
 create mode 100644 accel/stubs/whpx-stub.c
 create mode 100644 include/sysemu/whpx.h
 create mode 100644 target/i386/whpx-all.c

-- 
2.7.4

Am 12.01.2018 um 21:22 schrieb Justin Terry (VM) via Qemu-devel:
> Hello QEMU Community!
> 
> Over the past few months the Hyper-V team at Microsoft has been working hard on
> a new user-mode API for our hypervisor that will be released as part of the
> upcoming SDK. This new API adds user-mode capabilities to create and manage
> partitions at the hypervisor level, configure memory mappings for the
> partition, and create and control execution of virtual processors.
> 
> With this new API we are now able to bring our hypervisor to the QEMU
> community! The following patches implement the Windows Hypervisor Platform
> accelerator (WHPX) for QEMU on Windows 10 hosts.
> 
> When compiling QEMU for x86_64 passing the --enable-whpx flag will compile the
> accelerator for use. At runtime using the '-accel whpx' should see a
> significant performance improvement over emulation, much like when using 'hax'
> on Windows.
> 
> Over the next few days the pre-release version of the documentation for this new
> API will be visible at https://docs.microsoft.com/en-us/virtualization under
> the 'Windows Hypervisor Platform' section. Here you will see the requirements,
> API, and examples.
> 
> Thank you for your feedback. 
> 
> Justin Terry (VM) (4):
>   Add the Windows Hypervisor Platform accelerator.
>   Add the WHPX vcpu API
>   Introduce the WHPX impl
>   Add the WHPX acceleration enlightenments
> 
>  accel/stubs/Makefile.objs |    9 +-
>  accel/stubs/whpx-stub.c   |   48 ++
>  configure                 |   48 +-
>  cpus.c                    |   66 ++-
>  include/sysemu/hw_accel.h |   13 +
>  include/sysemu/whpx.h     |   40 ++
>  qemu-options.hx           |    8 +-
>  target/i386/Makefile.objs |    1 +
>  target/i386/helper.c      |    2 +-
>  target/i386/whpx-all.c    | 1395 +++++++++++++++++++++++++++++++++++++++++++++
>  10 files changed, 1619 insertions(+), 11 deletions(-)
>  create mode 100644 accel/stubs/whpx-stub.c
>  create mode 100644 include/sysemu/whpx.h
>  create mode 100644 target/i386/whpx-all.c


Thank you for this contribution – I'll test it.

The patches 2 and 3 fail the test with scripts/checkpatch.pl. Please fix
that in the next iteration (maybe wait a little until there was more
feedback).

Regards,
Stefan

Am 12.01.2018 um 22:57 schrieb Stefan Weil:
>> Over the next few days the pre-release version of the documentation for this new
>> API will be visible at https://docs.microsoft.com/en-us/virtualization under
>> the 'Windows Hypervisor Platform' section. Here you will see the requirements,
>> API, and examples.

Please inform the qemu-devel list when the required files for building
are available.

For now, building fails:

$ ../configure --enable-whpx

ERROR: User requested feature winhvplatform
       configure was not able to find it.
       winhvemulation is not installed

Enhancing the build instructions for QEMU would also be a good idea then.

Thanks,
Stefan

Hey Stefan,

Again thanks for the feedback. The short answer is that it will be first available on an Windows 10 Insider Preview release: https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK. I just don’t know which one exactly. When this is released I will for sure update the community that it is now available for building and testing.

When you say "enhancing the build instructions for QEMU" do you mean having an entry on the wiki describing cross compiling on Windows? I would be happy to add to that wiki page describing what we do now. Could you give me a pointer on where you keep the wiki code so I can add the descriptions there?

Thanks,
Justin

> -----Original Message-----
> From: Stefan Weil [mailto:sw@weilnetz.de]
> Sent: Friday, January 12, 2018 2:06 PM
> To: Justin Terry (VM) <juterry@microsoft.com>; qemu-devel@nongnu.org
> Cc: pbonzini@redhat.com; crosthwaite.peter@gmail.com;
> ehabkost@redhat.com; rth@twiddle.net
> Subject: Re: [Qemu-devel] [PATCH 0/4] Implements the Windows Hypervisor
> Platform accelerator
> 
> Am 12.01.2018 um 22:57 schrieb Stefan Weil:
> >> Over the next few days the pre-release version of the documentation
> >> for this new API will be visible at
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> >> .microsoft.com%2Fen-
> us%2Fvirtualization&data=02%7C01%7Cjuterry%40microsoft.com%7C736413
> 5f827e468fa10108d55a08a667%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C1%7C636513915865544044&sdata=CGgf2qVBFUAi4UCfBEmTvrRb8BD7QG
> kKytkZyhRCoh4%3D&reserved=0 under the 'Windows Hypervisor Platform'
> section. Here you will see the requirements, API, and examples.
> 
> Please inform the qemu-devel list when the required files for building are
> available.
> 
> For now, building fails:
> 
> $ ../configure --enable-whpx
> 
> ERROR: User requested feature winhvplatform
>        configure was not able to find it.
>        winhvemulation is not installed
> 
> Enhancing the build instructions for QEMU would also be a good idea then.
> 
> Thanks,
> Stefan

Hey Stefan,

Thanks for the feedback. I really apologize I forgot to run the checkpath.pl script before submission. I have fixed up all the issues and will send them in patch v2 once I fixup the other feedback.

Thanks,
Justin

-----Original Message-----
From: Stefan Weil [mailto:sw@weilnetz.de] 
Sent: Friday, January 12, 2018 1:57 PM
To: Justin Terry (VM) <juterry@microsoft.com>; qemu-devel@nongnu.org
Cc: pbonzini@redhat.com; rth@twiddle.net; ehabkost@redhat.com; crosthwaite.peter@gmail.com
Subject: Re: [Qemu-devel] [PATCH 0/4] Implements the Windows Hypervisor Platform accelerator

Am 12.01.2018 um 21:22 schrieb Justin Terry (VM) via Qemu-devel:
> Hello QEMU Community!
> 
> Over the past few months the Hyper-V team at Microsoft has been 
> working hard on a new user-mode API for our hypervisor that will be 
> released as part of the upcoming SDK. This new API adds user-mode 
> capabilities to create and manage partitions at the hypervisor level, 
> configure memory mappings for the partition, and create and control execution of virtual processors.
> 
> With this new API we are now able to bring our hypervisor to the QEMU 
> community! The following patches implement the Windows Hypervisor 
> Platform accelerator (WHPX) for QEMU on Windows 10 hosts.
> 
> When compiling QEMU for x86_64 passing the --enable-whpx flag will 
> compile the accelerator for use. At runtime using the '-accel whpx' 
> should see a significant performance improvement over emulation, much like when using 'hax'
> on Windows.
> 
> Over the next few days the pre-release version of the documentation 
> for this new API will be visible at 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.
> microsoft.com%2Fen-us%2Fvirtualization&data=02%7C01%7Cjuterry%40microsoft.com%7Caf4261019804491eb49608d55a076ea4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636513910334166849&sdata=up%2FGCX06qE4RgerXWLJhxLsrspvzrvTZnY53nP4504c%3D&reserved=0 under the 'Windows Hypervisor Platform' section. Here you will see the requirements, API, and examples.
> 
> Thank you for your feedback. 
> 
> Justin Terry (VM) (4):
>   Add the Windows Hypervisor Platform accelerator.
>   Add the WHPX vcpu API
>   Introduce the WHPX impl
>   Add the WHPX acceleration enlightenments
> 
>  accel/stubs/Makefile.objs |    9 +-
>  accel/stubs/whpx-stub.c   |   48 ++
>  configure                 |   48 +-
>  cpus.c                    |   66 ++-
>  include/sysemu/hw_accel.h |   13 +
>  include/sysemu/whpx.h     |   40 ++
>  qemu-options.hx           |    8 +-
>  target/i386/Makefile.objs |    1 +
>  target/i386/helper.c      |    2 +-
>  target/i386/whpx-all.c    | 1395 +++++++++++++++++++++++++++++++++++++++++++++
>  10 files changed, 1619 insertions(+), 11 deletions(-)  create mode 
> 100644 accel/stubs/whpx-stub.c  create mode 100644 
> include/sysemu/whpx.h  create mode 100644 target/i386/whpx-all.c


Thank you for this contribution – I'll test it.

The patches 2 and 3 fail the test with scripts/checkpatch.pl. Please fix that in the next iteration (maybe wait a little until there was more feedback).

Regards,
Stefan

> Hello QEMU Community!
> 
> Over the past few months the Hyper-V team at Microsoft has been working hard on
> a new user-mode API for our hypervisor that will be released as part of the
> upcoming SDK. This new API adds user-mode capabilities to create and manage
> partitions at the hypervisor level, configure memory mappings for the
> partition, and create and control execution of virtual processors.
> 
> With this new API we are now able to bring our hypervisor to the QEMU
> community! The following patches implement the Windows Hypervisor Platform
> accelerator (WHPX) for QEMU on Windows 10 hosts.
> 
> When compiling QEMU for x86_64 passing the --enable-whpx flag will compile
> the accelerator for use. At runtime using the '-accel whpx' should see a
> significant performance improvement over emulation, much like when using
> 'hax' on Windows.
> 
> Over the next few days the pre-release version of the documentation for this
> new API will be visible at https://docs.microsoft.com/en-us/virtualization under
> the 'Windows Hypervisor Platform' section. Here you will see the
> requirements, API, and examples.

That's great!  Accelerator galore. :)

From a quick skim they patches seem to be generally pretty good!  I have a few quick
question on a couple features that seem to be missing:

- an important missing feature is support for CPU models (e.g. "-cpu Haswell").  Code
  for that was added recently for Hypervisor.framework and you should be able to copy
  some of it and then more for your CPUID intercept.  However, the question I have is:
  what interfaces does WHPX support to query the hypervisor's CPUID capabilities?

- is dirty memory support available?  The log_sync callback seems a bit incomplete :)
  If it's not, VGA output probably will not work.

- I might have missed this because the relevant code is quite repetitive - what about
  get/set of XSAVE areas?  If either this or dirty memory is not present, it's probably
  best to block migration (grep for migration_blockers).

Also, what versions of Windows will support WHPX?

Thanks,

Paolo
> Thank you for your feedback.
> 
> Justin Terry (VM) (4):
>   Add the Windows Hypervisor Platform accelerator.
>   Add the WHPX vcpu API
>   Introduce the WHPX impl
>   Add the WHPX acceleration enlightenments
> 
>  accel/stubs/Makefile.objs |    9 +-
>  accel/stubs/whpx-stub.c   |   48 ++
>  configure                 |   48 +-
>  cpus.c                    |   66 ++-
>  include/sysemu/hw_accel.h |   13 +
>  include/sysemu/whpx.h     |   40 ++
>  qemu-options.hx           |    8 +-
>  target/i386/Makefile.objs |    1 +
>  target/i386/helper.c      |    2 +-
>  target/i386/whpx-all.c    | 1395
>  +++++++++++++++++++++++++++++++++++++++++++++
>  10 files changed, 1619 insertions(+), 11 deletions(-)
>  create mode 100644 accel/stubs/whpx-stub.c
>  create mode 100644 include/sysemu/whpx.h
>  create mode 100644 target/i386/whpx-all.c
> 
> --
> 2.7.4
> 
> 

Hey Paolo,

Thanks for all the feedback. After talking with various members of the team around these scenarios I think its best we add the migration blockers for all of your comments unfortunately. The answers to your question are below:

1. For CPUID. The API has support for an "EXTENDED_VM_EXITS" of type WHvRunVpExitReasonX64Cpuid after a call to WHvRunVirtualProcessor. This will one day allow for the CPUID instruction to be resolved however it is not currently implemented in the platform. So for right now we will have to block on CPUID.

2. For dirty memory tracking. We currently don’t have support in the platform or API for this. I have added that to the feature backlog and will update QEMU as that gets implemented in the platform. However, VGA does indeed work with the current impl of log_sync.

3. Also, for XSAVE/RSTOR we again don’t have platform support for the required registers. I have added this to the feature platform backlog to gain access for that functionality as well.

4. This will be supported on Windows 10 hosts (I don’t have the insider build number yet) and it will require an Intel processor with VT-x and Unrestricted Guest support. Will update the qemu-devel list once we have an insider build that is public that has the platform bits.

So, if your ok with it I will block on CPUID, Memory Tracking, and XSAVE/RSTOR functionality and send out the updated PR.

-Justin

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Friday, January 12, 2018 12:48 PM
> To: Justin Terry (VM) <juterry@microsoft.com>
> Cc: qemu-devel@nongnu.org qemu-devel <qemu-devel@nongnu.org>
> Subject: Re: [PATCH 0/4] Implements the Windows Hypervisor Platform
> accelerator
> 
> 
> > Hello QEMU Community!
> >
> > Over the past few months the Hyper-V team at Microsoft has been
> > working hard on a new user-mode API for our hypervisor that will be
> > released as part of the upcoming SDK. This new API adds user-mode
> > capabilities to create and manage partitions at the hypervisor level,
> > configure memory mappings for the partition, and create and control
> execution of virtual processors.
> >
> > With this new API we are now able to bring our hypervisor to the QEMU
> > community! The following patches implement the Windows Hypervisor
> > Platform accelerator (WHPX) for QEMU on Windows 10 hosts.
> >
> > When compiling QEMU for x86_64 passing the --enable-whpx flag will
> > compile the accelerator for use. At runtime using the '-accel whpx'
> > should see a significant performance improvement over emulation, much
> > like when using 'hax' on Windows.
> >
> > Over the next few days the pre-release version of the documentation
> > for this new API will be visible at
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.
> > microsoft.com%2Fen-
> us%2Fvirtualization&data=02%7C01%7Cjuterry%40microsoft.com%7Ce979c5
> 0ab5544ab2dec708d559fdc86f%7C72f988bf86f141af91ab2d7cd011db47%7C1
> %7C0%7C636513868884987772&sdata=E%2BE5DX%2FJqsK2%2BZJVWzQ3qFy
> Kg0YLKrg6EtzLkvnJqbU%3D&reserved=0 under the 'Windows Hypervisor
> Platform' section. Here you will see the requirements, API, and examples.
> 
> That's great!  Accelerator galore. :)
> 
> From a quick skim they patches seem to be generally pretty good!  I have a
> few quick question on a couple features that seem to be missing:
> 
> - an important missing feature is support for CPU models (e.g. "-cpu
> Haswell").  Code
>   for that was added recently for Hypervisor.framework and you should be
> able to copy
>   some of it and then more for your CPUID intercept.  However, the question
> I have is:
>   what interfaces does WHPX support to query the hypervisor's CPUID
> capabilities?
> 
> - is dirty memory support available?  The log_sync callback seems a bit
> incomplete :)
>   If it's not, VGA output probably will not work.
> 
> - I might have missed this because the relevant code is quite repetitive -
> what about
>   get/set of XSAVE areas?  If either this or dirty memory is not present, it's
> probably
>   best to block migration (grep for migration_blockers).
> 
> Also, what versions of Windows will support WHPX?
> 
> Thanks,
> 
> Paolo
> > Thank you for your feedback.
> >
> > Justin Terry (VM) (4):
> >   Add the Windows Hypervisor Platform accelerator.
> >   Add the WHPX vcpu API
> >   Introduce the WHPX impl
> >   Add the WHPX acceleration enlightenments
> >
> >  accel/stubs/Makefile.objs |    9 +-
> >  accel/stubs/whpx-stub.c   |   48 ++
> >  configure                 |   48 +-
> >  cpus.c                    |   66 ++-
> >  include/sysemu/hw_accel.h |   13 +
> >  include/sysemu/whpx.h     |   40 ++
> >  qemu-options.hx           |    8 +-
> >  target/i386/Makefile.objs |    1 +
> >  target/i386/helper.c      |    2 +-
> >  target/i386/whpx-all.c    | 1395
> >  +++++++++++++++++++++++++++++++++++++++++++++
> >  10 files changed, 1619 insertions(+), 11 deletions(-)  create mode
> > 100644 accel/stubs/whpx-stub.c  create mode 100644
> > include/sysemu/whpx.h  create mode 100644 target/i386/whpx-all.c
> >
> > --
> > 2.7.4
> >
> >

Am 18.01.2018 um 00:41 schrieb Justin Terry (VM) via Qemu-devel:
> Hey Paolo,
[...]
> 4. This will be supported on Windows 10 hosts (I don’t have the insider build number yet) and it will require an Intel processor with VT-x and Unrestricted Guest support. Will update the qemu-devel list once we have an insider build that is public that has the platform bits.

Is it restricted to professional and enterprise versions of Windows
(that would be bad), or will it run on any Windows 10 host?

Stefan

Ok looked into this. At present this will be included with Windows 10 Home, Professional, and Enterprise (as well as server builds) so I think that should enable the scenario on most of our releases.

Justin

> -----Original Message-----
> From: Stefan Weil [mailto:sw@weilnetz.de]
> Sent: Wednesday, January 17, 2018 11:05 PM
> To: Justin Terry (VM) <juterry@microsoft.com>; Paolo Bonzini
> <pbonzini@redhat.com>
> Cc: qemu-devel@nongnu.org qemu-devel <qemu-devel@nongnu.org>
> Subject: Re: [Qemu-devel] [PATCH 0/4] Implements the Windows Hypervisor
> Platform accelerator
> 
> Am 18.01.2018 um 00:41 schrieb Justin Terry (VM) via Qemu-devel:
> > Hey Paolo,
> [...]
> > 4. This will be supported on Windows 10 hosts (I don’t have the insider
> build number yet) and it will require an Intel processor with VT-x and
> Unrestricted Guest support. Will update the qemu-devel list once we have
> an insider build that is public that has the platform bits.
> 
> Is it restricted to professional and enterprise versions of Windows (that
> would be bad), or will it run on any Windows 10 host?
> 
> Stefan

On 18/01/2018 00:41, Justin Terry (VM) wrote:
> 
> Thanks for all the feedback. After talking with various members of
> the team around these scenarios I think its best we add the migration
> blockers for all of your comments unfortunately. The answers to your
> question are below:
> 
> 1. For CPUID. The API has support for an "EXTENDED_VM_EXITS" of type
> WHvRunVpExitReasonX64Cpuid after a call to WHvRunVirtualProcessor.
> This will one day allow for the CPUID instruction to be resolved
> however it is not currently implemented in the platform. So for right
> now we will have to block on CPUID.
> 
> 2. For dirty memory tracking. We currently don’t have support in the
> platform or API for this. I have added that to the feature backlog
> and will update QEMU as that gets implemented in the platform.
> However, VGA does indeed work with the current impl of log_sync.
> 
> 3. Also, for XSAVE/RSTOR we again don’t have platform support for the
> required registers. I have added this to the feature platform backlog
> to gain access for that functionality as well.
> 
> 4. This will be supported on Windows 10 hosts (I don’t have the
> insider build number yet) and it will require an Intel processor with
> VT-x and Unrestricted Guest support. Will update the qemu-devel list
> once we have an insider build that is public that has the platform
> bits.
> 
> So, if your ok with it I will block on CPUID, Memory Tracking, and
> XSAVE/RSTOR functionality and send out the updated PR.

Yes, thanks.  Of course just one migration blocker is enough.  Add a
comment like the above 1-3 bullet points above it.

Thanks,

Paolo

Perfect. Thanks Paolo. Will submit the Patch V2 with your requested changes today.

Justin

> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Thursday, January 18, 2018 12:16 AM
> To: Justin Terry (VM) <juterry@microsoft.com>
> Cc: qemu-devel@nongnu.org qemu-devel <qemu-devel@nongnu.org>
> Subject: Re: [PATCH 0/4] Implements the Windows Hypervisor Platform
> accelerator
> 
> On 18/01/2018 00:41, Justin Terry (VM) wrote:
> >
> > Thanks for all the feedback. After talking with various members of the
> > team around these scenarios I think its best we add the migration
> > blockers for all of your comments unfortunately. The answers to your
> > question are below:
> >
> > 1. For CPUID. The API has support for an "EXTENDED_VM_EXITS" of type
> > WHvRunVpExitReasonX64Cpuid after a call to WHvRunVirtualProcessor.
> > This will one day allow for the CPUID instruction to be resolved
> > however it is not currently implemented in the platform. So for right
> > now we will have to block on CPUID.
> >
> > 2. For dirty memory tracking. We currently don’t have support in the
> > platform or API for this. I have added that to the feature backlog and
> > will update QEMU as that gets implemented in the platform.
> > However, VGA does indeed work with the current impl of log_sync.
> >
> > 3. Also, for XSAVE/RSTOR we again don’t have platform support for the
> > required registers. I have added this to the feature platform backlog
> > to gain access for that functionality as well.
> >
> > 4. This will be supported on Windows 10 hosts (I don’t have the
> > insider build number yet) and it will require an Intel processor with
> > VT-x and Unrestricted Guest support. Will update the qemu-devel list
> > once we have an insider build that is public that has the platform
> > bits.
> >
> > So, if your ok with it I will block on CPUID, Memory Tracking, and
> > XSAVE/RSTOR functionality and send out the updated PR.
> 
> Yes, thanks.  Of course just one migration blocker is enough.  Add a comment
> like the above 1-3 bullet points above it.
> 
> Thanks,
> 
> Paolo

Hi,

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

Type: series
Message-id: 1515788548-3570-1-git-send-email-juterry@microsoft.com
Subject: [Qemu-devel] [PATCH 0/4] Implements the Windows Hypervisor Platform accelerator

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
c9a68bcd96 Add the WHPX acceleration enlightenments
03377875bf Introduce the WHPX impl
4fb340d015 Add the WHPX vcpu API
a4e1eebb6a Add the Windows Hypervisor Platform accelerator.

=== OUTPUT BEGIN ===
Checking PATCH 1/4: Add the Windows Hypervisor Platform accelerator....
Checking PATCH 2/4: Add the WHPX vcpu API...
ERROR: adding a line without newline at end of file
#126: FILE: include/sysemu/whpx.h:40:
+#endif /* QEMU_WHPX_H */

total: 1 errors, 0 warnings, 97 lines checked

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

Checking PATCH 3/4: Introduce the WHPX impl...
ERROR: do not use C99 // comments
#71: FILE: target/i386/whpx-all.c:38:
+    // X64 General purpose registers

ERROR: do not use C99 // comments
#91: FILE: target/i386/whpx-all.c:58:
+    // X64 Segment registers

ERROR: do not use C99 // comments
#101: FILE: target/i386/whpx-all.c:68:
+    // X64 Table registers

ERROR: do not use C99 // comments
#105: FILE: target/i386/whpx-all.c:72:
+    // X64 Control Registers

ERROR: do not use C99 // comments
#112: FILE: target/i386/whpx-all.c:79:
+    // X64 Debug Registers

ERROR: do not use C99 // comments
#113: FILE: target/i386/whpx-all.c:80:
+//    WHvX64RegisterDr0,

ERROR: do not use C99 // comments
#114: FILE: target/i386/whpx-all.c:81:
+//    WHvX64RegisterDr1,

ERROR: do not use C99 // comments
#115: FILE: target/i386/whpx-all.c:82:
+//    WHvX64RegisterDr2,

ERROR: do not use C99 // comments
#116: FILE: target/i386/whpx-all.c:83:
+//    WHvX64RegisterDr3,

ERROR: do not use C99 // comments
#117: FILE: target/i386/whpx-all.c:84:
+//    WHvX64RegisterDr6,

ERROR: do not use C99 // comments
#118: FILE: target/i386/whpx-all.c:85:
+//    WHvX64RegisterDr7,

ERROR: do not use C99 // comments
#120: FILE: target/i386/whpx-all.c:87:
+    // X64 Floating Point and Vector Registers

ERROR: do not use C99 // comments
#148: FILE: target/i386/whpx-all.c:115:
+    // X64 MSRs

ERROR: do not use C99 // comments
#155: FILE: target/i386/whpx-all.c:122:
+//    WHvX64RegisterPat,

ERROR: do not use C99 // comments
#166: FILE: target/i386/whpx-all.c:133:
+    // Interrupt / Event Registers

ERROR: do not use C99 // comments
#167: FILE: target/i386/whpx-all.c:134:
+//    WHvRegisterPendingInterruption,

ERROR: do not use C99 // comments
#168: FILE: target/i386/whpx-all.c:135:
+//    WHvRegisterInterruptState,

ERROR: do not use C99 // comments
#169: FILE: target/i386/whpx-all.c:136:
+//    WHvRegisterPendingEvent0,

ERROR: do not use C99 // comments
#170: FILE: target/i386/whpx-all.c:137:
+//    WHvRegisterPendingEvent1

ERROR: do not use C99 // comments
#171: FILE: target/i386/whpx-all.c:138:
+//    WHvX64RegisterDeliverabilityNotifications,

ERROR: "foo* bar" should be "foo *bar"
#199: FILE: target/i386/whpx-all.c:166:
+static struct whpx_vcpu* get_whpx_vcpu(CPUState* cpu)

ERROR: "(foo*)" should be "(foo *)"
#201: FILE: target/i386/whpx-all.c:168:
+    return (struct whpx_vcpu*)cpu->hax_vcpu;

WARNING: line over 80 characters
#204: FILE: target/i386/whpx-all.c:171:
+static WHV_X64_SEGMENT_REGISTER whpx_seg_q2h(const SegmentCache *qs, int v86, int r86)

ERROR: do not use C99 // comments
#232: FILE: target/i386/whpx-all.c:199:
+            //hs.Base &= 0xfffff;

ERROR: "foo* bar" should be "foo *bar"
#273: FILE: target/i386/whpx-all.c:240:
+static void whpx_set_registers(CPUState* cpu)

ERROR: "foo* bar" should be "foo *bar"
#276: FILE: target/i386/whpx-all.c:243:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

ERROR: "(foo*)" should be "(foo *)"
#277: FILE: target/i386/whpx-all.c:244:
+    struct CPUX86State* env = (CPUArchState*)(cpu->env_ptr);

ERROR: do not use C99 // comments
#356: FILE: target/i386/whpx-all.c:323:
+        //vcxt.values[idx].Fp.AsUINT128.High64 = env->fpregs[i].mmx.MMX_Q(1);

WARNING: line over 80 characters
#422: FILE: target/i386/whpx-all.c:389:
+        error_report("WHPX: Failed to set virtual processor context, hr=%08lx", hr);

ERROR: "foo* bar" should be "foo *bar"
#429: FILE: target/i386/whpx-all.c:396:
+static void whpx_get_registers(CPUState* cpu)

ERROR: "foo* bar" should be "foo *bar"
#432: FILE: target/i386/whpx-all.c:399:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

ERROR: "(foo*)" should be "(foo *)"
#433: FILE: target/i386/whpx-all.c:400:
+    struct CPUX86State* env = (CPUArchState*)(cpu->env_ptr);

WARNING: line over 80 characters
#448: FILE: target/i386/whpx-all.c:415:
+        error_report("WHPX: Failed to get virtual processor context, hr=%08lx", hr);

ERROR: do not use C99 // comments
#511: FILE: target/i386/whpx-all.c:478:
+        //env->fpregs[i].mmx.MMX_Q(1) = vcxt.values[idx].Fp.AsUINT128.High64;

WARNING: line over 80 characters
#575: FILE: target/i386/whpx-all.c:542:
+                                                WHV_EMULATOR_IO_ACCESS_INFO* IoAccess)

ERROR: "foo* bar" should be "foo *bar"
#575: FILE: target/i386/whpx-all.c:542:
+                                                WHV_EMULATOR_IO_ACCESS_INFO* IoAccess)

ERROR: line over 90 characters
#579: FILE: target/i386/whpx-all.c:546:
+                     (uint8_t*)&IoAccess->Data, IoAccess->AccessSize, IoAccess->Direction);

ERROR: "(foo*)" should be "(foo *)"
#579: FILE: target/i386/whpx-all.c:546:
+                     (uint8_t*)&IoAccess->Data, IoAccess->AccessSize, IoAccess->Direction);

WARNING: line over 80 characters
#584: FILE: target/i386/whpx-all.c:551:
+                                               WHV_EMULATOR_MEMORY_ACCESS_INFO* ma)

ERROR: "foo* bar" should be "foo *bar"
#584: FILE: target/i386/whpx-all.c:551:
+                                               WHV_EMULATOR_MEMORY_ACCESS_INFO* ma)

WARNING: line over 80 characters
#586: FILE: target/i386/whpx-all.c:553:
+    cpu_physical_memory_rw(ma->GpaAddress, ma->Data, ma->AccessSize, ma->Direction);

WARNING: line over 80 characters
#591: FILE: target/i386/whpx-all.c:558:
+                                                const WHV_REGISTER_NAME* RegisterNames,

ERROR: "foo* bar" should be "foo *bar"
#591: FILE: target/i386/whpx-all.c:558:
+                                                const WHV_REGISTER_NAME* RegisterNames,

WARNING: line over 80 characters
#593: FILE: target/i386/whpx-all.c:560:
+                                                WHV_REGISTER_VALUE* RegisterValues)

ERROR: "foo* bar" should be "foo *bar"
#593: FILE: target/i386/whpx-all.c:560:
+                                                WHV_REGISTER_VALUE* RegisterValues)

ERROR: "(foo*)" should be "(foo *)"
#597: FILE: target/i386/whpx-all.c:564:
+    CPUState* cpu = (CPUState*)ctx;

WARNING: line over 80 characters
#603: FILE: target/i386/whpx-all.c:570:
+        error_report("WHPX: Failed to get virtual processor registers, hr=%08lx", hr);

WARNING: line over 80 characters
#611: FILE: target/i386/whpx-all.c:578:
+                                                const WHV_REGISTER_NAME* RegisterNames,

ERROR: "foo* bar" should be "foo *bar"
#611: FILE: target/i386/whpx-all.c:578:
+                                                const WHV_REGISTER_NAME* RegisterNames,

WARNING: line over 80 characters
#613: FILE: target/i386/whpx-all.c:580:
+                                                const WHV_REGISTER_VALUE* RegisterValues)

ERROR: "foo* bar" should be "foo *bar"
#613: FILE: target/i386/whpx-all.c:580:
+                                                const WHV_REGISTER_VALUE* RegisterValues)

ERROR: "(foo*)" should be "(foo *)"
#617: FILE: target/i386/whpx-all.c:584:
+    CPUState* cpu = (CPUState*)ctx;

WARNING: line over 80 characters
#623: FILE: target/i386/whpx-all.c:590:
+        error_report("WHPX: Failed to set virtual processor registers, hr=%08lx", hr);

WARNING: line over 80 characters
#631: FILE: target/i386/whpx-all.c:598:
+                                                   WHV_GUEST_VIRTUAL_ADDRESS Gva,

WARNING: line over 80 characters
#632: FILE: target/i386/whpx-all.c:599:
+                                                   WHV_TRANSLATE_GVA_FLAGS TranslateFlags,

ERROR: line over 90 characters
#633: FILE: target/i386/whpx-all.c:600:
+                                                   WHV_TRANSLATE_GVA_RESULT_CODE* TranslationResult,

ERROR: "foo* bar" should be "foo *bar"
#633: FILE: target/i386/whpx-all.c:600:
+                                                   WHV_TRANSLATE_GVA_RESULT_CODE* TranslationResult,

WARNING: line over 80 characters
#634: FILE: target/i386/whpx-all.c:601:
+                                                   WHV_GUEST_PHYSICAL_ADDRESS* Gpa)

ERROR: "foo* bar" should be "foo *bar"
#634: FILE: target/i386/whpx-all.c:601:
+                                                   WHV_GUEST_PHYSICAL_ADDRESS* Gpa)

ERROR: "(foo*)" should be "(foo *)"
#638: FILE: target/i386/whpx-all.c:605:
+    CPUState* cpu = (CPUState*)ctx;

ERROR: "foo* bar" should be "foo *bar"
#663: FILE: target/i386/whpx-all.c:630:
+                                            WHV_VP_EXIT_CONTEXT* vp_ctx,

ERROR: "foo* bar" should be "foo *bar"
#664: FILE: target/i386/whpx-all.c:631:
+                                            uint8_t* bytes, uint8_t* count,

ERROR: "foo* bar" should be "foo *bar"
#714: FILE: target/i386/whpx-all.c:681:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

WARNING: line over 80 characters
#738: FILE: target/i386/whpx-all.c:705:
+static int whpx_handle_portio(CPUState *cpu, WHV_X64_IO_PORT_ACCESS_CONTEXT* ctx)

ERROR: "foo* bar" should be "foo *bar"
#741: FILE: target/i386/whpx-all.c:708:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

ERROR: "(foo*)" should be "(foo *)"
#767: FILE: target/i386/whpx-all.c:734:
+    struct CPUX86State* env = (CPUArchState*)(cpu->env_ptr);

ERROR: "foo* bar" should be "foo *bar"
#787: FILE: target/i386/whpx-all.c:754:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

ERROR: "(foo*)" should be "(foo *)"
#788: FILE: target/i386/whpx-all.c:755:
+    struct CPUX86State* env = (CPUArchState*)(cpu->env_ptr);

WARNING: line over 80 characters
#862: FILE: target/i386/whpx-all.c:829:
+        reg_values[reg_count].DeliverabilityNotifications.InterruptNotification = 1;

ERROR: line over 90 characters
#864: FILE: target/i386/whpx-all.c:831:
+    if (vcpu->window_registered != reg_values[reg_count].DeliverabilityNotifications.InterruptNotification) {

ERROR: line over 90 characters
#865: FILE: target/i386/whpx-all.c:832:
+        vcpu->window_registered = reg_values[reg_count].DeliverabilityNotifications.InterruptNotification;

WARNING: line over 80 characters
#876: FILE: target/i386/whpx-all.c:843:
+            error_report("WHPX: Failed o set interrupt state registers, hr=%08lx", hr);

ERROR: "foo* bar" should be "foo *bar"
#888: FILE: target/i386/whpx-all.c:855:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

ERROR: "(foo*)" should be "(foo *)"
#889: FILE: target/i386/whpx-all.c:856:
+    struct CPUX86State* env = (CPUArchState*)(cpu->env_ptr);

WARNING: line over 80 characters
#902: FILE: target/i386/whpx-all.c:869:
+        error_report("WHPX: Failed to get interrupt state regusters, hr=%08lx", hr);

ERROR: "(foo*)" should be "(foo *)"
#930: FILE: target/i386/whpx-all.c:897:
+    struct CPUX86State* env = (CPUArchState*)(cpu->env_ptr);

ERROR: "foo* bar" should be "foo *bar"
#932: FILE: target/i386/whpx-all.c:899:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

ERROR: "foo* bar" should be "foo *bar"
#976: FILE: target/i386/whpx-all.c:943:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

WARNING: line over 80 characters
#1007: FILE: target/i386/whpx-all.c:974:
+                WHvCancelRunVirtualProcessor(whpx->partition, cpu->cpu_index, 0);

WARNING: line over 80 characters
#1014: FILE: target/i386/whpx-all.c:981:
+            error_report("WHPX: Failed to exec a virtual processor, hr=%08lx", hr);

WARNING: line over 80 characters
#1051: FILE: target/i386/whpx-all.c:1018:
+            error_report("WHPX: Unexpected VP exit code %d", vcpu->exit_ctx.ExitReason);

WARNING: line over 80 characters
#1083: FILE: target/i386/whpx-all.c:1050:
+static void do_whpx_cpu_synchronize_post_init(CPUState *cpu, run_on_cpu_data arg)

WARNING: line over 80 characters
#1089: FILE: target/i386/whpx-all.c:1056:
+static void do_whpx_cpu_synchronize_pre_loadvm(CPUState *cpu, run_on_cpu_data arg)

ERROR: "foo* bar" should be "foo *bar"
#1128: FILE: target/i386/whpx-all.c:1095:
+    struct whpx_vcpu* vcpu;

ERROR: line over 90 characters
#1140: FILE: target/i386/whpx-all.c:1107:
+        error_report("WHPX: Failed to setup instruction completion support, hr=%08lx", hr);

WARNING: line over 80 characters
#1147: FILE: target/i386/whpx-all.c:1114:
+        error_report("WHPX: Failed to create a virtual processor, hr=%08lx", hr);

ERROR: "(foo*)" should be "(foo *)"
#1156: FILE: target/i386/whpx-all.c:1123:
+    cpu->hax_vcpu = (struct hax_vcpu_state*)vcpu;

ERROR: "foo* bar" should be "foo *bar"
#1187: FILE: target/i386/whpx-all.c:1154:
+    struct whpx_vcpu* vcpu = get_whpx_vcpu(cpu);

ERROR: "foo* bar" should be "foo *bar"
#1205: FILE: target/i386/whpx-all.c:1172:
+static void whpx_update_mapping(hwaddr start_pa, ram_addr_t size, void* host_va,

ERROR: "foo* bar" should be "foo *bar"
#1206: FILE: target/i386/whpx-all.c:1173:
+                               int add, int rom, const char* name)

ERROR: "(foo*)" should be "(foo *)"
#1240: FILE: target/i386/whpx-all.c:1207:
+                     (void*)start_pa, (void*)size, host_va, hr);

ERROR: "(foo*)" should be "(foo *)"
#1271: FILE: target/i386/whpx-all.c:1238:
+    whpx_update_mapping(start_pa, size, (void*)host_va, add,

ERROR: line over 90 characters
#1349: FILE: target/i386/whpx-all.c:1316:
+    hr = WHvGetCapability(WHvCapabilityCodeHypervisorPresent, &whpx_cap, sizeof(whpx_cap));

total: 68 errors, 25 warnings, 1399 lines checked

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

Checking PATCH 4/4: Add the WHPX acceleration enlightenments...
=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org