The vexpress-a15 QEMU model is supposed to be a V2P-CA15; the HBI
(a kind of board model number) for this coretile is 237, not 217.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The start bit should only be set to indicate that a function call is
underway, right now.  When done with function, clear it.
Signed-off-by: NChristoffer Dall <c.dall@virtualopensystems.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Note: the allocation in virtio_9p_init() is still leaked.  To be fixed
in a followup commit.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Once upon a time, it was decided that qemu_malloc(0) should abort.
Switching to glib retired that bright idea.  Some code that was added
to cope with it (e.g. in commits 702ef63f, b76b6e95) is still around.
Bury it.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Signed-off-by: NAndreas Färber <andreas.faerber@web.de>

Missing cast one one of the conditionally compiled printfs.
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Some printfs are throwing warnings when debug mode is enabled. Fixed.
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Some printfs are throwing warnings when debug mode is enabled. Fixed.
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

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: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

  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: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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: NJason Baron <jbaron@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This patch makes rx commands consistent with specification.
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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: NAmos Kong <akong@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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: NMichael S. Tsirkin <mst@redhat.com>

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: NMichael S. Tsirkin <mst@redhat.com>

set_bit on indicators doesn't go well on 32 bit targets:

note: expected 'long unsigned int *' but argument is of type 'uint64_t *'

Switch to bit shifts instead.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
[agraf: use 1ULL instead]
Signed-off-by: NAlexander Graf <agraf@suse.de>

Changed error codes in the channel subsystem / virtio-ccw code
(-EOPNOTSUPP -> -ENOSYS, -ERESTART -> -EINPROGRESS).

This should hopefully fix building on mingw32.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Map the I/O interruption code before calling into css.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add a new machine type, s390-ccw-virtio, making use of the
virtio-ccw transport to present virtio devices as channel
devices.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

s390_virtio_bus_find_mem() may return a NULL VirtIOS390Device.
If called with, e.g., args[0] == 0, this leads to a segfault.
Fix this by adding error handling as done for other hypercalls.

Present since baf0b55a (Implement
virtio reset).
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This moves all files only used by s390 system emulation to hw/s390x.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>

virtio-s390 devices are not being reset when their bus is.  To fix
this, add a reset method that forwards to virtio_reset.  This is
only needed because of the "strange" modeling of virtio devices;
the ->vdev link is being handled manually rather than through qdev.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

All TypeInfo definitions should be const.
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add a new virtio transport that uses channel commands to perform
virtio operations.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Some of the machine initialization for s390-virtio will be reused
by virtio-ccw.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Provide a mechanism for qemu to provide fully virtual subchannels to
the guest.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The current s390 machine uses the virtio console as default console,
but this doesn't mean that we always want to keep it that way for new
machines.

This patch introduces a way for a machine type to specify that it wants
the default console to be an SCLP console, which is a lot closer to what
real hardware does.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Reviewed-by: NAndreas Färber <afaerber@suse.de>

SysBusDeviceClass' initfn merely calls SysBusDeviceClass::init, so we
can already hook up our own realizefn overwriting this behavior.

A symmetric unrealizefn is not necessary, knowing that the child's
unrealizefn is still no-op, too. Avoids ripping it out again when
recursive realization at DeviceState-level is implemented.
Signed-off-by: NAndreas Färber <andreas.faerber@web.de>

Prepares for QOM realizefn by removing object creation from qdev initfn.
Signed-off-by: NAndreas Färber <andreas.faerber@web.de>

This keeps compatibility on machine-types pc-1.2 and older, and prints a
warning in case the requested configuration won't get the correct
topology.

I couldn't think of a better way to warn about broken topology when in
compat mode other than using error_report(). The warning message will
probably be buried in a log file somewhere, but it's better than
nothing.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This changes FW_CFG_MAX_CPUS and FW_CFG_NUMA to use apic_id_for_cpu(),
so the NUMA table can be based on the APIC IDs, instead of CPU index
(SeaBIOS knows nothing about CPU indexes, just APIC IDs).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

