e1000: document ICS read behaviour

Add code comment to clarify the reason we set ICS with ICR:
the reason was previously undocumented and git
log confused rather than clarified the comments.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
rules.mak: cleanup config generation rules

This addresses two issues with config generation
1. rule generating timestamp has side effect.
Thus cleanup on error does not work.
2. rule for handling timestamp is too generic.
It can create any missing .h file.
As a result when .h file is removed, build
might try to create it using this rule which
results in build errors.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Makefile: clean timestamp generation rule

create timestamp by rule without sideeffects.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
rules/mak: make clean should blow away timestamp files

Using a global pattern makes it easier to clean out
old generated files.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio-net: revert mac on reset

Once guest overrides virtio net primary mac,
it retains the value set until qemu exit.
This is inconsistent with standard nic behaviour.
To fix, revert the mac to the original value on reset.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio-net: remove layout assumptions for ctrl vq

Virtio-net code makes assumption about virtqueue descriptor layout
(e.g. sg[0] is the header, sg[1] is the data buffer).

This patch makes code not rely on the layout of descriptors.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio-net: introduce a new macaddr control

In virtio-net guest driver, currently we write MAC address to
pci config space byte by byte, this means that we have an
intermediate step where mac is wrong. This patch introduced
a new control command to set MAC address, it's atomic.

VIRTIO_NET_F_CTRL_MAC_ADDR is a new feature bit for compatibility.

"mac" field will be set to read-only when VIRTIO_NET_F_CTRL_MAC_ADDR
is acked.

Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio-net: rename ctrl rx commands

This patch makes rx commands consistent with specification.

Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
ich9: add support for pci assignment

Fills out support for the pci assignment API.  Added:

PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin)

Add calls to pci_bus_fire_intx_routing_notifier() when routing changes
are made.

Signed-off-by: Jason Baron <jbaron@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set

  Traditional PCI config space access is achieved by writing a 32 bit
  value to io port 0xcf8 to identify the bus, device, function and config
  register. Port 0xcfc then contains the register in question. But if you
  write the appropriate pair of magic values to 0xcf9, the machine will
  reboot. Spectacular! And not standardised in any way (certainly not part
  of the PCI spec), so different chipsets may have different requirements.
  Booo.

In the PIIX3 spec, IO port 0xcf9 is specified as the Reset Control
Register. Bit 1 (System Reset, SRST) would normally differentiate between
soft reset and hard reset, but we ignore the difference beyond allowing
the guest to read it back.

RHBZ reference: 890459

This patch introduces the following overlap between the preexistent
"pci-conf-idx" region and the "piix3-reset-control" region just being
added. Partial output from "info mtree":

  I/O
  0000000000000000-000000000000ffff (prio 0, RW): io
    0000000000000cf8-0000000000000cfb (prio 0, RW): pci-conf-idx
    0000000000000cf9-0000000000000cf9 (prio 1, RW): piix3-reset-control

I sanity-checked the patch by booting a RHEL-6.3 guest and found no
problems. I summoned gdb and set a breakpoint on rcr_write() in order to
gather a bit more confidence. Relevant frames of the stack:

  kvm_handle_io (port=3321, data=0x7f3f5f3de000, direction=1, size=1,
                 count=1)                                 [kvm-all.c:1422]
    cpu_outb (addr=3321, val=6 '\006')                      [ioport.c:289]
      ioport_write (index=0, address=3321, data=6)           [ioport.c:83]
        ioport_writeb_thunk (opaque=0x7f3f622c4680, addr=3321, data=6)
                                                            [ioport.c:212]
          memory_region_iorange_write (iorange=0x7f3f622c4680, offset=0,
                                       width=1, data=6)     [memory.c:439]
            access_with_adjusted_size (addr=0, value=0x7f3f531fbac0,
                                       size=1, access_size_min=1,
                                       access_size_max=4,
                                       access=0x7f3f5f6e0f90
                                           <memory_region_write_accessor>,
                                       opaque=0x7f3f6227b668)
                                                            [memory.c:364]
              memory_region_write_accessor (opaque=0x7f3f6227b668, addr=0,
                                            value=0x7f3f531fbac0, size=1,
                                            shift=0, mask=255)
                                                            [memory.c:334]
                rcr_write (opaque=0x7f3f6227afb0, addr=0, val=6, len=1)
                                                       [hw/piix_pci.c:498]

The dispatch happens in ioport_write(); "index=0" means byte-wide access:

    static void ioport_write(int index, uint32_t address, uint32_t data)
    {
        static IOPortWriteFunc * const default_func[3] = {
            default_ioport_writeb,
            default_ioport_writew,
            default_ioport_writel
        };
        IOPortWriteFunc *func = ioport_write_table[index][address];
        if (!func)
            func = default_func[index];
        func(ioport_opaque[address], address, data);
    }

