pit: fix pit interrupt can't inject into vm after migration

kvm_pit is running in kmod. kvm_pit is going to inject
interrupt to vm before cpu_synchronize_all_post_init at
dest side. vcpu will lose the pit interrupt, but
ack_irq(in kmod) has been 0. ack_irq become 1 after
vcpu responds pit interrupt. pit interruptcan inject
to vm when ack_irq is 1.

By the way, kvm_pit_vm_state_change has save and load
state of pit, so pre_save and post_load is unnecessary.

Signed-off-by: ChenLiang <chenliang88@huawei.com>
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Introduce cpu_clean_all_dirty

Introduce cpu_clean_all_dirty, to force subsequent cpu_synchronize_all_states
to read in-kernel register state.

Cc: qemu-stable@nongnu.org
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
kvmclock: Ensure proper env->tsc value for kvmclock_current_nsec calculation

Ensure proper env->tsc value for kvmclock_current_nsec calculation.

Reported-by: Marcin Gibuła <m.gibula@beyond.pl>
Analyzed-by: Marcin Gibuła <m.gibula@beyond.pl>
Cc: qemu-stable@nongnu.org
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
kvmclock: Ensure time in migration never goes backward

When we migrate we ask the kernel about its current belief on what the guest
time would be. However, I've seen cases where the kvmclock guest structure
indicates a time more recent than the kvm returned time.

To make sure we never go backwards, calculate what the guest would have seen as time at the point of migration and use that value instead of the kernel returned one when it's more recent.
This bases the view of the kvmclock after migration on the
same foundation in host as well as guest.

Signed-off-by: Alexander Graf <agraf@suse.de>
Cc: qemu-stable@nongnu.org
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
hw/dma/i8257: Silence phony error message

Convert into trace event. Otherwise the message
	dma: unregistered DMA channel used nchan=0 dma_pos=0 dma_len=1
gets printed every time and fills up the log-file with 50 MiB / minute.

Signed-off-by: Philipp Hahn <hahn@univention.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
target-i386: update fp status fix

This patch introduces cpu_set_fpuc() function, which changes fpuc field
of the CPU state and calls update_fp_status() function.
These calls update status of softfloat library and prevent bugs caused
by non-coherent rounding settings of the FPU and softfloat.

v2 changes:
 * Added missed calls and intoduced setter function (as suggested by TeLeMan)

Reviewed-by: TeLeMan <geleman@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
serial: reset state at startup

When a serial port is started, its initial state is all zero.  Make
it consistent with reset state instead.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
serial: check if backed by a physical serial port at realize time

Right now, s->poll_msl may linger at "0" value for an arbitrarily long
time, until serial_update_msl is called for the first time.  This is
unnecessary, and will lead to the s->poll_msl field being unnecessarily
migrated.

We can call serial_update_msl immediately at realize time (via
serial_reset) and be done with it.  The memory-mapped UART was already
doing that, but not the ISA and PCI variants.

Regarding the delta bits, be consistent with what serial_reset does when
the serial port is not backed by a physical serial port, and always clear
them at reset time.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
scsi: Optimize scsi_req_alloc

Zeroing sense buffer for each scsi request is not efficient, we can just
leave it uninitialized because sense_len is set to 0.

Move the implicitly zeroed fields to the end of the structure and use a
partial memset.

The explicitly initialized fields (by scsi_req_alloc or scsi_req_new)
are moved to the beginning of the structure, before sense buffer, to
skip the memset.

Also change g_malloc0 to g_slice_alloc.

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
virtio-scsi: Optimize virtio_scsi_init_req

The VirtQueueElement is a very big structure (>48k!), since it will be
initialzed by virtqueue_pop, we can save the expensive zeroing here.

This saves a few microseconds per request in my test:

[fio-test]      rw         bs         iodepth    jobs       bw         iops       latency
--------------------------------------------------------------------------------------------
Before          read       4k         1          1          110        28269      34
After           read       4k         1          1          131        33745      28

Whereas,

virtio-blk      read       4k         1          1          217        55673      16

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
vhost-scsi: use virtio_ldl_p

This helps for cross-endian configurations.

Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
virtio-scsi: clean up virtio_scsi_parse_cdb

The command direction according to the guest-passed buffers
is already stored in the VirtIOSCSIReq.  We can use it instead
of computing it again from req->elem.

Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
virtio-scsi: Split virtio_scsi_handle_cmd_req from virtio_scsi_handle_cmd

This is the "common part" to handle one cmd request. Refactor out for
later usage of dataplane iothread code.

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
virtio-scsi: Split virtio_scsi_handle_ctrl_req from virtio_scsi_handle_ctrl

To share with dataplane code.

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
virtio-scsi: Make virtio_scsi_init_req public

To share with datplane code later.

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
virtio-scsi: Make virtio_scsi_free_req public

To share with dataplane code later.

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
virtio-scsi: Make virtio_scsi_push_event public

Later this will be called by dataplane code.

Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
blkdebug: show an error for invalid event names

It is easy to typo a blkdebug configuration and waste a lot of time
figuring out why no rules are matching.

Push the Error** down into add_rule() so we can report an error when the
event name is invalid.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
blockdev: Disentangle BlockDriverState and DriveInfo creation

blockdev_init() mixes up BlockDriverState and DriveInfo initialization
Finish the BlockDriverState job before starting to mess with
DriveInfo.  Easier on the eyes.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Benoît Canet <benoit.canet@nodalink.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block: Keep DriveInfo alive until BlockDriverState dies

If the BDS's refcnt > 0, drive_del() destroys the DriveInfo, but not
the BDS.  This can happen in three places:

* Device model destruction during unplug: blockdev_auto_del()

* Xen IDE unplug: pci_piix3_xen_ide_unplug()

* drive_del command when no device model is attached: do_drive_del()

The other callers of drive_del are on error paths where refcnt == 1.

If the user somehow manages to plug in a device model using a BDS that
has gone through drive_del(), the legacy configuration passed in
DriveInfo doesn't reach the device model, and automatic deletion on
unplug doesn't work.  Worse, some device models such as scsi-disk
crash when DriveInfo doesn't exist.

This is theoretical; I didn't research an actual reproducer. The problem
was introduced when we replaced DriveInfo reference counting by BDS
reference counting in commit a94a3fa..fa510eb.

Fix by keeping DriveInfo alive until its BDS dies.

This affects qemu_drive_opts: now you can't reuse the same ID for new
drive options until the BDS dies.  Before, you could, but since the
code always attempts to create a BDS with the same ID next, the
enclosing operation "create a new drive" failed anyway.  Different
error path, same result.

Unfortunately, the fix involves use of blockdev.c stuff from block.c,
which is a layering violation.  Fortunately, my forthcoming
BlockBackend work will get rid of it again.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Benoît Canet <benoit.canet@nodalink.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>