PC will not use max_cpus for that field, so move it outside the common
code so it can use a different value on PC.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Currently, the pc-1.4 machine init function enables PV EOI and then
calls the pc-1.2 machine init function. The problem with this approach
is that now we can't enable any additional compatibility code inside the
pc-1.2 init function because it would end up enabling the compatibility
behavior on pc-1.3 and pc-1.4 as well.

This reverses the logic so that the pc-1.2 machine init function will
disable PV EOI, and then call the pc-1.4 machine init function.

This way we can change older machine-types to enable compatibility
behavior, and the newer machine-types (pc-1.3, pc-q35-1.4 and
pc-i440fx-1.4) would just use the default behavior.

(This means that one nice side-effect of this change is that pc-q35-1.4
will get PV EOI enabled by default, too)

It would be interesting to eventually change pc_init_pci_no_kvmclock()
and pc_init_isa() to reuse pc_init_pci_1_2() as well (so we don't need
to duplicate compatibility code on those two functions). But this will
be probably much easier to do after we create a PCInitArgs struct for
the PC initialization arguments, and/or after we use global-properties
to implement the compatibility modes present in pc_init_pci_1_2().
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

Default to moving back to the IDLE state after the COLLECTING_DATA
state. For a well behaved guest this patch has no consequence, but
A bad guest could crash QEMU by using one of the erase commands
followed by a longer than 5 byte argument (undefined behaviour).
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

Software services a received packet by clearing the CTRL_S bit in the RX_CTRLn
register. If this bit is cleared, flush any packets queued for the device.
Reported-by: NJohn Williams <john.williams@xilinx.com>
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

The eth_can_rx() function only checks the first buffers status ("ping"). The
controller should be able to receive into "pong" when ping-pong is enabled.
Checks the active buffer (either "ping" or "pong") when determining can_rx()
rather than just testing "ping".
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

This is a follow up for several attempts to fix this issue.

Previous incarnations:

1. http://thread.gmane.org/gmane.linux.ubuntu.bugs.general/3156089
https://bugs.launchpad.net/bugs/918791
"qemu-kvm dies when using vmvga driver and unity in the guest" bug.
Fix by Serge Hallyn:
 https://launchpadlibrarian.net/94916786/qemu-vmware.debdiff
This fix is incomplete, since it does not check width and height
for being negative.  Serge weren't sure if that's the right place
to fix it, maybe the fix should be up the stack somewhere.

2. http://thread.gmane.org/gmane.comp.emulators.qemu/166064
by Marek Vasut: "vmware_vga: Redraw only visible area"

This one adds the (incomplete) check to vmsvga_update_rect_delayed(),
the routine just queues the rect updating but does no interesting
stuff.  It is also incomplete in the same way as patch by Serge,
but also does not touch width&height at all after adjusting x&y,
which is wrong.

As far as I can see, when processing guest requests, the device
places them into a queue (vmsvga_update_rect_delayed()) and
processes this queue in different place/time, namely, in
vmsvga_update_rect().  Sometimes, vmsvga_update_rect() is
called directly, without placing the request to the gueue.
This is the place this patch changes, which is the last
(deepest) in the stack.  I'm not sure if this is the right
place still, since it is possible we have some queue optimization
(or may have in the future) which will be upset by negative/wrong
values here, so maybe we should check for validity of input
right when receiving request from the guest (and maybe even
use unsigned types there).  But I don't know the protocol
and implementation enough to have a definitive answer.

But since vmsvga_update_rect() has other sanity checks already,
I'm adding the missing ones there as well.

Cc'ing BALATON Zoltan and Andrzej Zaborowski who shows in `git blame'
output and may know something in this area.

If this patch is accepted, it should be applied to all active
stable branches (at least since 1.1, maybe even before), with
minor context change (ds_get_*(s->vga.ds) => s->*).  I'm not
Cc'ing -stable yet, will do it explicitly once the patch is
accepted.

BTW, these checks use fprintf(stderr) -- it should be converted
to something more appropriate, since stderr will most likely
disappear somewhere.

Cc: Marek Vasut <marex@denx.de>
CC: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Andrzej Zaborowski <balrogg@gmail.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NSerge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>