[RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Ryan Harper]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Playing around with running VMware-server within a KVM guest and noticed
that whenever we launch a VM within the guest, KVM reports a GP fault in
set_cr3.  Removing the fault injection (raised for attempting to set
reserved bits) for the non-pae case allows memtest to boot and run 
within VMWare Server, running in a KVM Linux guest.

This same test (Linux, VMware-server, booting/running memtest iso) works
fine on bare-metal.  Thoughts?

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

[-- Attachment #2: ignore_gp_fault_in_nonpae_paging.patch --]
[-- Type: text/plain, Size: 789 bytes --]


This patch removes the fault injected when the guest attempts to set reserved
bits in cr3.  X86 hardware doesn't generate a fault when setting reserved bits.
The result of this patch is that vmware-server, running within a kvm guest,
boots and runs memtest from an iso.

Signed-off-by: Ryan Harper <ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 353e585..386f9c1 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -573,13 +573,6 @@ void set_cr3(struct kvm_vcpu *vcpu, unsigned long cr3)
 				inject_gp(vcpu);
 				return;
 			}
-		} else {
-			if (cr3 & CR3_NONPAE_RESERVED_BITS) {
-				printk(KERN_DEBUG
-				       "set_cr3: #GP, reserved bits\n");
-				inject_gp(vcpu);
-				return;
-			}
 		}
 	}
 

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Anthony Liguori]

Ryan Harper wrote:
> Playing around with running VMware-server within a KVM guest and noticed
> that whenever we launch a VM within the guest, KVM reports a GP fault in
> set_cr3.  Removing the fault injection (raised for attempting to set
> reserved bits) for the non-pae case allows memtest to boot and run 
> within VMWare Server, running in a KVM Linux guest.
>
> This same test (Linux, VMware-server, booting/running memtest iso) works
> fine on bare-metal.  Thoughts?
>   

Setting reserved bits is different from setting MBZ bits since the 
behaviors undefined.  If something as common as VMware is depending on 
being able to set a reserved bit then perhaps the right thing to do from 
KVM's perspective is to let it.

I'm curious if Zach or Jun have any comments about the right thing to do 
here.

Regards,

Anthony Liguori

> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Nakajima, Jun]

Anthony Liguori wrote:
> Ryan Harper wrote:
> > Playing around with running VMware-server within a KVM guest and
noticed
> > that whenever we launch a VM within the guest, KVM reports a GP
fault in
> > set_cr3.  Removing the fault injection (raised for attempting to set
> > reserved bits) for the non-pae case allows memtest to boot and run
> > within VMWare Server, running in a KVM Linux guest.
> > 
> > This same test (Linux, VMware-server, booting/running memtest iso)
works
> > fine on bare-metal.  Thoughts?
> > 
> 
> Setting reserved bits is different from setting MBZ bits since the
> behaviors undefined.  If something as common as VMware is depending on
> being able to set a reserved bit then perhaps the right thing to do
from
> KVM's perspective is to let it.
> 
> I'm curious if Zach or Jun have any comments about the right thing to
do
> here.
> 

As long as the guest is protected mode (unlike the long mode), the Intel
spec does _not_ say that reserved bits checking is enforced for CR3. As
far as I looked at the AMD spec, looks like #GP is caused even in
protected mode... Does the test work for AMD systems?

> Regards,
> 
> Anthony Liguori
> 


Jun
---
Intel Open Source Technology Center

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Ryan Harper]

* Nakajima, Jun <jun.nakajima-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> [2007-09-18 16:22]:
> Anthony Liguori wrote:
> > Ryan Harper wrote:
> > > Playing around with running VMware-server within a KVM guest and
> noticed
> > > that whenever we launch a VM within the guest, KVM reports a GP
> fault in
> > > set_cr3.  Removing the fault injection (raised for attempting to set
> > > reserved bits) for the non-pae case allows memtest to boot and run
> > > within VMWare Server, running in a KVM Linux guest.
> > > 
> > > This same test (Linux, VMware-server, booting/running memtest iso)
> works
> > > fine on bare-metal.  Thoughts?
> > > 
> > 
> > Setting reserved bits is different from setting MBZ bits since the
> > behaviors undefined.  If something as common as VMware is depending on
> > being able to set a reserved bit then perhaps the right thing to do
> from
> > KVM's perspective is to let it.
> > 
> > I'm curious if Zach or Jun have any comments about the right thing to
> do
> > here.
> > 
> 
> As long as the guest is protected mode (unlike the long mode), the Intel
> spec does _not_ say that reserved bits checking is enforced for CR3. As
> far as I looked at the AMD spec, looks like #GP is caused even in
> protected mode... Does the test work for AMD systems?

