OSStatus type is defined as SInt32. That's signed int on __LP64__ and
signed long otherwise.
Since it is an explicit 32-bit-width type, cast to corresponsing POSIX type
and use PRId32 format specifier. This avoids a warning on ppc64.

Cc: malc <av1474@comtv.ru>
Signed-off-by: NAndreas Faerber <andreas.faerber@web.de>
Signed-off-by: Nmalc <av1474@comtv.ru>

coreaudioVoiceOut's audioDevicePropertyBufferFrameSize is defined as UInt32
and is being used by reference for AudioDevice{Get,Set}Property().
UInt32 is unsigned int on __LP64__ but unsigned long otherwise.

Cast to POSIX type and use PRIu32 format specifier to hide the details.
This avoids a warning on ppc64.

Cc: malc <av1474@comtv.ru>
Signed-off-by: NAndreas Faerber <andreas.faerber@web.de>
Signed-off-by: Nmalc <av1474@comtv.ru>

Diagnose the case where the user asked for a NIC via "-net nic"
but the board didn't instantiate that NIC (for example where the
user asked for two NICs but the board only supports one). Note
that this diagnostic doesn't apply to NICs created through -device,
because those are always instantiated.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Don't warn about the default network setup that you get if no command line
-net options are specified.  There are two cases that we would otherwise
complain about:

