path: root/target-s390x
AgeCommit message (Collapse)AuthorFilesLines
2010-05-11Do not stop VM if emulation failed in userspace.Gleb Natapov1-0/+5
Continue vcpu execution in case emulation failure happened while vcpu was in userspace. In this case #UD will be injected into the guest allowing guest OS to kill offending process and continue. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-05-11kvm: enable smp > 1Marcelo Tosatti1-0/+5
Process INIT/SIPI requests and enable -smp > 1. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com>
2010-04-01S390: Add stub for cpu_get_phys_page_debugAlexander Graf1-0/+5
We don't implement any virtual memory in the S390 target so far, so let's add a stub for this now mandatory function. Fixes building of S390 target. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2010-03-17Large page TLB flushPaul Brook1-4/+5
QEMU uses a fixed page size for the CPU TLB. If the guest uses large pages then we effectively split these into multiple smaller pages, and populate the corresponding TLB entries on demand. When the guest invalidates the TLB by virtual address we must invalidate all entries covered by the large page. However the address used to invalidate the entry may not be present in the QEMU TLB, so we do not know which regions to clear. Implementing a full vaiable size TLB is hard and slow, so just keep a simple address/mask pair to record which addresses may have been mapped by large pages. If the guest invalidates this region then flush the whole TLB. Signed-off-by: Paul Brook <paul@codesourcery.com>
2010-03-12Remove cpu_get_phys_page_debug from userspace emulationPaul Brook1-5/+0
cpu_get_phys_page_debug makes no sense for userspace emulation, so remove it. Signed-off-by: Paul Brook <paul@codesourcery.com>
2010-03-12Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.Richard Henderson1-0/+5
Removes a set of ifdefs from exec.c. Introduce TARGET_VIRT_ADDR_SPACE_BITS for all targets other than Alpha. This will be used for page_find_alloc, which is supposed to be using virtual addresses in the first place. Signed-off-by: Richard Henderson <rth@twiddle.net>
2010-03-07Update to a hopefully more future proof FSF addressBlue Swirl5-10/+5
See also 8167ee883931cb20c6264fc19d040ce2dc6ceaaa, 530e7615ce3c01882e582c84dc6304ab98a3d5c5 and fad6cb1a565bb73f83fc0e2654489457b489e436. Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2010-03-04KVM: Rework VCPU state writeback APIJan Kiszka1-2/+1
This grand cleanup drops all reset and vmsave/load related synchronization points in favor of four(!) generic hooks: - cpu_synchronize_all_states in qemu_savevm_state_complete (initial sync from kernel before vmsave) - cpu_synchronize_all_post_init in qemu_loadvm_state (writeback after vmload) - cpu_synchronize_all_post_init in main after machine init - cpu_synchronize_all_post_reset in qemu_system_reset (writeback after system reset) These writeback points + the existing one of VCPU exec after cpu_synchronize_state map on three levels of writeback: - KVM_PUT_RUNTIME_STATE (during runtime, other VCPUs continue to run) - KVM_PUT_RESET_STATE (on synchronous system reset, all VCPUs stopped) - KVM_PUT_FULL_STATE (on init or vmload, all VCPUs stopped as well) This level is passed to the arch-specific VCPU state writing function that will decide which concrete substates need to be written. That way, no writer of load, save or reset functions that interact with in-kernel KVM states will ever have to worry about synchronization again. That also means that a lot of reasons for races, segfaults and deadlocks are eliminated. cpu_synchronize_state remains untouched, just as Anthony suggested. We continue to need it before reading or writing of VCPU states that are also tracked by in-kernel KVM subsystems. Consequently, this patch removes many cpu_synchronize_state calls that are now redundant, just like remaining explicit register syncs. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2010-02-14Fix incorrect exception_index useBlue Swirl1-2/+2
env->exception_index should be cleared with -1, not 0. See also 821b19fe923ac49a24cdb4af902584fdd019cee6. Spotted by Igor Kovalenko. Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2010-01-19kill regs_to_env and env_to_regsPaolo Bonzini1-8/+0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-12-18target-s390: Fail on unknown instructionsAlexander Graf1-1/+1
We were being a bit too nice and didn't give the guest an invalid instruction interrupt. While that works, it's not exactly the fastest thing to do, since now the guest doesn't know that we're not really implementing that instruction, so it continues doing it. We run into this with the set_page_unstable hint instruction. So let's bail out in these cases. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2009-12-05Add support for S390x system emulationAlexander Graf4-2/+208
Let's enable the basics for system emulation so we can run virtual machines with KVM! Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2009-12-05Add KVM support for S390xAlexander Graf1-0/+483
S390x was one of the first platforms that received support for KVM back in the day. Unfortunately until now there hasn't been a qemu implementation that would enable users to actually run guests. So let's include support for KVM S390x in qemu! Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2009-12-05S/390 CPU fake emulationAlexander Graf5-0/+372
Because Qemu currently requires a TCG target to exist and there are quite some useful helpers here to lay the groundwork for out KVM target, let's create a stub TCG emulation target for S390X CPUs. This is required to make tcg happy. The emulation target itself won't work though. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>