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>
target-arm: Fix TCG temp leaks for WI and UNDEF VFP sysreg writes

Fix a leak of a TCG temporary in code paths for VFP system register
writes for cases which UNDEF or are write-ignored.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
target-arm: Rename CPU types

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.
This leads to names like arm926-arm-cpu but is easiest to handle.

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

Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
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-mips: fix DSP loads with rd = 0

When rd is 0, which still need to do the actually load to possibly
generate a TLB exception.

Reviewed-by: Eric Johnson <ericj@mips.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
target-mips: copy insn_flags in DisasContext

Copy insn_flags in DisasContext to avoid passing a CPUMIPSState pointer
to subroutines, as suggested by Richard Henderson. Change subroutines to
use this new field and remove the first argument.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
target-mips: generate a reserved instruction exception on CPU without DSP

On CPU without DSP ASE support, a reserved instruction exception (instead of
a DSP ASE sate disabled) should be generated.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
target-mips: add unions to access DSP elements

Instead of playing with bit shifting, add two unions (one for 32-bit
values, one for 64-bit ones) to access all the DSP elements with the
correct type.

This make the code easier to read and less error prone, and allow GCC
to vectorize the code in some cases.

Reviewed-by: Eric Johnson <ericj@mips.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
target-mips: use DSP unions for binary DSP operators

This allow to reduce the number of macros.

Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>