virtio-net: remove function calls from assert

peer_{de,at}tach were called from inside assert().
We don't support building without NDEBUG but it's not tidy.
Rearrange to attach peer outside assert calls.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
memory_region_present: return false if address is not found in child MemoryRegion

Windows XP shows COM2 port as non functional in
"Device Manager" although no COM2 port backing device
is present in QEMU.

This regression is really due to
3bb28b7208b349e7a1b326e3c6ef9efac1d462bf?
    memory: Provide separate handling of unassigned io ports accesses

That is caused by the fact that QEMU reports to
OSPM that device is present by setting 5th bit in
PII4XPM.pci_conf[0x67] register when COM2 doesn't
exist.

It happens due to memory_region_present(io_as, 0x2f8)
returning false positive since 0x2f8 address eventually
translates into catchall io_as address space.

Fix memory_region_present(parent, addr) by returning
true only if addr maps into a MemoryRegion within
parent (excluding parent itself), to match its
doc comment.

While at it fix copy/paste error in
memory_region_present() doc comment.

Note: this is a temporary hack: we really need better handling for
unassigned regions, we should avoid fallback regions since they are bad
for performance (breaking radix tree assumption that the data structure
is sparsely populated); for memory we need to fix this to implement PCI
master abort properly, anyway.

Cc: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
PCIE: fix regression with coldplugged multifunction device

PCIE is causing asserts each time a multifunction device is added
on command line (coldplug).

This is caused by
commit a66e657e18cd9b70e9f57ae5512c07faf2bc508f
    pci/pcie: convert PCIE hotplug to use hotplug-handler API
QEMU abort is caused by misplaced assertion, which should
be checked only when device is hotplugged.

Reference to regression report:
 http://www.mail-archive.com/qemu-devel@nongnu.org/msg216226.html

Fixes: a66e657e18cd9b70e9f57ae5512c07faf2bc508f

Reported-By: Nigel Kukard <nkukard+qemu@lbsd.net>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Rework --name to use QemuOpts

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add 'debug-threads' suboption to --name

Add flag storage to qemu-thread-* to store the namethreads flag

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add a 'name' parameter to qemu_thread_create

If enabled, set the thread name at creation (on GNU systems with
  pthread_set_np)
Fix up all the callers with a thread name

Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
MAINTAINERS: drop an out of date address

Gleb's address seems to be out of date.  Since it stayed like that for a
while now, I'm guessing he's no longer interested in getting mail.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
acpi-test: retain both asl and aml files on failure

Updated the error message while at it.

Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
acpi-test: issue errors instead of warnings when possible

If the expected (offline) acpi tables loaded correctly,
it is safe to assume the iasl installation is OK and
issue an error if the actual tables failed to load.

Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
pam: partly fix write-only mode

In write-only mode, writes are forwarded to RAM, while reads should not be
handled (ie should return 0xff).
Assume that in this mode, no read access is ever done, as they shouldn't
give any sensible result.

So, in write-only mode, alias PAM region to RAM, instead of PCI memory
(which can even be mapped to some device!)

This fixes Award BIOS, which use this mode to shadow system BIOS and video BIOS.

Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
pckbd: return 'keyboard enabled' on read input port command

Bit 7 of Input Port is the keyboard inhibit switch.
0 means keyboard inhibited, while 1 means keyboard enabled.

Incidentaly, this also fixes an error encountered while booting
an Award BIOS: "Keyboard is locked out - Unlock the key".

Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
qemu: x86: ignore ioapic polarity

Both QEMU and KVM have already accumulated a significant number of
optimizations based on the hard-coded assumption that ioapic polarity
will always use the ActiveHigh convention, where the logical and
physical states of level-triggered irq lines always match (i.e.,
active(asserted) == high == 1, inactive == low == 0). QEMU guests
are expected to follow directions given via ACPI and configure the
ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
QEMU will still use the ActiveHigh signaling convention when
interfacing with the emulated ioapic.

