On 16/05/2018 16:18, Justin Terry (VM) via Qemu-devel wrote:
> Hey Paolo,
>
> I agree that in the future it would be great if the Windows
> Hypervisor Platform supported that and if that happens there is no
> reason to differentiate the two.
>
> However, today WHPX actually doesn’t support any of the synthetic
> enlightenments that Hyper-V does. We are really trying to make the
> Windows Hypervisor Platform a generic hypervisor where as Hyper-V is
> a specific implementation on top of that hypervisor (and QEMU is
> another such implementation). For example, VMBus was mentioned but as
> it stands today, VMBus is not supported in WHPX due to lack of
> support for hypercalls. Additionally, timer enlightenments that you
> mentioned would not be supported through synthetic paths and instead
> run emulated as devices (hpet etc.).
Sorry I missed this email. Note that I didn't mention timer
enlightenments, I mentioned relaxed timing, CPUID[0x40000004].EAX[bit
5]. These are the main reason to implement Hyper-V interfaces in
non-Hyper-V hypervisors, otherwise Windows will bugcheck with STOP 0x101
under load.
The question is why you need to implement a CPUID signature. The guest
OS should not care about the hypervisor that hosts it, and indeed
Windows works well without detecting Xen, KVM, etc. It only detects the
Hyper-V interface that is presented by those hypervisors. Implementing
and documenting a QEMU-specific hypervisor interface has a potentially
large future cost, and it would be preferrable to implement an existing
hypervisor interface for QEMU with WHPX.
> I hope this adds some clarity here for why WHPX doesn’t implement
> hyperv-proto.h as Hyper-V != Windows Hypervisor Platform in many
> aspects. Please let me know if there is anything else I can explain
> to help clarify the two.
Non-Hyper-V hypervisors can provide the Hyper-V interfaces with no
hypercalls and the three synthetic MSRs HV_X64_MSR_GUEST_OS_ID,
HV_X64_MSR_HYPERCALL and HV_X64_MSR_VP_INDEX.
This should not be hard. For example at least KVM and Xen don't make
the hypercall page an overlay; they just replace the old contents with a
vmcall+ret sequence, which simplifies noticeably the implementation.
Does WHPX allow trapping hypercalls? If not, a stopgap implementation
could be to put something like this in the hypercall page
xor eax, eax
// The next byte sets eax=1 and zf=0 in 32-bit mode
// In 64-bit mode it is decoded together with the JZ
db 0x40
jz is_64_bit
// Zero edx in 32-bit mode
cdq
is_64_bit:
// HV_STATUS_INVALID_HYPERCALL_CODE
mov al,2
ret
It would not satisfy the requirement of trapping in real mode or at
CPL=3, and it would clobber the zero flag, but perhaps it's better than
nothing.
Paolo
>
>> -----Original Message----- From: Paolo Bonzini
>> <pbonz...@redhat.com> Sent: Wednesday, May 16, 2018 12:35 AM To:
>> apilotti <apilo...@cloudbasesolutions.com> Cc:
>> petrutlucia...@gmail.com; Lucian Petrut
>> <lpet...@cloudbasesolutions.com>; Eduardo Habkost
>> <ehabk...@redhat.com>; open list:All patches CC here <qemu-
>> de...@nongnu.org>; Justin Terry (VM) <jute...@microsoft.com>;
>> Richard Henderson <r...@twiddle.net> Subject: Re: [Qemu-devel]
>> [PATCH] WHPX Add signature CPUID
>>
>> On 16/05/2018 01:55, Alessandro Pilotti wrote:
>>> Hi Paolo,
>>>
>>> The main reason for different signatures is to allow guest
>>> workloads to be aware of the differences between the two
>>> platforms (eg VirtIO vs VMBus).
>>
>> Why does it matter? CPUID tells you about the enlightenments that
>> the hypervisor provides, not the availability of the VMBus.
>>
>> VMBus requires some of the enlightenments, mostly related to the
>> synthetic interrupt controllers, but the opposite is not true---you
>> can have enlightenments without VMBus, and in fact you probably
>> want WHPX to enable the relaxed timing enlightenment.
>>
>> Thanks,
>>
>> Paolo
