[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wntb7vke.fsf@vitty.brq.redhat.com>
Date: Fri, 09 Apr 2021 09:42:41 +0200
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Siddharth Chandrasekaran <sidcha@...zon.de>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kys@...rosoft.com,
haiyangz@...rosoft.com, sthemmin@...rosoft.com, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com,
seanjc@...gle.com, wanpengli@...cent.com, jmattson@...gle.com,
joro@...tes.org, graf@...zon.com, eyakovl@...zon.de,
linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, Wei Liu <wei.liu@...nel.org>
Subject: Re: [PATCH 0/4] Add support for XMM fast hypercalls
Siddharth Chandrasekaran <sidcha@...zon.de> writes:
> On Thu, Apr 08, 2021 at 04:30:18PM +0000, Wei Liu wrote:
>> On Thu, Apr 08, 2021 at 05:54:43PM +0200, Siddharth Chandrasekaran wrote:
>> > On Thu, Apr 08, 2021 at 05:48:19PM +0200, Paolo Bonzini wrote:
>> > > On 08/04/21 17:40, Siddharth Chandrasekaran wrote:
>> > > > > > > Although the Hyper-v TLFS mentions that a guest cannot use this feature
>> > > > > > > unless the hypervisor advertises support for it, some hypercalls which
>> > > > > > > we plan on upstreaming in future uses them anyway.
>> > > > > > No, please don't do this. Check the feature bit(s) before you issue
>> > > > > > hypercalls which rely on the extended interface.
>> > > > > Perhaps Siddharth should clarify this, but I read it as Hyper-V being
>> > > > > buggy and using XMM arguments unconditionally.
>> > > > The guest is at fault here as it expects Hyper-V to consume arguments
>> > > > from XMM registers for certain hypercalls (that we are working) even if
>> > > > we didn't expose the feature via CPUID bits.
>> > >
>> > > What guest is that?
>> >
>> > It is a Windows Server 2016.
>>
>> Can you be more specific? Are you implementing some hypercalls from
>> TLFS? If so, which ones?
>
> Yes all of them are from TLFS. We are implementing VSM and there are a
> bunch of hypercalls that we have implemented to manage VTL switches,
> memory protection and virtual interrupts.
Wow, sounds awesome! Do you plan to upstream this work?
> The following 3 hypercalls that use the XMM fast hypercalls are relevant
> to this patch set:
>
> HvCallModifyVtlProtectionMask
> HvGetVpRegisters
> HvSetVpRegisters
It seems AccessVSM and AccessVpRegisters privilges have implicit
dependency on XMM input/output. This will need to be enforced in KVM
userspace.
--
Vitaly
Powered by blists - more mailing lists