Re: [kvm-unit-tests RFC PATCH 02/16] arm/arm64: psci: Don't run C code without stack or vectors
On Mon, Sep 02, 2019 at 03:55:48PM +0100, Alexandru Elisei wrote: > On 8/28/19 4:14 PM, Alexandru Elisei wrote: > > > On 8/28/19 3:45 PM, Andrew Jones wrote: > >> On Wed, Aug 28, 2019 at 02:38:17PM +0100, Alexandru Elisei wrote: > >>> The psci test performs a series of CPU_ON/CPU_OFF cycles for CPU 1. This > >>> is > >>> done by setting the entry point for the CPU_ON call to the physical > >>> address > >>> of the C function cpu_psci_cpu_die. > >>> > >>> The compiler is well within its rights to use the stack when generating > >>> code for cpu_psci_cpu_die. However, because no stack initialization has > >>> been done, the stack pointer is zero, as set by KVM when creating the > >>> VCPU. > >>> This causes a data abort without a change in exception level. The VBAR_EL1 > >>> register is also zero (the KVM reset value for VBAR_EL1), the MMU is off, > >>> and we end up trying to fetch instructions from address 0x200. > >>> > >>> At this point, a stage 2 instruction abort is generated which is taken to > >>> KVM. KVM interprets this as an instruction fetch from an I/O region, and > >>> injects a prefetch abort into the guest. Prefetch abort is a synchronous > >>> exception, and on guest return the VCPU PC will be set to VBAR_EL1 + > >>> 0x200, > >>> which is... 0x200. The VCPU ends up in an infinite loop causing a > >>> prefetch > >>> abort while fetching the instruction to service the said abort. > >>> > >>> cpu_psci_cpu_die is basically a wrapper over the HVC instruction, so > >>> provide an assembly implementation for the function which will serve as > >>> the > >>> entry point for CPU_ON. > >>> > >>> Signed-off-by: Alexandru Elisei > >>> --- > >>> arm/cstart.S | 7 +++ > >>> arm/cstart64.S | 7 +++ > >>> arm/psci.c | 5 +++-- > >>> 3 files changed, 17 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/arm/cstart.S b/arm/cstart.S > >>> index 114726feab82..5d4fe4b1570b 100644 > >>> --- a/arm/cstart.S > >>> +++ b/arm/cstart.S > >>> @@ -7,6 +7,7 @@ > >>> */ > >>> #define __ASSEMBLY__ > >>> #include > >>> +#include > >>> #include > >>> #include > >>> #include > >>> @@ -138,6 +139,12 @@ secondary_entry: > >>> blx r0 > >>> b do_idle > >>> > >>> +.global asm_cpu_psci_cpu_die > >>> +asm_cpu_psci_cpu_die: > >>> + ldr r0, =PSCI_0_2_FN_CPU_OFF > >>> + hvc #0 > >>> + b halt > >> Shouldn't we load PSCI_POWER_STATE_TYPE_POWER_DOWN into r1 and > >> zero out r2 and r3, as cpu_psci_cpu_die() does? And maybe we > >> should just do a 'b .' here instead of 'b halt' in order to > >> avoid confusion as to how we ended up in halt(), if the psci > >> invocation were to ever fail. > > Not really, I'm not really sure where the extra parameter in > > cpu_psci_cpu_die > > comes from. I have looked at ARM DEN 0022D, section 5.1.3, and the > > CPU_OFFcall > > has exactly one parameter, the function id. I've also looked at how KVM > > handles > > this call, and it doesn't use anything else other than the function id. > > Please > > correct me if I missed something. > > Did some digging, apparently the power state parameter was required for the > very > first version of PSCI. ARM DEN 0022D states that it has been removed in > PSCIv0.2: > > "7.3 Changes in PSCIv0.2 from first proposal > > [..] > > Removed power_state parameter for CPU_OFF." > > The kvm-unit-tests implementation of psci uses fixed function ids (as opposed > to > first psci version, where the ids were taken from the DT), so I think that we > can drop the PSCI_POWER_STATE_TYPE_POWER_DOWN parameter in cpu_psci_cpu_die > altogether. What do you think? Sounds good to me. Thanks for the digging. drew > > Thanks, > Alex > > As for zero'ing the extra registers, this is not part of the SMC calling > > convention, this is just something that the C code for psci does. The SMC > > calling convention states that registers 0-3 will be modified after the > > call, so > > having 4 arguments to the psci_invoke function will tell the compiler to > > save/restore the registers in the caller. > > > > As for doing 'b .' instead of branching to halt, that's a good idea, I'll do > > that. But it will only be useful if the last CPU_OFF call fails. > > > > Thanks, > > Alex ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [kvm-unit-tests RFC PATCH 02/16] arm/arm64: psci: Don't run C code without stack or vectors
On 8/28/19 4:14 PM, Alexandru Elisei wrote: > On 8/28/19 3:45 PM, Andrew Jones wrote: >> On Wed, Aug 28, 2019 at 02:38:17PM +0100, Alexandru Elisei wrote: >>> The psci test performs a series of CPU_ON/CPU_OFF cycles for CPU 1. This is >>> done by setting the entry point for the CPU_ON call to the physical address >>> of the C function cpu_psci_cpu_die. >>> >>> The compiler is well within its rights to use the stack when generating >>> code for cpu_psci_cpu_die. However, because no stack initialization has >>> been done, the stack pointer is zero, as set by KVM when creating the VCPU. >>> This causes a data abort without a change in exception level. The VBAR_EL1 >>> register is also zero (the KVM reset value for VBAR_EL1), the MMU is off, >>> and we end up trying to fetch instructions from address 0x200. >>> >>> At this point, a stage 2 instruction abort is generated which is taken to >>> KVM. KVM interprets this as an instruction fetch from an I/O region, and >>> injects a prefetch abort into the guest. Prefetch abort is a synchronous >>> exception, and on guest return the VCPU PC will be set to VBAR_EL1 + 0x200, >>> which is... 0x200. The VCPU ends up in an infinite loop causing a prefetch >>> abort while fetching the instruction to service the said abort. >>> >>> cpu_psci_cpu_die is basically a wrapper over the HVC instruction, so >>> provide an assembly implementation for the function which will serve as the >>> entry point for CPU_ON. >>> >>> Signed-off-by: Alexandru Elisei >>> --- >>> arm/cstart.S | 7 +++ >>> arm/cstart64.S | 7 +++ >>> arm/psci.c | 5 +++-- >>> 3 files changed, 17 insertions(+), 2 deletions(-) >>> >>> diff --git a/arm/cstart.S b/arm/cstart.S >>> index 114726feab82..5d4fe4b1570b 100644 >>> --- a/arm/cstart.S >>> +++ b/arm/cstart.S >>> @@ -7,6 +7,7 @@ >>> */ >>> #define __ASSEMBLY__ >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -138,6 +139,12 @@ secondary_entry: >>> blx r0 >>> b do_idle >>> >>> +.global asm_cpu_psci_cpu_die >>> +asm_cpu_psci_cpu_die: >>> + ldr r0, =PSCI_0_2_FN_CPU_OFF >>> + hvc #0 >>> + b halt >> Shouldn't we load PSCI_POWER_STATE_TYPE_POWER_DOWN into r1 and >> zero out r2 and r3, as cpu_psci_cpu_die() does? And maybe we >> should just do a 'b .' here instead of 'b halt' in order to >> avoid confusion as to how we ended up in halt(), if the psci >> invocation were to ever fail. > Not really, I'm not really sure where the extra parameter in cpu_psci_cpu_die > comes from. I have looked at ARM DEN 0022D, section 5.1.3, and the CPU_OFFcall > has exactly one parameter, the function id. I've also looked at how KVM > handles > this call, and it doesn't use anything else other than the function id. Please > correct me if I missed something. Did some digging, apparently the power state parameter was required for the very first version of PSCI. ARM DEN 0022D states that it has been removed in PSCIv0.2: "7.3 Changes in PSCIv0.2 from first proposal [..] Removed power_state parameter for CPU_OFF." The kvm-unit-tests implementation of psci uses fixed function ids (as opposed to first psci version, where the ids were taken from the DT), so I think that we can drop the PSCI_POWER_STATE_TYPE_POWER_DOWN parameter in cpu_psci_cpu_die altogether. What do you think? Thanks, Alex > As for zero'ing the extra registers, this is not part of the SMC calling > convention, this is just something that the C code for psci does. The SMC > calling convention states that registers 0-3 will be modified after the call, > so > having 4 arguments to the psci_invoke function will tell the compiler to > save/restore the registers in the caller. > > As for doing 'b .' instead of branching to halt, that's a good idea, I'll do > that. But it will only be useful if the last CPU_OFF call fails. > > Thanks, > Alex ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Singapore Citizen Mr. Teo En Ming's Refugee Seeking Attempts, In The Search of a Substantially Better Life
Subject: Singapore Citizen Mr. Teo En Ming's Refugee Seeking Attempts, In The Search of a Substantially Better Life In reverse chronological order: [1] Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday Photo #1: At the building of the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photo #2: Queue ticket no. 515 at the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photo #3: Submission of documents/petition to the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photos #4 and #5: Acknowledgement of Receipt (no. 03142) for the submission of documents/petition from the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019, 10:00 AM References: (a) Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday (Blogspot blog) Link: https://tdtemcerts.blogspot.sg/2019/08/petition-to-government-of-taiwan-for.html (b) Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday (Wordpress blog) Link: https://tdtemcerts.wordpress.com/2019/08/23/petition-to-the-government-of-taiwan-for-refugee-status/ [2] Application for Refugee Status at the United Nations Refugee Agency, Bangkok, Thailand, 21st March 2017 Tuesday References: (a) [YOUTUBE] Vlog: The Road to Application for Refugee Status at the United Nations High Commissioner for Refugees, Bangkok Link: https://www.youtube.com/watch?v=utpuAa1eUNI YouTube video Published on March 22nd, 2017 Views as at 31st August 2019: 593 YouTube Channel: Turritopsis Dohrnii Teo En Ming Subscribers as at 31st August 2019: 2815 Link: https://www.youtube.com/channel/UC__F2hzlqNEEGx-IXxQi3hA -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE- ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 02/10] KVM: arm/arm64: Factor out hypercall handling from PSCI code
Hi Steven, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc6 next-20190830] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Steven-Price/arm64-Stolen-time-support/20190901-185152 config: c6x-allyesconfig (attached as .config) compiler: c6x-elf-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=c6x If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from :0:0: >> include/kvm/arm_hypercalls.h:7:10: fatal error: asm/kvm_emulate.h: No such >> file or directory #include ^~~ compilation terminated. vim +7 include/kvm/arm_hypercalls.h 6 > 7 #include 8 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 01/10] KVM: arm64: Document PV-time interface
On Fri, Aug 30, 2019 at 04:25:08PM +0100, Steven Price wrote: > On 30/08/2019 15:47, Andrew Jones wrote: > > On Fri, Aug 30, 2019 at 09:42:46AM +0100, Steven Price wrote: > >> Introduce a paravirtualization interface for KVM/arm64 based on the > >> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A. > >> > >> This only adds the details about "Stolen Time" as the details of "Live > >> Physical Time" have not been fully agreed. > >> > >> User space can specify a reserved area of memory for the guest and > >> inform KVM to populate the memory with information on time that the host > >> kernel has stolen from the guest. > >> > >> A hypercall interface is provided for the guest to interrogate the > >> hypervisor's support for this interface and the location of the shared > >> memory structures. > >> > >> Signed-off-by: Steven Price > >> --- > >> Documentation/virt/kvm/arm/pvtime.txt | 64 + > >> Documentation/virt/kvm/devices/vcpu.txt | 14 ++ > >> 2 files changed, 78 insertions(+) > >> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt > >> > >> diff --git a/Documentation/virt/kvm/arm/pvtime.txt > >> b/Documentation/virt/kvm/arm/pvtime.txt > >> new file mode 100644 > >> index ..dda3f0f855b9 > >> --- /dev/null > >> +++ b/Documentation/virt/kvm/arm/pvtime.txt > >> @@ -0,0 +1,64 @@ > >> +Paravirtualized time support for arm64 > >> +== > >> + > >> +Arm specification DEN0057/A defined a standard for paravirtualised time > >> +support for AArch64 guests: > >> + > >> +https://developer.arm.com/docs/den0057/a > >> + > >> +KVM/arm64 implements the stolen time part of this specification by > >> providing > >> +some hypervisor service calls to support a paravirtualized guest > >> obtaining a > >> +view of the amount of time stolen from its execution. > >> + > >> +Two new SMCCC compatible hypercalls are defined: > >> + > >> +PV_FEATURES 0xC520 > >> +PV_TIME_ST 0xC522 > >> + > >> +These are only available in the SMC64/HVC64 calling convention as > >> +paravirtualized time is not available to 32 bit Arm guests. The existence > >> of > >> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 > >> ARCH_FEATURES > >> +mechanism before calling it. > >> + > >> +PV_FEATURES > >> +Function ID: (uint32) : 0xC520 > >> +PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST > > > > PV_TIME_LPT doesn't exist > > Thanks, will remove. > > >> +Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the > >> relevant > >> + PV-time feature is supported by the > >> hypervisor. > >> + > >> +PV_TIME_ST > >> +Function ID: (uint32) : 0xC522 > >> +Return value: (int64) : IPA of the stolen time data structure for > >> this > >> + VCPU. On failure: > >> + NOT_SUPPORTED (-1) > >> + > >> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal > >> memory > >> +with inner and outer write back caching attributes, in the inner shareable > >> +domain. A total of 16 bytes from the IPA returned are guaranteed to be > >> +meaningfully filled by the hypervisor (see structure below). > >> + > >> +PV_TIME_ST returns the structure for the calling VCPU. > >> + > >> +Stolen Time > >> +--- > >> + > >> +The structure pointed to by the PV_TIME_ST hypercall is as follows: > >> + > >> + Field | Byte Length | Byte Offset | Description > >> + --- | --- | --- | -- > >> + Revision| 4 | 0 | Must be 0 for version 0.1 > >> + Attributes | 4 | 4 | Must be 0 > > > > The above fields don't appear to be exposed to userspace in anyway. How > > will we handle migration from one KVM with one version of the structure > > to another? > > Interesting question. User space does have access to them now it is > providing the memory, but it's not exactly an easy method. In particular > user space has no (simple) way of probing the kernel's supported version. > > I guess one solution would be to add an extra attribute on the VCPU > which would provide the revision information. The current kernel would > then reject any revision other than 0, but this could then be extended > to support other revision numbers in the future. > > Although there's some logic in saying we could add the extra attribute > when(/if) there is a new version. Future kernels would then be expected > to use the current version unless user space explicitly set the new > attribute. > > Do you feel this is something that needs to be addressed now, or can it > be deferred until another version is proposed? Assuming we'll want userspace to have the option of choosing version=0, and that we're fine with version=0 being the implicit choice, when nothing is selected, then I guess it can be left as is for now. If, OTOH, we just wan
Re: [PATCH 0/3] arm64: KVM: Kiss hyp_alternate_select() goodbye
On Sun, Sep 01, 2019 at 10:12:34PM +0100, Marc Zyngier wrote: > hyp_alternate_select() is a leftover from the my second attempt at > supporting VHE (the first one was never merged, thankfully), and is > now an irrelevant relic. It was a way to patch function pointers > without having to dereference memory, a bit like static keys for > function calls. > > Lovely idea, but since Christoffer mostly separated the VHE and !VHE > hypervisor paths, most of the uses of hyp_alternate_select() are > gone. What is left is two instances that are better replaced by > already existing static keys. One of the instances becomes > cpus_have_const_cap(), and the rest is a light sprinkling of > has_vhe(). > > So off it goes. > > Marc Zyngier (3): > arm64: KVM: Drop hyp_alternate_select for checking for > ARM64_WORKAROUND_834220 > arm64: KVM: Replace hyp_alternate_select with has_vhe() > arm64: KVM: Kill hyp_alternate_select() > > arch/arm64/include/asm/kvm_hyp.h | 24 - > arch/arm64/kvm/hyp/switch.c | 17 ++- > arch/arm64/kvm/hyp/tlb.c | 36 +++- > 3 files changed, 24 insertions(+), 53 deletions(-) > > -- > 2.20.1 > Yay! The 'func()(...)' stuff always gave me cross-eyes. Reviewed-by: Andrew Jones ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 0/3] arm64: KVM: Kiss hyp_alternate_select() goodbye
On Sun, Sep 01, 2019 at 10:12:34PM +0100, Marc Zyngier wrote: > hyp_alternate_select() is a leftover from the my second attempt at > supporting VHE (the first one was never merged, thankfully), and is > now an irrelevant relic. It was a way to patch function pointers > without having to dereference memory, a bit like static keys for > function calls. > > Lovely idea, but since Christoffer mostly separated the VHE and !VHE > hypervisor paths, most of the uses of hyp_alternate_select() are > gone. What is left is two instances that are better replaced by > already existing static keys. One of the instances becomes > cpus_have_const_cap(), and the rest is a light sprinkling of > has_vhe(). > > So off it goes. I'm not sure I want to kiss hyp_alternate_select() at all, but away it must go! Reviewed-by: Christoffer Dall ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 02/10] KVM: arm/arm64: Factor out hypercall handling from PSCI code
Hi Steven,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc6 next-20190830]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Steven-Price/arm64-Stolen-time-support/20190901-185152
config: i386-randconfig-a002-201935 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
In file included from include/kvm/arm_hypercalls.h:7:0,
from :0:
>> arch/x86/include/asm/kvm_emulate.h:349:22: error: 'NR_VCPU_REGS' undeclared
>> here (not in a function)
unsigned long _regs[NR_VCPU_REGS];
^~~~
In file included from :0:0:
>> include/kvm/arm_hypercalls.h:9:33: warning: 'struct kvm_vcpu' declared
>> inside parameter list will not be visible outside of this definition or
>> declaration
int kvm_hvc_call_handler(struct kvm_vcpu *vcpu);
^~~~
include/kvm/arm_hypercalls.h:11:45: warning: 'struct kvm_vcpu' declared
inside parameter list will not be visible outside of this definition or
declaration
static inline u32 smccc_get_function(struct kvm_vcpu *vcpu)
^~~~
include/kvm/arm_hypercalls.h: In function 'smccc_get_function':
>> include/kvm/arm_hypercalls.h:13:9: error: implicit declaration of function
>> 'vcpu_get_reg' [-Werror=implicit-function-declaration]
return vcpu_get_reg(vcpu, 0);
^~~~
include/kvm/arm_hypercalls.h: At top level:
include/kvm/arm_hypercalls.h:16:51: warning: 'struct kvm_vcpu' declared
inside parameter list will not be visible outside of this definition or
declaration
static inline unsigned long smccc_get_arg1(struct kvm_vcpu *vcpu)
^~~~
include/kvm/arm_hypercalls.h:21:51: warning: 'struct kvm_vcpu' declared
inside parameter list will not be visible outside of this definition or
declaration
static inline unsigned long smccc_get_arg2(struct kvm_vcpu *vcpu)
^~~~
include/kvm/arm_hypercalls.h:26:51: warning: 'struct kvm_vcpu' declared
inside parameter list will not be visible outside of this definition or
declaration
static inline unsigned long smccc_get_arg3(struct kvm_vcpu *vcpu)
^~~~
include/kvm/arm_hypercalls.h:31:44: warning: 'struct kvm_vcpu' declared
inside parameter list will not be visible outside of this definition or
declaration
static inline void smccc_set_retval(struct kvm_vcpu *vcpu,
^~~~
include/kvm/arm_hypercalls.h: In function 'smccc_set_retval':
>> include/kvm/arm_hypercalls.h:37:2: error: implicit declaration of function
>> 'vcpu_set_reg'; did you mean 'smccc_set_retval'?
>> [-Werror=implicit-function-declaration]
vcpu_set_reg(vcpu, 0, a0);
^~~~
smccc_set_retval
cc1: some warnings being treated as errors
vim +/NR_VCPU_REGS +349 arch/x86/include/asm/kvm_emulate.h
a584539b24b87d arch/x86/include/asm/kvm_emulate.h Paolo Bonzini
2015-04-01 290
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 291 struct x86_emulate_ctxt {
0225fb509d51fc arch/x86/include/asm/kvm_emulate.h Mathias Krause
2012-08-30 292 const struct x86_emulate_ops *ops;
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 293
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 294 /* Register state before/after emulation. */
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 295 unsigned long eflags;
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 296 unsigned long eip; /* eip before instruction emulation */
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 297 /* Emulated execution mode, represented by an
X86EMUL_MODE value. */
9d1b39a967871b arch/x86/include/asm/kvm_emulate.h Gleb Natapov
2012-09-03 298 enum x86emul_mode mode;
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 299
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 300 /* interruptibility state, as a result of execution of
STI or MOV SS */
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
2011-06-01 301 int interruptibility;
9dac77fa4011bd arch/x86/include/asm/kvm_emulate.h Avi Kivity
