Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1270427 > unrolled thread

Re: [PATCH] kvm/vmx: EPTP switching test

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] kvm/vmx: EPTP switching test =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com> - 2015-11-16 19:00 +0100
    Re: [PATCH] kvm/vmx: EPTP switching test "Michael S. Tsirkin" <mst@redhat.com> - 2015-11-16 19:10 +0100
      Re: [PATCH] kvm/vmx: EPTP switching test =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com> - 2015-11-16 19:20 +0100
        Re: [PATCH] kvm/vmx: EPTP switching test Andy Lutomirski <luto@amacapital.net> - 2015-11-16 20:00 +0100
        Re: [PATCH] kvm/vmx: EPTP switching test Paolo Bonzini <pbonzini@redhat.com> - 2015-11-17 10:30 +0100

#1270427 — Re: [PATCH] kvm/vmx: EPTP switching test

2015-11-15 18:00+0200, Michael S. Tsirkin:
> This patch adds a new parameter: eptp_switching_test, which enables
> 
> testing EPT switching on VMX if supported by hardware.  All EPT entries
> are initialized to the same value so this adds no useful functionality
> by itself, but can be used to test VMFUNC performance, and serve as a
> basis for future features based on EPTP switching.
> 
> Support for nested virt is not enabled.
> 
> This was tested using the following code within guest:
> 	#define VMX_VMFUNC ".byte 0x0f,0x01,0xd4"
> 	static void vmfunc(unsigned int nr, unsigned int ept)
> 	{
> 		asm volatile(VMX_VMFUNC
> 			     :
> 			     : "a"(nr), "c"(ept)
> 			     : "memory");
> 	}
> 
> VMFUNC instruction cost was measured at ~122 cycles.
> (Note: recent versions of gnu toolchain support
>  the vmfunc instruction - removing the need for writing
>  the bytecode manually).
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> 
> I think I'd like to put this upstream so future eptp switching work can
> be implemented on top. Comments?

I'd wait for the future.  Patch is already on the list so people
interested in benchmarking VMFUNC can quickly compile a kernel and
developers will need to overwrite the code anyway.

(And I think that eptp switching is expected to be used in conjuction
 with #VE, so it'd then make sense to implement a nop for it as well.)

> diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> @@ -3011,6 +3035,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf)
>  			SECONDARY_EXEC_PAUSE_LOOP_EXITING |
>  			SECONDARY_EXEC_RDTSCP |
>  			SECONDARY_EXEC_ENABLE_INVPCID |
> +			SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |

The VMFUNC vmexit should be handled to prevent guests from triggering a
WARN_ON on the host.  (VMFUNC did just #UD before this patch.)

After that, it's ok for KVM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1270438

On Mon, Nov 16, 2015 at 06:51:06PM +0100, =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= wrote:
> 2015-11-15 18:00+0200, Michael S. Tsirkin:
> > This patch adds a new parameter: eptp_switching_test, which enables
> > 
> > testing EPT switching on VMX if supported by hardware.  All EPT entries
> > are initialized to the same value so this adds no useful functionality
> > by itself, but can be used to test VMFUNC performance, and serve as a
> > basis for future features based on EPTP switching.
> > 
> > Support for nested virt is not enabled.
> > 
> > This was tested using the following code within guest:
> > 	#define VMX_VMFUNC ".byte 0x0f,0x01,0xd4"
> > 	static void vmfunc(unsigned int nr, unsigned int ept)
> > 	{
> > 		asm volatile(VMX_VMFUNC
> > 			     :
> > 			     : "a"(nr), "c"(ept)
> > 			     : "memory");
> > 	}
> > 
> > VMFUNC instruction cost was measured at ~122 cycles.
> > (Note: recent versions of gnu toolchain support
> >  the vmfunc instruction - removing the need for writing
> >  the bytecode manually).
> > 
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > 
> > I think I'd like to put this upstream so future eptp switching work can
> > be implemented on top. Comments?
> 
> I'd wait for the future.  Patch is already on the list so people
> interested in benchmarking VMFUNC can quickly compile a kernel and
> developers will need to overwrite the code anyway.

It'll bitrot though.  But I'll let Paolo decide that.

> (And I think that eptp switching is expected to be used in conjuction
>  with #VE, so it'd then make sense to implement a nop for it as well.)

No idea how would I even test it, so I'm not interested in #VE at this
point.  If you are - go ahead and post a patch for that on top though,
why not.

> > diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
> > @@ -3011,6 +3035,7 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf)
> >  			SECONDARY_EXEC_PAUSE_LOOP_EXITING |
> >  			SECONDARY_EXEC_RDTSCP |
> >  			SECONDARY_EXEC_ENABLE_INVPCID |
> > +			SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
> 
> The VMFUNC vmexit should be handled to prevent guests from triggering a
> WARN_ON on the host.  (VMFUNC did just #UD before this patch.)

Do you mean VMFUNC other than EPTP switch 0?  True, thanks!

> 
> After that, it's ok for KVM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1270442

2015-11-16 19:59+0200, Michael S. Tsirkin:
> On Mon, Nov 16, 2015 at 06:51:06PM +0100, =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= wrote:
>> 2015-11-15 18:00+0200, Michael S. Tsirkin:
>> (And I think that eptp switching is expected to be used in conjuction
>>  with #VE, so it'd then make sense to implement a nop for it as well.)
> 
> No idea how would I even test it, so I'm not interested in #VE at this
> point.  If you are - go ahead and post a patch for that on top though,
> why not.

I thought that it's going to be simpler to provide functionality (that
utilizes eptp switching) to the guest through #VE, which probably isn't
true as I think more about it.  (Not interested in implementing it :])
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1270477

On Mon, Nov 16, 2015 at 10:18 AM,
=?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com> wrote:
> 2015-11-16 19:59+0200, Michael S. Tsirkin:
>> On Mon, Nov 16, 2015 at 06:51:06PM +0100, =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= wrote:
>>> 2015-11-15 18:00+0200, Michael S. Tsirkin:
>>> (And I think that eptp switching is expected to be used in conjuction
>>>  with #VE, so it'd then make sense to implement a nop for it as well.)
>>
>> No idea how would I even test it, so I'm not interested in #VE at this
>> point.  If you are - go ahead and post a patch for that on top though,
>> why not.
>
> I thought that it's going to be simpler to provide functionality (that
> utilizes eptp switching) to the guest through #VE, which probably isn't
> true as I think more about it.  (Not interested in implementing it :])

I'm willing to review a #VE stub.  I'm not likely to implement it.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1271002

On 16/11/2015 19:18, =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= wrote:
>> > No idea how would I even test it, so I'm not interested in #VE at this
>> > point.  If you are - go ahead and post a patch for that on top though,
>> > why not.
> I thought that it's going to be simpler to provide functionality (that
> utilizes eptp switching) to the guest through #VE, which probably isn't
> true as I think more about it.  (Not interested in implementing it :])

#VE and EPTP switching are distinct features, one does not imply the other.

Unfortunately, EPTP switching is designed for a very specific use case
where the hypervisor is effectively part of the kernel, and the kernel
is trusted to some extent.  Examples include antivirus software and
virtual machines.  Antiviruses do use VMFUNC, that's as far as I know
the only current use case of it
(https://embedded.communities.intel.com/community/en/applications/blog/2013/06/13/roving-reporter-enhancing-retail-security-and-manageability-with-4th-generation-intel-core-processors).

So I'm against this patch, but only because I'm not sure why KVM would
ever use EPTP switching in its current incarnation.  The guest kernel is
absolutely not trusted by KVM.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web