I ran my test on an AMD host.

> 
> > Regards,
> > 
> > Anthony Liguori
> > 
> 
> 
> Jun
> ---
> Intel Open Source Technology Center

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Nakajima, Jun]

Ryan Harper wrote:
> * Nakajima, Jun <jun.nakajima-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> [2007-09-18 16:22]:
> > Anthony Liguori wrote:
> > > Ryan Harper wrote:
> > > > Playing around with running VMware-server within a KVM guest and
noticed
> > > > that whenever we launch a VM within the guest, KVM reports a GP
fault in
> > > > set_cr3.  Removing the fault injection (raised for attempting to
set
> > > > reserved bits) for the non-pae case allows memtest to boot and
run
> > > > within VMWare Server, running in a KVM Linux guest.
> > > > 
> > > > This same test (Linux, VMware-server, booting/running memtest
iso) works
> > > > fine on bare-metal.  Thoughts?
> > > > 
> > > 
> > > Setting reserved bits is different from setting MBZ bits since the
> > > behaviors undefined.  If something as common as VMware is
depending on
> > > being able to set a reserved bit then perhaps the right thing to
do from
> > > KVM's perspective is to let it.
> > > 
> > > I'm curious if Zach or Jun have any comments about the right thing
to do
> > > here. 
> > > 
> > 
> > As long as the guest is protected mode (unlike the long mode), the
Intel
> > spec does _not_ say that reserved bits checking is enforced for CR3.
As
> > far as I looked at the AMD spec, looks like #GP is caused even in
> > protected mode... Does the test work for AMD systems?
> 
> I ran my test on an AMD host.

Well then the patch sounds fine to me.

Jun
---
Intel Open Source Technology Center

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Zachary Amsden]

On Tue, 2007-09-18 at 16:25 -0500, Ryan Harper wrote:
> * Nakajima, Jun <jun.nakajima-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> [2007-09-18 16:22]:
> > Anthony Liguori wrote:
> > > Ryan Harper wrote:
> > > > Playing around with running VMware-server within a KVM guest and
> > noticed
> > > > that whenever we launch a VM within the guest, KVM reports a GP
> > fault in
> > > > set_cr3.  Removing the fault injection (raised for attempting to set
> > > > reserved bits) for the non-pae case allows memtest to boot and run
> > > > within VMWare Server, running in a KVM Linux guest.
> > > > 
> > > > This same test (Linux, VMware-server, booting/running memtest iso)
> > works
> > > > fine on bare-metal.  Thoughts?
> > > > 
> > > 
> > > Setting reserved bits is different from setting MBZ bits since the
> > > behaviors undefined.  If something as common as VMware is depending on
> > > being able to set a reserved bit then perhaps the right thing to do
> > from
> > > KVM's perspective is to let it.
> > > 
> > > I'm curious if Zach or Jun have any comments about the right thing to
> > do
> > > here.
> > > 
> > 
> > As long as the guest is protected mode (unlike the long mode), the Intel
> > spec does _not_ say that reserved bits checking is enforced for CR3. As
> > far as I looked at the AMD spec, looks like #GP is caused even in
> > protected mode... Does the test work for AMD systems?
> 
> I ran my test on an AMD host.

We have a test which verifies #GP is not caused by setting the bits on
either AMD or Intel chips.  "Stray" bits can get turned on in some cases
when switching between 64-bit, PAE and non-PAE address modes.

Were you testing on a 64-bit host kernel?

Zach


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Ryan Harper]

* Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> [2007-09-18 16:59]:
> On Tue, 2007-09-18 at 16:25 -0500, Ryan Harper wrote:
> > * Nakajima, Jun <jun.nakajima-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> [2007-09-18 16:22]:
> > > Anthony Liguori wrote:
> > > > Ryan Harper wrote:
> > > > > Playing around with running VMware-server within a KVM guest and
> > > noticed
> > > > > that whenever we launch a VM within the guest, KVM reports a GP
> > > fault in
> > > > > set_cr3.  Removing the fault injection (raised for attempting to set
> > > > > reserved bits) for the non-pae case allows memtest to boot and run
> > > > > within VMWare Server, running in a KVM Linux guest.
> > > > > 
> > > > > This same test (Linux, VMware-server, booting/running memtest iso)
> > > works
> > > > > fine on bare-metal.  Thoughts?
> > > > > 
> > > > 
> > > > Setting reserved bits is different from setting MBZ bits since the
> > > > behaviors undefined.  If something as common as VMware is depending on
> > > > being able to set a reserved bit then perhaps the right thing to do
> > > from
> > > > KVM's perspective is to let it.
> > > > 
> > > > I'm curious if Zach or Jun have any comments about the right thing to
> > > do
> > > > here.
> > > > 
> > > 
> > > As long as the guest is protected mode (unlike the long mode), the Intel
> > > spec does _not_ say that reserved bits checking is enforced for CR3. As
> > > far as I looked at the AMD spec, looks like #GP is caused even in
> > > protected mode... Does the test work for AMD systems?
> > 
> > I ran my test on an AMD host.
> 
> We have a test which verifies #GP is not caused by setting the bits on
> either AMD or Intel chips.  "Stray" bits can get turned on in some cases
> when switching between 64-bit, PAE and non-PAE address modes.
> 
> Were you testing on a 64-bit host kernel?

64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing
anything 64-bit AFAIK.


> 
> Zach

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Avi Kivity]

Ryan Harper wrote:
>>
>> We have a test which verifies #GP is not caused by setting the bits on
>> either AMD or Intel chips.  "Stray" bits can get turned on in some cases
>> when switching between 64-bit, PAE and non-PAE address modes.
>>
>> Were you testing on a 64-bit host kernel?
>>     
>
> 64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing
> anything 64-bit AFAIK.
>   

If the host is 64-bit, so is the guest, although the guest can choose to 
ignore the 64-bit capabilities (and 32-bit guest OSes do; but VMware 
might be doing something tricky).


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Ryan Harper]

* Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-09-19 03:58]:
> Ryan Harper wrote:
> >>
> >>We have a test which verifies #GP is not caused by setting the bits on
> >>either AMD or Intel chips.  "Stray" bits can get turned on in some cases
> >>when switching between 64-bit, PAE and non-PAE address modes.
> >>
> >>Were you testing on a 64-bit host kernel?
> >>    
> >
> >64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing
> >anything 64-bit AFAIK.
> >  
> 
> If the host is 64-bit, so is the guest, although the guest can choose to 
> ignore the 64-bit capabilities (and 32-bit guest OSes do; but VMware 
> might be doing something tricky).

Hrm.  I'm not sure I understand the distiction you are making.  I'll
give a 32-bit host a try without the patch and see if I see the same
behavior.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Anthony Liguori]

Ryan Harper wrote:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-09-19 03:58]:
>   
>> Ryan Harper wrote:
>>     
>>>> We have a test which verifies #GP is not caused by setting the bits on
>>>> either AMD or Intel chips.  "Stray" bits can get turned on in some cases
>>>> when switching between 64-bit, PAE and non-PAE address modes.
>>>>
>>>> Were you testing on a 64-bit host kernel?
>>>>    
>>>>         
>>> 64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing
>>> anything 64-bit AFAIK.
>>>  
>>>       
>> If the host is 64-bit, so is the guest, although the guest can choose to 
>> ignore the 64-bit capabilities (and 32-bit guest OSes do; but VMware 
>> might be doing something tricky).
>>     
>
> Hrm.  I'm not sure I understand the distiction you are making.  I'll
> give a 32-bit host a try without the patch and see if I see the same
> behavior.
>   

On a 64-bit host, even if the guest kernel is 32-bit the guest could 
still detect the ability to run in 64-bit mode.  The thinking is that 
VMware may be detecting 64-bit capabilities and doing something weird.  
I think that's somewhat orthogonal to this patch.  It seems like 
ignoring setting of reserved bits is the right thing to do in 32-bit 
mode.  Does anyone disagree with that?

Regards,

Anthony Liguori


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Zachary Amsden]

