Use PCI_DEVFN() where appropriate.
The resulted stripped binary remains same
with/without thie patch.

Cc: Huacai Chen <zltjiangshi@gmail.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Removing dead code.  Above we already continued when
rom->addr + valuegreaterthan0 < addr so this condition is always false.
Signed-off-by: NJoel Schopp <jschopp@austin.ibm.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Currently virtio-serial supports a maximum of 31 ports. Specifying the
'max_ports' parameter to be > 31 on the cmd line causes badness.

Ensure we initialise virtio-serial only if max_ports is within the
supported range.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Fix the following warnings:
/src/qemu/hw/ide/core.c: In function `ide_drive_pio_post_load':
/src/qemu/hw/ide/core.c:2767: warning: comparison is always false due to limited range of data type

/src/qemu/ui/vnc-enc-tight.c: In function `tight_detect_smooth_image':
/src/qemu/ui/vnc-enc-tight.c:284: warning: comparison is always true due to limited range of data type
/src/qemu/ui/vnc-enc-tight.c:297: warning: comparison is always true due to limited range of data type
/src/qemu/ui/vnc-enc-tight.c: In function `tight_encode_indexed_rect16':
/src/qemu/ui/vnc-enc-tight.c:456: warning: comparison is always false due to limited range of data type
/src/qemu/ui/vnc-enc-tight.c: In function `tight_encode_indexed_rect32':
/src/qemu/ui/vnc-enc-tight.c:457: warning: comparison is always false due to limited range of data type
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

It reintroduces
    Revert "ide save/restore pio/atapi cmd transfer fields and io buffer"

but using subsections.  Added bonus is the addition of ide_dummy_transfer_stop
to transfer_end_table, that was missing.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This commit adds subsections for each device section.
Subsections is the way to handle information that don't need to be sent
to de destination of a migration because its values are not needed.  It is
the way to handle optional information.  Notice that only the source can
decide if the information is optional or not.  The destination needs to
understand all subsections that it receives to have a sucessful load.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This reverts commit 42ee76fe.
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This reverts commit ed487bb1.

The conflicts are due to commit 4fc8d671
that is a fix to the ide_drive_pre_save() function.  It reverts both
(and both are reinstantiated later in the series)

Conflicts:

	hw/ide/core.c
Signed-off-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Otherwise we can't migrate after we've removed a virtio block device.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

The GET EVENT STATUS NOTIFICATION is a mandatory command according
to MMC-3, even if event status notification is not supported.

