Level 15 interrupts are broadcast to all CPUs, each CPU can clear the
interrupt using the local Clear Pending register.

Update intbit_to_level table.

Don't try to raise level 0 interrupts.

Calculate pending interrupts based on the separate inputs from master
register. Setting or resetting the pending level isn't correct because of
overlap of levels.

Level 14 is always used for CPU timer interrupts, remove the property.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Conditional moves off fp condition codes were using the result of
get_fp_bit to isolate and test the relevant condition code.  However,
get_fp_bit returns the bit number of the condition code, not a
bitmask.  (Compare the use of get_fp_bit in gen_compute_branch1, for
instance.)

Fixed by shifting a bitmask into place using the result of get_fp_bit in
the relevant functions (gen_mov{ci,cf_s,cf_d,cf_ps}).
Signed-off-by: NNathan Froyd <froydnj@codesourcery.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

the encode_imm function in tcg/arm/tcg-target.c lacks shift declaration.

Laurent
Signed-off-by: NLaurent Desnogues <laurent.desnogues@gmail.com>
Signed-off-by: NAndrzej Zaborowski <andrew.zaborowski@intel.com>

The ne2k is an ancient card that performs pretty terribly under QEMU.  In many
modern OSes, there is no longer drivers available for the ne2k.

Switch the default network adapter to e1000.  This card is more widely
suppported and performs rather well under QEMU.  There may be very old OSes
that had a ne2k driver but not an e1000 driver but I think this is likely the
exception.

I think the average user is better served with an e1000 vs ne2k.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

These errors come up when compiling with gcc-4.3.3 and some older headers:

/scratch/froydnj/qemu.git/block/vpc.c: In function 'vpc_create':
/scratch/froydnj/qemu.git/block/vpc.c:514: error: value computed is not used
/scratch/froydnj/qemu.git/block/vpc.c:516: error: value computed is not used
/scratch/froydnj/qemu.git/block/vpc.c:517: error: value computed is not used
/scratch/froydnj/qemu.git/block/vpc.c:566: error: value computed is not used

Use memcpy to copy the strings instead of strncpy.
Signed-off-by: NNathan Froyd <froydnj@codesourcery.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

As requested by Anthony make pthreads mandatory.  This means we will always
have AIO available on posix hosts, and it will also allow enabling the I/O
thread unconditionally once it's ready.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

virtio-pci depends, and will always depend, on pci.c
so it makes sense to keep it in the same makefile,
(unlike the rest of virtio files which should eventually
 be moved out to Makefile.hw).
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Notify users of the char interface whenever the file / connection is
closed.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

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: NNathan Froyd <froydnj@codesourcery.com>
Signed-off-by: NAnthony 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: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

We no longer need hackery to work around kqemu
Signed-off-by: NAnthony 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: NAnthony Liguori <aliguori@us.ibm.com>

Add a configure switch to enable / disable all user targets. I felt compelled to do it for symmetry, mostly it is useful to disable user targets when you don't want to build them.
Signed-off-by: NZachary Amsden <zamsden@redhat.com>
Signed-off-by: NAnthony 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: NChris Lalancette <clalance@redhat.com>
Signed-off-by: NAnthony 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: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony 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: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony 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: NAlexandre Bique <alexandre.bique@citrix.com>
Signed-off-by: NAnthony 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: NJes Sorensen <jes@sgi.com>
Signed-off-by: NAnthony 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: NBrian Wheeler <bdwheele@indiana.edu>
Signed-off-by: NAnthony 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: NStefan Weil <weil@mail.berlios.de>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Clean up VGA type selection; far too many variables being used to track one state leads to confusion if new variables are added.
Signed-off-by: NZachary Amsden <zamsden@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When using stdio monitor and VNC display, one can set or clear a VNC password; this should set or turn off VNC authentication as well.
Signed-off-by: NZachary Amsden <zamsden@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NZachary Amsden <zamsden@redhat.com>
Signed-off-by: NAnthony 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: NChris Lalancette <clalance@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If the user does not want autostart, they can specify -S.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony 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: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: Nmalc <av1474@comtv.ru>

Signed-off-by: NJuan Quintela <quintela@redhat.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

was incorrect.

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: NTorsten Duwe <duwe@lst.de>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAndrzej 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: NReimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: NAndrzej 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.

Signed-off-by: NBenoit Canet <benoit.canet@gmail.com>
Signed-off-by: NAndrzej Zaborowski <balrogg@gmail.com>

Signed-off-by: NBenoit Canet <benoit.canet@gmail.com>
Signed-off-by: NAndrzej Zaborowski <balrogg@gmail.com>