If the kernel supports KVM_SIGNAL_MSI, we can avoid the route-based
MSI injection mechanism.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

This patch basically adds kvm_irqchip_send_msi, a service for sending
arbitrary MSI messages to KVM's in-kernel irqchip models.

As the original KVM API requires us to establish a static route from a
pseudo GSI to the target MSI message and inject the MSI via toggling
that virtual IRQ, we need to play some tricks to make this interface
transparent. We create those routes on demand and keep them in a hash
table. Succeeding messages can then search for an existing route in the
table first and reuse it whenever possible. If we should run out of
limited GSIs, we simply flush the table and rebuild it as messages are
sent.

This approach is rather simple and could be optimized further. However,
latest kernels contains a more efficient MSI injection interface that
will obsolete the GSI-based dynamic injection.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Instead of the bitmap size, store the maximum of GSIs the kernel
support. Move the GSI limit assertion to the API function
kvm_irqchip_add_route and make it stricter.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

If the kernel page size is larger than TARGET_PAGE_SIZE, which
happens for example on ppc64 with kernels compiled for 64K pages,
the dirty tracking doesn't work.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAvi Kivity <avi@redhat.com>

The current kvm_init_irq_routing() doesn't set up the used_gsi_bitmap
correctly, and as a consequence pins max_gsi to 32 when it really
should be 1024. I ran into this limitation while testing pci
passthrough, where I consistently got an -ENOSPC return from
kvm_get_irq_route_gsi() called from assigned_dev_update_msix_mmio().
Signed-off-by: NJason Baron <jbaron@redhat.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

This is now implied by kvm_irqchip_in_kernel.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

We use a 2 byte ioeventfd for virtio memory,
add support for this.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

In kvm-all.c we store an ioctl cmd number in the irqchip_inject_ioctl field
of KVMState, which has type 'int'.  This seems to make sense since the
ioctl() man page says that the cmd parameter has type int.

However, the kernel treats ioctl numbers as unsigned - sys_ioctl() takes an
unsigned int, and the macros which generate ioctl numbers expand to
unsigned expressions.  Furthermore, some ioctls (IOC_READ ioctls on x86
and IOC_WRITE ioctls on powerpc) have bit 31 set, and so would be negative
if interpreted as an int. This has the surprising and compile-breaking
consequence that in kvm_irqchip_set_irq() where we do:
    return (s->irqchip_inject_ioctl == KVM_IRQ_LINE) ? 1 : event.status;
We will get a "comparison is always false due to limited range of data
type" warning from gcc if KVM_IRQ_LINE is one of the bit-31-set ioctls,
which it is on powerpc.

So, despite the fact that the man page and posix say ioctl numbers are
signed, they're actually unsigned.  The kernel uses unsigned, the glibc
header uses unsigned long, and FreeBSD, NetBSD and OSX also use unsigned
long ioctl numbers in the code.

Therefore, this patch changes the variable to be unsigned, fixing the
compile.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Scripted conversion:
  for file in *.[hc] hw/*.[hc] hw/kvm/*.[hc] linux-user/*.[hc] linux-user/m68k/*.[hc] bsd-user/*.[hc] darwin-user/*.[hc] tcg/*/*.[hc] target-*/cpu.h; do
    sed -i "s/CPUState/CPUArchState/g" $file
  done

All occurrences of CPUArchState are expected to be replaced by QOM CPUState,
once all targets are QOM'ified and common fields have been extracted.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NAnthony Liguori <aliguori@us.ibm.com>

* it's -> its (fixed for all files)
* dont -> don't (only fixed in a line which was touched by the previous fix)
* distrub -> disturb (fixed in the same line)
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

valgrind warns about padding fields which are passed
to vcpu ioctls uninitialized.
This is not an error in practice because kvm ignored padding.
Since the ioctls in question are off data path and
the cost is zero anyway, initialize padding to 0
to suppress these errors.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

To be used for in-kernel PIT emulation.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

kvm_set_phys_mem() may be passed sections that are not aligned to a page
boundary.  The current code simply brute-forces the alignment which leads
to an inconsistency and an abort().

Fix by aligning the start and the end of the section correctly, discarding
and unaligned head or tail.

This was triggered by a guest sizing a 64-bit BAR that is smaller than a page
with PCI_COMMAND_MEMORY enabled and the upper dword clear.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Current memory listeners are incremental; that is, they are expected to
maintain their own state, and receive callbacks for changes to that state.

This patch adds support for stateless listeners; these work by receiving
a ->begin() callback (which tells them that new state is coming), a
sequence of ->region_add() and ->region_nop() callbacks, and then a
->commit() callback which signifies the end of the new state.  They should
ignore ->region_del() callbacks.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Ignore any regions not belonging to a specified address space.
Signed-off-by: NAvi Kivity <avi@redhat.com>

This way the accelerator (kvm) can handle them directly.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

This allows reverse iteration, which in turns allows consistent ordering
among multiple listeners:

  l1->add
  l2->add
  l2->del
  l1->del
Signed-off-by: NAvi Kivity <avi@redhat.com>
Reviewed-by: NRichard Henderson <rth@twiddle.net>

As we have thread-local cpu_single_env now and KVM uses exactly one
thread per VCPU, we can drop the cpu_single_env updates from the loop
and initialize this variable only once during setup.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAvi Kivity <avi@redhat.com>