This patch adds support for this command. It returns NEA ("No Event
Available") with an empty "Supported Event Classes" to show that it
doesn't event support status notification. If asychronous operation is
requested, which requires NCQ support, it returns an error according
to the specifications.

This fixes HAL support on FreeBSD and derivatives, which fill up the
logs every second with:

  acd0: FAILURE - unknown CMD (0x03) ILLEGAL REQUEST asc=0x20 ascq=0x00
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Some SW drivers dont keep track of what they've written and
depend on the HW latching write contents for later
read+modify+write sequences.
Signed-off-by: NEdgar E. Iglesias <edgar@axis.com>

Commit 36388314 moved most of the
interrupt logic to cpu-exec.c. Remove the remaining useless code
and fix software interrupts.
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
Acked-by: NEdgar E. Iglesias <edgar@axis.com>
Tested-by: NEdgar E. Iglesias <edgar@axis.com>

When hw interrupt pending bits in CP0_Cause are set, the CPU should
see the hw interrupt line as active. The CPU may or may not take the
interrupt based on internal state (global irq mask etc) but the glue
logic shouldn't care.

This fixes MIPS external hw interrupts in combination with -icount.
Signed-off-by: NEdgar E. Iglesias <edgar@axis.com>

The request completion callback of the LSI controller may start the next
request that can use the same tag as the completed one. As the latter is
still enqueued at that point, scsi_send_command will complain about the
tag reuse and cancel the completed request. That will cause a double
free later on when the completion path cleans up as well.

Fix this by dequeuing the request before invoking the callback.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

This change fixes initialization of e1000's microwire EEPROM internal
state values so that qemu's e1000 emulation works on NetBSD,
which doesn't use Intel's em driver but has its own wm driver
for the Intel i8254x Gigabit Ethernet.

Previously set_eecd() function in e1000.c clears EEPROM internal state
values on SK rising edge during CS==L, but according to FM93C06 EEPROM
(which is MicroWire compatible) data sheet, EEPROM internal status
should be cleared on CS rise edge regardless of SK input:
 "... a rising edge on this (CS) signal is required to reset the internal
  state-machine to accept a new cycle .."
and nothing should be changed during CS (chip select) is inactive.

Intel's em driver seems to explicitly raise SK output after CS is negated
in em_standby_eeprom() so many other OSes that use Intel's driver
don't have this problem even on the previous e1000.c implementation,
but I can't find any articles that say the MICROWIRE or EEPROM spec
requires such sequence, and actually hardware works fine without it
(i.e. real i82540EM has been working on NetBSD).

This fix also changes initialization to clear each state value in
struct eecd_state individually rather than using memset() against
the whole structre. The old_eecd member stores the last SK and CS
signal levels and it should be preserved even after reset of internal
EEPROM state to detect next signal edges for proper EEPROM emulation.
Signed-off-by: NIzumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Starting with qemu -M pc-0.12 -device virtio-serial

results in

-device virtio-serial: Property 'virtio-serial-pci.max_nr_ports' not found

The property name 'max_ports' is incorrectly named 'max_nr_ports'. Fix
that.

Also fix the ppc440 machine type bamboo-0.12 which has this typo.
Reported-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Use empty_slot to reserve addresses for several unimplemented devices so they won't fault.
 - BPP (parallel port), DBRI (audio), SX (pixel processor), and vsimms (framebuffer)
OBP for SS-20 either assumes these devices exist or probes without expecting faults.
Signed-off-by: NBob Breuer <breuerr@mc.net>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

We need to know ring layout to allocate log buffer.
So init rings first.

Also fixes a theoretical memory-leak-on-error.

https://bugzilla.redhat.com/show_bug.cgi?id=615228Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NGerd Hoffmann <kraxel@redhat.com>

Add support for secrc field. Reportedly needed by old RHEL guests.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

We do range check for size, and get size as buffer,
but copy size + 4 bytes (4 is for FCS).
Let's copy size bytes but put size + 4 in length.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This mistake makes PCI devices can't work correctly.
Signed-off-by: NHuacai Chen <zltjiangshi@gmail.com>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

Disks without media make no sense.  For SCSI, a Linux guest kernel
complains during boot.  I didn't try other combinations.

scsi-generic doesn't need the additional check, because it already
requires bdrv_is_sg(), which fails without media.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Move the check from virtio_blk_init_pci(), where it protects only
virtio-blk-pci, to virtio_blk_init().  Without that, virtio-blk-s390
initializes without a drive.  I figure that can lead to null pointer
dereferences.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

It can't actually fail now, but the next commit will change that.

s390_virtio_blk_init() already checks for failure, but
virtio_blk_init_pci() doesn't.  Fix that.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

In addition to the previous fix for calling do_flush_queued_data() only
when the virtqueue is ready, ensure do_flush_queued_data() gets a vq
that's suitably initialised.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

If a virtio-serial port is removed before the guest comes up and
initialises the virtqueues, qemu exits with the message

Guest moved used index from 0 to 61440

This happens because we try to clear any pending buffers from the
virtqueue.

Ensure the virtqueue is initialised before calling any virtqueue
operations.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

While running in debug mode if 9P server is unable to open the log file
it results in a SEGV deep down in glibc:

Program received signal SIGSEGV, Segmentation fault.
0x008fca8c in fwrite () from /lib/libc.so.6
(gdb) bt
#0  0x008fca8c in fwrite () from /lib/libc.so.6
#1  0x081eb87e in pprint_pdu (pdu=0x89a52e1c)
    at /data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio-9p-debug.c:380
#2  0x0806dad8 in submit_pdu (s=0x897dc008, pdu=0x89a52e1c)
    at /data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio-9p.c:3092
#3  0x0806dc63 in handle_9p_output (vdev=0x897dc008, vq=0x86d8218)
    at /data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio-9p.c:3122
#4  0x081ac728 in virtio_queue_notify (vdev=0x897dc008, n=0)
    at /data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio.c:563
#5  0x08063876 in virtio_ioport_write (opaque=0x86d7b98, addr=16, val=0)
    at /data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio-pci.c:222
#6  0x08063e26 in virtio_pci_config_writew (opaque=0x86d7b98, addr=16, val=0)
    at /data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio-pci.c:357
#7  0x080c881a in ioport_write (index=1, address=49296, data=0) at ioport.c:80
#8  0x080c8d4c in cpu_outw (addr=49296, val=0) at ioport.c:204
#9  0x08073010 in kvm_handle_io (port=49296, data=0xab393000, direction=1, size=2, count=1)
    at /data/sripathi/code/qemu/new/qemu-next-upstream/kvm-all.c:735
...
...

This is ugly and misleading. The following patch adds a BUG_ON to catch this
error. With this patch we get an abort message like the following, which makes
it easier to analyze:

f12-kvm login: qemu: /data/sripathi/code/qemu/new/qemu-next-upstream/hw/virtio-9p-debug.c:353: pprint_pdu: Assertion `!(!llogfile)' failed.
Signed-off-by: NSripathi Kodi <sripathik@in.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

No need to call cpu_register_physical_memory() for a zero sized area.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The file, vt82c686.c, was added after the change set of
b80d4a98 and
fecb93c4
are created, but before the patch series was commit.
So similar fix is needed to vt82c686.c.

Cc: Huacai Chen <zltjiangshi@gmail.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

bridge config write should trigger updates
on the secondary bus. never on the primary bus.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

We were requesting too much when checking buffer
length: size already includes host header length.

Further, we should not exit if we get a packet that
is too long, since this might not be under control
of the guest. Just drop the packet.

Red Hat bz 591494
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

make pci hotplug callback return value to caller.
And when returning error, allocated resources are freed.
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Make init value for this register match the spec.
BAR address is 0 at init, so enabling it
only works by chance.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Make rtl8139 spec compliant, fixing reset values
for command register.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

pcnet enables memory/io on init, which
does not make sense as BAR values are wrong.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Tested-by: NJan Kiszka <jan.kiszka@siemens.com>

Clear interrupt disable bit on reset, according to PCI spec.
Fix pci_device_reset() with 64bit BAR.
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Intel Macs have a chip called the "AppleSMC" which they use to control
certain Apple specific parts of the hardware, like the keyboard background
light.

That chip is also used to store a key that Mac OS X uses to decrypt binaries.

This patch adds emulation for that chip, so we're getting one step further
to having Mac OS X run natively on Qemu.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Set PCI multi-function bit according to multifunction property.
PCI address, devfn ,is exported to users as addr property,
so users can populate pci function(PCIDevice in qemu)
at arbitrary devfn.
It means each function(PCIDevice) don't know whether pci device
(PCIDevice[8]) is multi function or not.
So this patch allows user to set multifunction bit via property
and checks whether multifunction bit is set correctly.

Cc:  Juan Quintela <quintela@redhat.com>
Signed-off-by: NIsaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>