(1) board doesn't support a NIC but the implicit "-net nic" requested one
(2) CONFIG_SLIRP not set, so the implicit "-net nic" sets up a nic that
isn't connected to anything
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This reverts commit f68b9d67.
That attempt at diagnosing unused -net nic options failed to account
for NICs created via -device; back it out cleanly in preparation
for implementing in a different manner.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When running kvm-autotest, fputc() is often the second highest (sometimes #1)
function showing up in a profile.  This is due to fputc() locking the file
for every byte written.

Optimize by buffering a line's worth of pixels and writing that out in a
single call.
Reviewed-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Conflicts:
	hw/usb-uhci.c

There is no need to specify version on the subsection fields.
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

When iterating through the XSAVE feature enumeration CPUID leaf (0xD)
we should not stop at the first zero EAX, but instead keep scanning
since there are gaps in the enumeration (ECX=1 for instance).
This fixes the proper usage of AVX in KVM guests.
Signed-off-by: NAndre Przywara <andre.przywara@amd.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

This was obsoleted by 6792a57b.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

kvm_arch_get_supported_cpuid checks for global cpuid restrictions, it
does not require any CPUState reference. Changing its interface allows
to call it before any VCPU is initialized.

CC: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

No one references kvm_check_extension, kvm_has_vcpu_events, and
kvm_has_robust_singlestep outside KVM code.

kvm_update_guest_debug is never called, thus has no job besides
returning an error.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

No longer needed with accompanied kernel headers.

CC: Alexander Graf <agraf@suse.de>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

No longer needed with accompanied kernel headers.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

No longer needed with accompanied kernel headers. We are only left with
build dependencies that are controlled by kvm arch headers.

CC: Alexander Graf <agraf@suse.de>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Backing KVMState is alreay zero-initialized.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Required header support is now unconditionally available.

CC: Alexander Graf <agraf@suse.de>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

The kvm_para.h header is now always available.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

This helps reducing our build-time checks for feature support in the
available Linux kernel headers. And it helps users that do not have
sufficiently recent headers installed on their build machine.

Consequently, the patch removes and build-time checks for kvm and vhost
in configure, the --kerneldir switch, and KVM_CFLAGS. Kernel headers are
supposed to be provided by QEMU only.

s390 needs some extra love as it carries redefinitions from kernel
headers.

CC: Alexander Graf <agraf@suse.de>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

These kernel headers and the COPYING file were automatically imported
from current Linux git, cb0a02ecf9 (post 3.0-rc2).

Licensing:
asm-powerpc	GPLv2
asm-s390	GPLv2
asm-x86		Linux top-level license (GPLv2 with exception)
linux/kvm*:	Linux top-level license (GPLv2 with exception)
linux/vhost:	Linux top-level license (GPLv2 with exception)
linux/virtio*:	3-clause BSB

CC: Alexander Graf <agraf@suse.de>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

This helper pulls the required kernel headers for KVM and vhost into a
specified directory. The update is triggered via

    scripts/update-linux-headers.sh LINUX_PATH

and will place the output under linux-headers/linux and linux-headers/asm-*.
It also imports the COPYING to care for headers without an explicit license.

CC: Alexander Graf <agraf@suse.de>
CC: Christoph Hellwig <hch@lst.de>
CC: Peter Maydell <peter.maydell@linaro.org>
CC: Andreas Färber <andreas.faerber@web.de>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Signed-off-by: NFrediano Ziglio <freddy77@gmail.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

filed -> failed
Signed-off-by: NAlexandre Raymond <cerbere@gmail.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

This warning is new in gcc 4.6.
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

These FPU states are properly maintained by KVM but not yet by TCG. So
far we unconditionally set them to 0 in the guest which may cause
state corruptions, though not with modern guests.

To avoid breaking backward migration, use a conditional subsection that
is only written if any of the three fields is non-zero. The guest's
FNINIT clears them frequently, and cleared IA32_MISC_ENABLE MSR[2]
reduces the probability of non-zero values further so that this
subsection is not expected to restrict migration in any common scenario.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

Introduce a new emulated PCI device, specific to fully virtualized Xen
guests.  The device is necessary for PV on HVM drivers to work.
Signed-off-by: NSteven Smith <ssmith@xensource.com>
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Compared to the last version I only added a comment to the code.

- remove i440FX-xen and i440fx_write_config_xen
we don't need to intercept pci config writes to i440FX anymore;

- introduce PIIX3-xen and piix3_write_config_xen
we do need to intercept pci config write to the PCI-ISA bridge to update
the PCI link routing;

- set the number of PIIX3-xen interrupts line to 128;
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Xen can only do dirty bit tracking for one memory region, so we should
explicitly avoid trying to track anything but the vga vram region.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

If the cirrus_vga PCI BAR is unmapped than we should not only reset
map_addr but also lfb_addr, otherwise we'll keep trying to map
the old lfb_addr in map_linear_vram.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Use qemu_invalidate_entry in cpu_physical_memory_unmap.

Do not lock mapcache entries in qemu_get_ram_ptr if the address falls in
the ramblock with offset == 0. We don't need to do that because the
callers of qemu_get_ram_ptr either try to map an entire block, other
from the main ramblock, or until the end of a page to implement a single
read or write in the main ramblock.
If we don't lock mapcache entries in qemu_get_ram_ptr we don't need to
call qemu_invalidate_entry in qemu_put_ram_ptr anymore because we can
leave with few long lived block mappings requested by devices.

Also move the call to qemu_ram_addr_from_mapcache at the beginning of
qemu_ram_addr_from_host.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Introduce qemu_ram_ptr_length that takes an address and a size as
parameters rather than just an address.

Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
once rather than calling qemu_get_ram_ptr one time per page.
This is not only more efficient but also tries to simplify the logic of
the function.
Currently we are relying on the fact that all the pages are mapped
contiguously in qemu's address space: we have a check to make sure that
the virtual address returned by qemu_get_ram_ptr from the second call on
is consecutive. Now we are making this more explicit replacing all the
calls to qemu_get_ram_ptr with a single call to qemu_ram_ptr_length
passing a size argument.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: agraf@suse.de
CC: anthony@codemonkey.ws
Signed-off-by: NAlexander Graf <agraf@suse.de>

Replace xen_map_block with qemu_map_cache with the appropriate locking
and size parameters.
Replace xen_unmap_block with qemu_invalidate_entry.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

There is no need for qemu_map_cache_unlock, just use
qemu_invalidate_entry instead.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Fix the implementation of qemu_map_cache: correctly support size
arguments different from 0 or MCACHE_BUCKET_SIZE.
The new implementation supports locked mapcache entries with size
multiple of MCACHE_BUCKET_SIZE. qemu_invalidate_entry can correctly
find and unmap these "large" mapcache entries given that the virtual
address passed to qemu_invalidate_entry is the same returned by
qemu_map_cache when the locked mapcache entry was created.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This patch introduces phys memory client for Xen.

Only sync dirty_bitmap and set_memory are actually implemented.
migration_log will stay empty for the moment.

Xen can only log one range for bit change, so only the range in the
first call will be synced.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This function will be used to support sync dirty bitmap.

This come with a check against every Xen release, and special
implementation for Xen version that doesn't have this specific call.

This function will not be usable with Xen 3.3 because the behavior is
different.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

In case we load the vmstate during incoming migration, we start from a
clean, default machine state as we went through system reset before. But
if we load from a snapshot, the machine can be in any state. That can
cause troubles if loading an older image which does not carry all state
information the executing QEMU requires. Hardly any device takes care of
this scenario.

However, fixing this is trivial. We just need to issue a system reset
during loadvm as well.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>