The "ioport_write_table" and "ioport_opaque" arrays describe the flattened
IO port space. The first array is less interesting (it selects a thunk
function). The "ioport_opaque" array is interesting because it decides how
writing to the port is implemented ultimately.

4-byte wide access to 0xcf8 (pci-conf-idx):

  (gdb) print ioport_write_table[2][0xcf8]
  $1 = (IOPortWriteFunc *) 0x7f3f5f6d99ba <ioport_writel_thunk>

  (gdb) print \
        ((struct MemoryRegionIORange*)ioport_opaque[0xcf8])->mr->ops.write
  $2 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
       0x7f3f5f5575cb <pci_host_config_write>

1-byte wide access to 0xcf9 (piix3-reset-control):

  (gdb) print ioport_write_table[0][0xcf9]
  $3 = (IOPortWriteFunc *) 0x7f3f5f6d98d0 <ioport_writeb_thunk>

  (gdb) print \
        ((struct MemoryRegionIORange*)ioport_opaque[0xcf9])->mr->ops.write
  $4 = (void (*)(void *, hwaddr, uint64_t, unsigned int))
       0x7f3f5f6b42f1 <rcr_write>

The higher priority of "piix3-reset-control" ensures that the 0xcf9
entries in ioport_write_table / ioport_opaque will always belong to it,
independently of its relative registration order versus "pci-conf-idx".

Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
vfio-pci: Enable PCIe extended config space

We don't know pre-init time whether the device we're exposing is PCIe
or legacy PCI.  We could ask for it to be specified via a device
option, but that seems like too much to ask of the user.  Instead we
can assume everything will be PCIe, which makes PCI-core allocate
enough config space.  Removing the flag during init leaves the space
allocated, but allows legacy PCI devices to report the real device
config space size to rest of Qemu.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
cocoa: Fix VBE function Set Display Start

Register a dpy_gfx_setdata callback so that the Cocoa code
is notified whenever the screen start address changes.

Commit 1d3323d has a similar fix for the VNC UI.

Signed-off-by: Henry Harrington <henry.harrington@gmail.com>
Cc: qemu-stable@nongnu.org (1.3.x)
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
cocoa: Replace non-portable asprintf() by g_strdup_printf()

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
target-unicore32: Mark as unmigratable

CPU_SAVE_VERSION 2 was bogus as both save and load would just throw a
hw_error(). Therefore we can without problems suppress registration of
"cpu_common" VMState by dropping CPU_SAVE_VERSION define and provide an
unmigratable "cpu" VMStateDescription for UniCore32CPU at device level
instead, where we can attach this the QOM way.

Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Juan Quintela <quintela@redhat.com>
target-microblaze: Mark as unmigratable

cpu_{save,load} were no-ops, so de facto it is unmigratable and no
backwards compatibility to keep. Therefore mark the MicroBlazeCPU as
unmigratable at device level the QOM way and suppress "cpu_common"
VMState registration by dropping CPU_SAVE_VERSION.

Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Juan Quintela <quintela@redhat.com>
target-xtensa: Mark as unmigratable

There was no CPU_SAVE_VERSION defined, so neither "cpu_common" VMState
nor cpu_{save,load}() were registered. Their implementation was no-op.
Therefore there is no backwards compatibility to keep, so mark XtensaCPU
as unmigratable at device level.

Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Juan Quintela <quintela@redhat.com>
target-sh4: Mark as unmigratable

It neither defined CPU_SAVE_VERSION nor implemented cpu{save,load}().
Mark it as unmigratable at device level.

Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Juan Quintela <quintela@redhat.com>
target-s390x: Mark as unmigratable

CPU_SAVE_VERSION was undefined, so "cpu_common" VMState and
cpu_{save,load}() were not registered. They were no-ops.
Therefore there is no backwards compatibility to keep, so we can mark
S390CPU as unmigratable at device level.

Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Juan Quintela <quintela@redhat.com>
target-m68k: Mark as unmigratable

It neither defined CPU_SAVE_VERSION nor implemented cpu_{save,load}().
Mark M68kCPU as unmigratable at device level.

Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Juan Quintela <quintela@redhat.com>
target-m68k: Rename CPU subtypes

In the initial conversion of CPU models to QOM types, model names were
mapped 1:1 to type names. As a side effect this gained us a type "any",
which is now a device.

To avoid "-device any" silliness and to pave the way for compiling
multiple targets into one executable, adopt a <name>-<arch>-cpu scheme.

No functional changes for -cpu arguments or -cpu ? output.

Signed-off-by: Andreas Färber <afaerber@suse.de>