piix_pci: fix typo in i400FX chipset init code

There is a typo in i440FX init code. This is causing problems when
somebody wants to access the 64bit PCI range.

Signed-off-by: Alexey Korolev <alexey.korolev@endace.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
pc: reduce duplication in compat machine types

Make it easier to add compat properties, by
adding macros for properties duplicated across
machine types.

Note: there could be bugs in compat properties,
this patch does not attempt to address them,
the code is bug for bug identical to the original.

Tested by: generated a preprocessed file, sorted and
compared to sorted original.
Lightly tested on x86_64.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
piix: fix up/down races

piix acpi interface suffers from the following 2 issues:

1.
- delete device a
- quickly add device b in another slot

if we do this before guest reads the down register,
the down event is discarded and device will never
be deleted.

2.
- delete device a
- quickly reset before guest can respond

interrupt is reset and guest will never eject the device.

To fix this, we implement three changes:

1. Do not clear up/down registers on each hotplug event.
this ensures we don't lose events.

2. Make existing up/down registers write 1 to clear;
bios will now write back to these the value it read.

3. on reset, remove all devices which have DOWN bit set

For compatibility with old guests, we also clear
the DOWN bit on write to EJ0 for a device.

This patch also extends the documentation for the
ACPI interface, to make the semantics explicit.

Compatibility notes: migrating guests across qemu versions
can cause bios from one qemu realease running on another qemu
release. The following documents the behaviour in this case:

A. new bios running on old qemu
A bios implementing the change mentioned above will if running on an old
qemu introduce a race: the registers were writeable there, so if a
register changes between read and write, we'll clobber the new bits
losing events.  As that version tends to lose events anyway, and as the
better than complicating the interface. If someone cares enough, the fix
can go on the stable branch.
B. old bios running on new qemu
Down bits will get cleared on eject because of 3 above.
Up bits only get cleared on reset.
This will cause unnecessary notifications and bus rescans,
but they are harmless.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
vhost: Fix size of dirty log sync on resize

When the vhost log is resized, we want to sync up to
the size of the old log.  With that end address in place,
ignore regions that start after then end rather than
hitting assert.

This also addresses the following crash report:
When migrating a vm using vhost-net we hit the following assertion:

qemu-kvm: /usr/src/packages/BUILD/qemu-kvm-0.15.1/hw/vhost.c:30:
vhost_dev_sync_region: Assertion `start / (0x1000 * (8 *
sizeof(vhost_log_chunk_t))) < dev->log_size' failed.

The cases which the end < start check is intended to catch, such as
for vga video memory, will also likely trigger the assertion.
Reorder the code to handle this correctly.

Reported-by: Josh Durgin <josh.durgin@dreamhost.com>
Signed-off-by: Bruce Rogers <brogers@suse.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
vhost: readd assert statement

It's clear from the surrounding code that
start < end so it's enough to assert end < log_size.
However, it's better to make this explicit in case
we refactor the code again.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
ivshmem: add missing msix calls

ivshmem used msix but didn't call it on either reset or
config write paths. This used to partically work since
guests don't use all of msi-x configuration fields,
and reset is rarely used, but the patch 'msix: track function masked
in pci device state' broke that. Fix by adding appropriate calls.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reported-by: Cam Macdonell <cam@cs.ualberta.ca>
Tested-by: Cam Macdonell <cam@cs.ualberta.ca>
virtio-pci: change virtio balloon PCI class code

Currently the virtio balloon device, when using the virtio-pci interface
advertises itself with PCI class code MEMORY_RAM.  This is wrong; the
balloon is vaguely related to memory, but is nothing like a PCI memory
device in the meaning of the class code, and this code is not required
or suggested by the virtio PCI specification.

Worse, this patch causes problems on the pseries machine, because the
firmware, seeing this class code, advertises the device as memory in the
device tree, and then a guest kernel bug causes it to see this "memory"
before the real system memory, leading to a crash in early boot.

This patch fixes the problem by removing the bogus PCI class code on the
balloon device.  The backwards compatibility PC machines get new compat
properties so that they don't change.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>