- Jan 10, 2013
-
-
Cornelia Huck authored
Dynamically allocate any data structures like ccw used when doing channel I/O. Otherwise, we'd need to add extra serialization for the different callbacks using the same data structures. Reported-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Avi Kivity authored
Opcodes: TEST CMP ADD ADC SUB SBB XOR OR AND Acked-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Avi Kivity <avi.kivity@gmail.com> Signed-off-by:
-
Avi Kivity authored
Acked-by:
-
Avi Kivity authored
Acked-by:
-
Avi Kivity authored
Acked-by:
-
Avi Kivity authored
Instead of disabling writeback via OP_NONE, just specify NoWrite. Acked-by:
-
Avi Kivity authored
Acked-by:
-
Avi Kivity authored
We emulate arithmetic opcodes by executing a "similar" (same operation, different operands) on the cpu. This ensures accurate emulation, esp. wrt. eflags. However, the prologue and epilogue around the opcode is fairly long, consisting of a switch (for the operand size) and code to load and save the operands. This is repeated for every opcode. This patch introduces an alternative way to emulate arithmetic opcodes. Instead of the above, we have four (three on i386) functions consisting of just the opcode and a ret; one for each operand size. For example: .align 8 em_notb: not %al ret .align 8 em_notw: not %ax ret .align 8 em_notl: not %eax ret .align 8 em_notq: not %rax ret The prologue and epilogue are shared across all opcodes. Note the functions use a special calling convention; notably eflags is an input/output parameter and is not clobbered. Rather than dispatching the four functions through a jump table, the functions are declared as a constant size (8) so their address can be calculated. Acked-by:
-
- Jan 09, 2013
-
-
Marcelo Tosatti authored
CPL is always 0 when in real mode, and always 3 when virtual 8086 mode. Using values other than those can cause failures on operations that check CPL. Reviewed-by:
-
Gleb Natapov authored
Fix compilation warning. Signed-off-by:
-
- Jan 08, 2013
-
-
Gleb Natapov authored
MMU code tries to avoid if()s HW is not able to predict reliably by using bitwise operation to streamline code execution, but in case of a dirty bit folding this gives us nothing since write_fault is checked right before the folding code. Lets just piggyback onto the if() to make code more clear. Signed-off-by:
-
Gleb Natapov authored
trace_kvm_mmu_delay_free_pages() is no longer used. Signed-off-by:
-
Cornelia Huck authored
Add a new capability, KVM_CAP_S390_CSS_SUPPORT, which will pass intercepts for channel I/O instructions to userspace. Only I/O instructions interacting with I/O interrupts need to be handled in-kernel: - TEST PENDING INTERRUPTION (tpi) dequeues and stores pending interrupts entirely in-kernel. - TEST SUBCHANNEL (tsch) dequeues pending interrupts in-kernel and exits via KVM_EXIT_S390_TSCH to userspace for subchannel- related processing. Reviewed-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Cornelia Huck authored
Make s390 support KVM_ENABLE_CAP. Reviewed-by:
-
Cornelia Huck authored
Explicitely catch all channel I/O related instructions intercepts in the kernel and set condition code 3 for them. This paves the way for properly handling these instructions later on. Note: This is not architecture compliant (the previous code wasn't either) since setting cc 3 is not the correct thing to do for some of these instructions. For Linux guests, however, it still has the intended effect of stopping css probing. Reviewed-by:
-
Cornelia Huck authored
Add support for injecting machine checks (only repressible conditions for now). This is a bit more involved than I/O interrupts, for these reasons: - Machine checks come in both floating and cpu varieties. - We don't have a bit for machine checks enabling, but have to use a roundabout approach with trapping PSW changing instructions and watching for opened machine checks. Reviewed-by:
-
Cornelia Huck authored
Add support for handling I/O interrupts (standard, subchannel-related ones and rudimentary adapter interrupts). The subchannel-identifying parameters are encoded into the interrupt type. I/O interrupts are floating, so they can't be injected on a specific vcpu. Reviewed-by:
-
Cornelia Huck authored
Introduce helper functions for decoding the various base/displacement instruction formats. Reviewed-by:
-
Cornelia Huck authored
These tables are never modified. Reviewed-by:
-
- Jan 03, 2013
-
-
Gleb Natapov authored
With emulate_invalid_guest_state=0 if a vcpu is in real mode VMX can enter the vcpu with smaller segment limit than guest configured. If the guest tries to access pass this limit it will get #GP at which point instruction will be emulated with correct segment limit applied. If during the emulation IO is detected it is not handled correctly. Vcpu thread should exit to userspace to serve the IO, but it returns to the guest instead. Since emulation is not completed till userspace completes the IO the faulty instruction is re-executed ad infinitum. The patch fixes that by exiting to userspace if IO happens during instruction emulation. Reported-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Gleb Natapov authored
Segment registers will be fixed according to current emulation policy during switching to real mode for the first time. Signed-off-by:
-
Gleb Natapov authored
Currently when emulation of invalid guest state is enable (emulate_invalid_guest_state=1) segment registers are still fixed for entry to vm86 mode some times. Segment register fixing is avoided in enter_rmode(), but vmx_set_segment() still does it unconditionally. The patch fixes it. Signed-off-by:
-
Gleb Natapov authored
Currently it allows entering vm86 mode if segment limit is greater than 0xffff and db bit is set. Both of those can cause incorrect execution of instruction by cpu since in vm86 mode limit will be set to 0xffff and db will be forced to 0. Signed-off-by:
-
Gleb Natapov authored
Signed-off-by:
-
Gleb Natapov authored
According to Intel SDM Vol3 Section 5.5 "Privilege Levels" and 5.6 "Privilege Level Checking When Accessing Data Segments" RPL checking is done during loading of a segment selector, not during data access. We already do checking during segment selector loading, so drop the check during data access. Checking RPL during data access triggers #GP if after transition from real mode to protected mode RPL bits in a segment selector are set. Signed-off-by:
-
Jesse Larrew authored
Correct a typo in the comment explaining hypercalls. Signed-off-by:
Jesse Larrew <jlarrew@linux.vnet.ibm.com> Signed-off-by:
-
- Dec 24, 2012
-
-
Gleb Natapov authored
Move repetitive code sequence to a separate function. Reviewed-by:
-
- Dec 23, 2012
-
-
Gleb Natapov authored
Reviewed-by:
-
Gleb Natapov authored
Move all vm86_active logic into one place. Reviewed-by:
-
Gleb Natapov authored
Segment descriptor's base is fixed by call to fix_rmode_seg(). Not need to do it twice. Reviewed-by:
-
Gleb Natapov authored
The code for SS and CS does the same thing fix_rmode_seg() is doing. Use it instead of hand crafted code. Reviewed-by:
-
Gleb Natapov authored
VMX without unrestricted mode cannot virtualize real mode, so if emulate_invalid_guest_state=0 kvm uses vm86 mode to approximate it. Sometimes, when guest moves from protected mode to real mode, it leaves segment descriptors in a state not suitable for use by vm86 mode virtualization, so we keep shadow copy of segment descriptors for internal use and load fake register to VMCS for guest entry to succeed. Till now we kept shadow for all segments except SS and CS (for SS and CS we returned parameters directly from VMCS), but since commit a5625189 emulator enforces segment limits in real mode. This causes #GP during move from protected mode to real mode when emulator fetches first instruction after moving to real mode since it uses incorrect CS base and limit to linearize the %rip. Fix by keeping shadow for SS and CS too. Reviewed-by:
-
Gleb Natapov authored
rmode_segment_valid() checks if segment descriptor can be used to enter vm86 mode. VMX spec mandates that in vm86 mode CS register will be of type data, not code. Lets allow guest entry with vm86 mode if the only problem with CS register is incorrect type. Otherwise entire real mode will be emulated. Reviewed-by:
-
Gleb Natapov authored
Set segment fields explicitly instead of using binary operations. No behaviour changes. Reviewed-by:
-
Alex Williamson authored
Previous patch "kvm: Minor memory slot optimization" (b7f69c55 ) overlooked the generation field of the memory slots. Re-using the original memory slots left us with with two slightly different memory slots with the same generation. To fix this, make update_memslots() take a new parameter to specify the last generation. This also makes generation management more explicit to avoid such problems in the future. Reported-by:
Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp> Signed-off-by:
-
Yang Zhang authored
This hack is wrong. The pin number of PIT is connected to 2 not 0. This means this hack never takes effect. So it is ok to remove it. Signed-off-by:
Yang Zhang <yang.z.zhang@Intel.com> Signed-off-by:
-
- Dec 18, 2012
-
-
Cornelia Huck authored
Add a driver for kvm guests that matches virtual ccw devices provided by the host as virtio bridge devices. These virtio-ccw devices use a special set of channel commands in order to perform virtio functions. Reviewed-by:
-
Cornelia Huck authored
Get the definition of struct subchannel_id. Reviewed-by:
-
Cornelia Huck authored
Running under a kvm host does not necessarily imply the presence of a page mapped above the main memory with the virtio information; however, the code includes a hard coded access to that page. Instead, check for the presence of the page and exit gracefully before we hit an addressing exception if it does not exist. Reviewed-by:
-
Nickolai Zeldovich authored
The kvm i8254 emulation for counter 0 (but not for counters 1 and 2) has at least two bugs in mode 0: 1. The OUT bit, computed by pit_get_out(), is never set high. 2. The counter value, computed by pit_get_count(), wraps back around to the initial counter value, rather than wrapping back to 0xFFFF (which is the behavior described in the comment in __kpit_elapsed, the behavior implemented by qemu, and the behavior observed on AMD hardware). The bug stems from __kpit_elapsed computing the elapsed time mod the initial counter value (stored as nanoseconds in ps->period). This is both unnecessary (none of the callers of kpit_elapsed expect the value to be at most the initial counter value) and incorrect (it causes pit_get_count to appear to wrap around to the initial counter value rather than 0xFFFF). Removing this mod from __kpit_elapsed fixes both of the above bugs. Signed-off-by:
Nickolai Zeldovich <nickolai@csail.mit.edu> Reviewed-by:
-