On Wed, 2007-09-19 at 10:08 -0500, Anthony Liguori wrote:
> Ryan Harper wrote:
> > * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-09-19 03:58]:
> >   
> >> Ryan Harper wrote:
> >>     
> >>>> We have a test which verifies #GP is not caused by setting the bits on
> >>>> either AMD or Intel chips.  "Stray" bits can get turned on in some cases
> >>>> when switching between 64-bit, PAE and non-PAE address modes.
> >>>>
> >>>> Were you testing on a 64-bit host kernel?
> >>>>    
> >>>>         
> >>> 64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing
> >>> anything 64-bit AFAIK.
> >>>  
> >>>       
> >> If the host is 64-bit, so is the guest, although the guest can choose to 
> >> ignore the 64-bit capabilities (and 32-bit guest OSes do; but VMware 
> >> might be doing something tricky).
> >>     
> >
> > Hrm.  I'm not sure I understand the distiction you are making.  I'll
> > give a 32-bit host a try without the patch and see if I see the same
> > behavior.
> >   
> 
> On a 64-bit host, even if the guest kernel is 32-bit the guest could 
> still detect the ability to run in 64-bit mode.  The thinking is that 
> VMware may be detecting 64-bit capabilities and doing something weird.  
> I think that's somewhat orthogonal to this patch.  It seems like 
> ignoring setting of reserved bits is the right thing to do in 32-bit 
> mode.  Does anyone disagree with that?

No, VMware does this in non-weird cases.  It might not actually load a
CR3 with reserved bits set (well, it might do that too in a different
version of the code), but the standard path in and out of the VMware
monitor has a couple of different ways you can effectively end up with
reserved bits set (left as an exercise to the reader).

VMware will exhibit this behavior more frequently with 64-bit host, but
a PAE / non-PAE mismatch between guest and host also causes the same
issue.

Our software tests show that AMD and Intel processors ignore these
reserved bits across the board and we've been relying on this behavior
for some time.

BTW, VMware can run 64-bit guests on a 32-bit host, all it needs is
capable hardware, so unless you mask the 64-bit support in KVM, you
could have a strange situation where the 32-bit KVM starts (or tries to
start, expecting success) running 64-bit code.  I can imagine a couple
of ways that could blow up the host if assumptions are made that 32-bit
guests will limit themselves to running 32-bit code.  So if you don't
support EFER.LM activation, you should strip the cpuid bit from
hardware.

Zach


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Avi Kivity]

Zachary Amsden wrote:
> BTW, VMware can run 64-bit guests on a 32-bit host, all it needs is
> capable hardware, so unless you mask the 64-bit support in KVM, you
> could have a strange situation where the 32-bit KVM starts (or tries to
> start, expecting success) running 64-bit code.  I can imagine a couple
> of ways that could blow up the host if assumptions are made that 32-bit
> guests will limit themselves to running 32-bit code.  So if you don't
> support EFER.LM activation, you should strip the cpuid bit from
> hardware.
>   

We do that.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Ryan Harper]

* Ryan Harper <ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> [2007-09-19 09:56]:
> * Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> [2007-09-19 03:58]:
> > Ryan Harper wrote:
> > >>
> > >>We have a test which verifies #GP is not caused by setting the bits on
> > >>either AMD or Intel chips.  "Stray" bits can get turned on in some cases
> > >>when switching between 64-bit, PAE and non-PAE address modes.
> > >>
> > >>Were you testing on a 64-bit host kernel?
> > >>    
> > >
> > >64-bit Host running 32-bit KVM Guest. VMware-server shouldn't be seeing
> > >anything 64-bit AFAIK.
> > >  
> > 
> > If the host is 64-bit, so is the guest, although the guest can choose to 
> > ignore the 64-bit capabilities (and 32-bit guest OSes do; but VMware 
> > might be doing something tricky).
> 
> Hrm.  I'm not sure I understand the distiction you are making.  I'll
> give a 32-bit host a try without the patch and see if I see the same
> behavior.

With, or without the patch, using 32-bit host, I get triple fault in the
guest.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [RFC][PATCH] ignore set_cr3 GP fault in non-pae mode

[Avi Kivity]

Ryan Harper wrote:
> Playing around with running VMware-server within a KVM guest and noticed
> that whenever we launch a VM within the guest, KVM reports a GP fault in
> set_cr3.  Removing the fault injection (raised for attempting to set
> reserved bits) for the non-pae case allows memtest to boot and run 
> within VMWare Server, running in a KVM Linux guest.
>   

Applied, thanks.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/