This patch modifies the emulated ioapic to completely ignore polarity
as set by the guest OS, enabling misbehaving guests to work alongside
those which comply with the ActiveHigh polarity specified by QEMU's
ACPI tables.

Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
loader: rename in_ram/has_mr

we put copy of ROMs in MR for migration.
but the name rom_in_ram makes one think we
load it in guest RAM.
Rename has_mr to make intent clearer.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Update OpenBIOS images

Update OpenBIOS images to SVN r1280 built from submodule.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
vnc: Fix tight_detect_smooth_image() for lossless case

VncTight member uint8_t quality is either (uint8_t)-1 for lossless or
less than 10 for lossy.

tight_detect_smooth_image() first promotes it to int, then compares
with -1.  Always unequal, so we always execute the lossy code.  Reads
beyond tight_conf[] and returns crap when quality is actually
lossless.

Compare to (uint8_t)-1 instead, like we do elsewhere.

Spotted by Coverity.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
vnc: Fix qemu crashed when vnc client disconnect suddenly

Hi,

When I use RealVNC viewer client (http://www.realvnc.com/) to connect vnc server,
the client disconnect suddenly, and I click reconnect button immediately, then the Qemu crashed.

In the function vnc_worker_thread_loop, will call vnc_async_encoding_start
to set the local vs->output buffer by global queue's buffer. Then send rectangles to
the vnc client call function vnc_send_framebuffer_update. Finally, Under normal circumstances,
call vnc_async_encoding_end to set the global queue'buffer by the local vs->output conversely.

When the vnc client disconnect, the job->vs->csock will be set to -1. And the current prcoess
logic will goto disconnected partion without call function vnc_async_encoding_end.
But, the function vnc_send_framebuffer_update will call buffer_reserve, which
maybe call g_realloc reset the local vs's buffer, meaning the global queue's buffer is modified also.
If anyone use the original global queue's buffer memory will cause corruption and then crash qemu.

This patch assure the function vnc_async_encoding_end being called
even though the vnc client disconnect suddenly.

Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
vnc: fix use-after-free in vnc_update_client_sync

Spotted by Coverity:

876     static int vnc_update_client_sync(VncState *vs, int has_dirty)
877     {

(1) Event freed_arg:    "vnc_update_client(VncState *, int)" frees "vs".  [details]
Also see events:        [deref_arg]

878         int ret = vnc_update_client(vs, has_dirty);

(2) Event deref_arg:    Calling "vnc_jobs_join(VncState *)" dereferences freed pointer "vs". [details]
Also see events:        [freed_arg]

879         vnc_jobs_join(vs);
880         return ret;
881     }

Remove vnc_update_client_sync wrapper, replace it with an additional
argument to vnc_update_client, so we can so the sync properly in
vnc_update_client (i.e. skip it in case of a client disconnect).

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
ui/vnc: introduce VNC_DIRTY_PIXELS_PER_BIT macro

Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ui/vnc: derive cmp_bytes from VNC_DIRTY_PIXELS_PER_BIT

this allows for setting VNC_DIRTY_PIXELS_PER_BIT to different
values than 16 if desired.

Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ui/vnc: optimize dirty bitmap tracking

vnc_update_client currently scans the dirty bitmap of each client
bitwise which is a very costly operation if only few bits are dirty.
vnc_refresh_server_surface does almost the same.
this patch optimizes both by utilizing the heavily optimized
function find_next_bit to find the offset of the next dirty
bit in the dirty bitmaps.

The following artifical test (just the bitmap operation part) running
vnc_update_client 65536 times on a 2560x2048 surface illustrates the
performance difference:

All bits clean - vnc_update_client_new: 0.07 secs
 vnc_update_client_old: 10.98 secs

All bits dirty - vnc_update_client_new: 11.26 secs
 vnc_update_client_old: 20.19 secs

Few bits dirty - vnc_update_client_new: 0.08 secs
 vnc_update_client_old: 10.98 secs

The case for all bits dirty is still rather slow, this
is due to the implementation of find_and_clear_dirty_height.
This will be addresses in a separate patch.

Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>