handle_cpu_signal is very nearly copy-paste code for each target, with a
few minor variations. This patch sets up appropriate defaults for a
generic handle_cpu_signal and provides overrides for particular targets
that did things differently. Fixing things like the persistent (XXX:
use sigsetjmp) should now become somewhat easier.
Previous comments on this patch suggest that the "activate soft MMU for
this block" comments refer to defunct functionality. I have removed
such blocks for the appropriate targets in this patch.
Signed-off-by: Nathan Froyd <froydnj@codesourcery.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
While reading Chris's code for fd migration I noticed the duplication
between QEMUFilePopen and QEMUFileStdio. This fixes it, and makes
qemu_fopen more similar qemu_popen.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
kqemu introduces a number of restrictions on the i386 target. The worst is that
it prevents large memory from working in the default build.
Furthermore, kqemu is fundamentally flawed in a number of ways. It relies on
the TSC as a time source which will not be reliable on a multiple processor
system in userspace. Since most modern processors are multicore, this severely
limits the utility of kqemu.
kvm is a viable alternative for people looking to accelerate qemu and has the
benefit of being supported by the upstream Linux kernel. If someone can
implement work arounds to remove the restrictions introduced by kqemu, I'm
happy to avoid and/or revert this patch.
N.B. kqemu will still function in the 0.11 series but this patch removes it from
the 0.12 series.
Paul, please Ack or Nack this patch.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Implement migration via unix sockets. While you can fake this using
exec and netcat, this involves forking another process and is
generally not very nice. By doing this directly in qemu, we can avoid
the copy through the external nc command. This is useful for
implementations (such as libvirt) that want to do "secure" migration;
we pipe the data on the sending side into the unix socket, libvirt
picks it up, encrypts it, and transports it, and then on the remote
side libvirt decrypts it, dumps it to another unix socket, and
feeds it into qemu.
The implementation is straightforward and looks very similar to
migration-exec.c and migration-tcp.c
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Instead of calling the IOAPIC from the PIC, raise IOAPIC irqs via the ISA bus.
As a side effect, IOAPIC lines 16-23 are enabled.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
A PC has its motherboard IRQ lines connected to both the PIC and IOAPIC.
Currently, qemu routes IRQs to the PIC which then calls the IOAPIC, an
incestuous arrangement. In order to clean this up, create a new ISA IRQ
abstraction, and have devices raise ISA IRQs (which in turn raise the i8259
IRQs as usual).
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
- still works if the build dir is not the src dir
- use find instead of *.c block/*.c etc...
Signed-off-by: Alexandre Bique <alexandre.bique@citrix.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Hi,
After discussing the issue with Avi, Gleb and a couple others on irq,
we came to the conclusion that it is preferred to have QEMU request
features from the BIOS, rather than notifying the BIOS that it is
running on QEMU or KVM. This way memory ranges can change etc. and
an older BIOS will continue to work on newer QEMU if it receives the
info as a fw_cfg value.
This one also matches what qemu-kvm does for irq0override, except I
haven't made it configurable. I leave that as an exercise for whoever
would be interested in switching off irq0override.
Thanks,
Jes
Set irq0 override in fw_cfg, informing the BIOS that QEMU expects
override on irq0. This matches qemu-kvm, and will help sharing a
single BIOS binary.
Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
For the lulz I implemented basic SMART functionality in ide.c. smartctl
on linux recognizes it just fine and starting self tests with it
complete successfully.
Signed-off-by: Brian Wheeler <bdwheele@indiana.edu>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The error message for an unknown network device given to
monitor command set_link looks better with a terminating
linefeed.
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When trying to do detached migration with exec, I found that
the monitor wouldn't always return in a timely manner. I
tracked this down to exec_start_outgoing_migration. It
appeared we were setting the fd to NONBLOCK'ing, but in
point of fact we weren't.
This bugfix should also go onto the stable 0.10 branch
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If the user does not want autostart, they can specify -S.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Hi all,
currently the vga screen_dump code doesn't use the DisplayState
interface properly and tries to replace it temporarily while taking the
screenshot.
A better approach is to register a DisplayChangeListener, call
vga_hw_update, and finally write the ppm in the next call from dpy_update.
Testing is appreciated.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu-system-arm (0.10.5) segfaults when invoked with a PXA machine target,
e.g. -M tosa. The reason is fairly obvious:
Signed-off-by: Torsten Duwe <duwe@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrzej Zaborowski <balrogg@gmail.com>
Hello,
currently when a 32 bpp cursor gets defined the result is all-black in
the areas that are not transparent (you'll get a 32 bpp cursor if you
use my previous patch to allow vmware_vga to use a 32 bpp framebuffer).
This is because the switch in sdl.c lacks a 32 bpp case.
The thing I am unsure about though is which byte is the unused one and
should be skipped, the first or the last - for the black-and-white
cursors I tested it doesn't make a difference...
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Andrzej Zaborowski <balrogg@gmail.com>
Hello,
for what I can tell, there is no way for vmware_vga to work correctly
right now. It assumes that the framebuffer bits-per-pixel and the one
from the DisplaySurface are identical (it uses directly the VRAM from
vga.c), but it always assumes 3 bytes per pixel, which is never possible
with the current version of DisplaySurface.
Attached patch fixes that by using ds_get_bits_per_pixel.
This change allows to define helpers returning pointers.
This looks like a typo in original commit.
Signed-off-by: igor.v.kovalenko@gmail.com
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
this patch handles all possible constants for immediate operand of ALU ops.
I'm not very satisfied by the implementation.
Laurent
Signed-off-by: Laurent Desnogues <laurent.desnogues@gmail.com>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
Searching for "inspiration" to convert another device to qdev, I got
ac97. Once I understood a bit of qdev, found that ac97 used a not needed
indirection. To protect the unaware, just fixed it.
Later, Juan.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: malc <av1474@comtv.ru>
Rely on the subpage system instead of the local version.
Make most functions "static".
Fix wrong parameter passed to ppc4xx_pob_reset.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Nathan Froyd