To both avoid that kvm_irqchip_in_kernel always has to be paired with
kvm_enabled and that the former ends up in a function call, implement it
like the latter. This means keeping the state in a global variable and
defining kvm_irqchip_in_kernel as a preprocessor macro.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>

Commit 84b058d7 broke compilation for KVM on non-x86 targets, which
don't have KVM_CAP_IRQ_ROUTING defined.

Fix by not using the unavailable constant when it's not around.
Signed-off-by: NAlexander Graf <agraf@suse.de>

Instead of each target knowing or guessing the guest page size,
just pass the desired size of dirtied memory area.
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

The kvm_get_dirty_pages_log_range() function uses two address
variables to step through the monitored memory region to update the
dirty log.  However, these variables have type unsigned long, which
can overflow if running a 64-bit guest with a 32-bit qemu binary.

This patch changes these to target_phys_addr_t which will have the
correct size.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

KVM is forced to disable the IRQ0 override when we run with in-kernel
irqchip but without IRQ routing support of the kernel. Set the fwcfg
value correspondingly. This aligns us with qemu-kvm.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>

Add the basic infrastructure to active in-kernel irqchip support, inject
interrupts into these models, and maintain IRQ routes.

Routing is optional and depends on the host arch supporting
KVM_CAP_IRQ_ROUTING. When it's not available on x86, we looe the HPET as
we can't route GSI0 to IOAPIC pin 2.

In-kernel irqchip support will once be controlled by the machine
property 'kernel_irqchip', but this is not yet wired up.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>

Otherwise, the dirty log information is lost in the kernel forever.

Fixes opensuse-12.1 boot screen, which changes the vga windows rapidly.
Signed-off-by: NAvi Kivity <avi@redhat.com>

This reaches into the innards of the memory core, which are being
changed.  Switch to a memory API version.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Drop the use of cpu_register_phys_memory_client() in favour of the new
MemoryListener API.  The new API simplifies the caller, since there is no
need to deal with splitting and merging slots; however this is not exploited
in this patch.
Signed-off-by: NAvi Kivity <avi@redhat.com>

This simplifies a later switch to the memory API in slot management.
Signed-off-by: NAvi Kivity <avi@redhat.com>

It's a little unfriendly to call abort() without printing any sort of
error message. So turn the DPRINTK() into an fprintf(stderr, ...).
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>

And kvm_ioctl(s, KVM_CREATE_VM, 0)'s return value can be < -1,
so change the check of vmfd at label 'err'.
Signed-off-by: NXu He Jie <xuhj@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

mmio callbacks invoked by kvm_flush_coalesced_mmio_buffer() may
themselves indirectly call kvm_flush_coalesced_mmio_buffer().
Prevent reentering the function by checking a flag that indicates
we're processing coalesced mmio requests.
Signed-off-by: NAvi Kivity <avi@redhat.com>

Next commit will convert the query-status command to use the
RunState type as generated by the QAPI.

In order to "transparently" replace the current enum by the QAPI
one, we have to make some changes to some enum values.

As the changes are simple renames, I'll do them in one shot. The
changes are:

 - Rename the prefix from RSTATE_ to RUN_STATE_
 - RUN_STATE_SAVEVM to RUN_STATE_SAVE_VM
 - RUN_STATE_IN_MIGRATE to RUN_STATE_INMIGRATE
 - RUN_STATE_PANICKED to RUN_STATE_INTERNAL_ERROR
 - RUN_STATE_POST_MIGRATE to RUN_STATE_POSTMIGRATE
 - RUN_STATE_PRE_LAUNCH to RUN_STATE_PRELAUNCH
 - RUN_STATE_PRE_MIGRATE to RUN_STATE_PREMIGRATE
 - RUN_STATE_RESTORE to RUN_STATE_RESTORE_VM
 - RUN_STATE_PRE_MIGRATE to RUN_STATE_FINISH_MIGRATE
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Today, when notifying a VM state change with vm_state_notify(),
we pass a VMSTOP macro as the 'reason' argument. This is not ideal
because the VMSTOP macros tell why qemu stopped and not exactly
what the current VM state is.

One example to demonstrate this problem is that vm_start() calls
vm_state_notify() with reason=0, which turns out to be VMSTOP_USER.

This commit fixes that by replacing the VMSTOP macros with a proper
state type called RunState.
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Enabling the I/O thread by default seems like an important part of declaring
1.0.  Besides allowing true SMP support with KVM, the I/O thread means that the
TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
currently requires a (racey) signal based alarm system.

I know there have been concerns about performance.  I think so far the ones that
have come up (virtio-net) are most likely due to secondary reasons like
decreased batching.

I think we ought to force enabling I/O thread early in 1.0 development and
commit to resolving any lingering issues.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

qemu_malloc/qemu_free no longer exist after this commit.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

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>

On PPC, the default PAGE_SIZE is 64kb. Unfortunately, the hardware
alignments don't match here: There are RAM and MMIO regions within
a single page when it's 64kb in size.

So the only way out for now is to tell the user that he should use 4k
PAGE_SIZE.

This patch gives the user a hint on that, telling him that failing to
register a prefix slot is most likely to be caused by mismatching PAGE_SIZE.

This way it's also more future-proof, as bigger PAGE_SIZE can easily be
supported by other machines then, as long as they stick to 64kb granularities.
Signed-off-by: NAlexander Graf <agraf@suse.de>

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>