The MPS2 FPGAIO block includes some simple free-running counters.
Implement these.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Message-id: 20180820141116.9118-2-peter.maydell@linaro.org

The kernel booting specification for an AArch32 kernel requires that
it is booted in Hyp mode if available; otherwise the kernel can't
enable KVM. We were incorrectly leaving the kernel in SVC mode.
If we're booting an AArch32 kernel in the Nonsecure state and Hyp
mode is available, start in it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NEdgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180820153020.21478-7-peter.maydell@linaro.org

Add a "virtualization" property to the vexpress-a15 board,
controlling presence of EL2. As with EL3, we default to
enabling it, but the user can disable it if they have an
older guest which can't cope with it being present.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-10-peter.maydell@linaro.org

Don't request that the arm_load_kernel() code should boot in secure
state if the CPU doesn't have a secure state. Currently this
doesn't make a difference because the boot.c code only examines
the secure_boot flag in code guarded by an ARM_FEATURE_EL3 check,
but upcoming changes for supporting booting into Hyp mode will
change that.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-9-peter.maydell@linaro.org

For the A15MPCore internal peripheral object, we handle GIC
security extensions support by checking whether the CPUs
have EL3 enabled; if so then we enable it also on the GIC.
Handle the virtualization extensions in the same way: if the
CPU has EL2 then enable it on the GIC and wire up the
virtualization-specific memory regions and the maintenance
interrupt.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-8-peter.maydell@linaro.org

Connect the VIRQ and VFIQ lines from the GIC to the CPU;
these exist always for both CPU and GIC whether the
virtualization extensions are enabled or not, so we
can just unconditionally connect them.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-7-peter.maydell@linaro.org

Connect the VIRQ and VFIQ lines from the GIC to the CPU;
these exist always for both CPU and GIC whether the
virtualization extensions are enabled or not, so we
can just unconditionally connect them.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-6-peter.maydell@linaro.org

Connect the VIRQ and VFIQ lines from the GIC to the CPU;
these exist always for both CPU and GIC whether the
virtualization extensions are enabled or not, so we
can just unconditionally connect them.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-5-peter.maydell@linaro.org

Connect the VIRQ and VFIQ lines from the GIC to the CPU;
these exist always for both CPU and GIC whether the
virtualization extensions are enabled or not, so we
can just unconditionally connect them.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-4-peter.maydell@linaro.org

Reduce the size of the per-cpu GICH memory regions from 0x1000
to 0x200. The registers only cover 0x200 bytes, and the Cortex-A15
wants to map them at a spacing of 0x200 bytes apart. Having the
region be too large interferes with mapping them like that, so
reduce it.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NLuc Michel <luc.michel@greensocs.com>
Message-id: 20180821132811.17675-3-peter.maydell@linaro.org

The PIIX4 hardware has block transfer buffer always enabled in
the hardware, but the i801 does not.  Add a parameter to pm_smbus_init
to force on the block transfer so the PIIX4 handler can enable this
by default, as it was disabled by default before.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1534796770-10295-9-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Change 880b1ffe "smbus: do not immediately complete commands"
changed pm_smbus to delay setting the host busy bit until the status
register was read, to work around a bug in AMIBIOS.  Unfortunately,
when interrupts are enabled, the status register will never get read
and the processing will never happen.

Modify the code to only delay setting the host busy bit if interrupts
are not enabled.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Hervé Poussineau <hpoussin@reactos.org>
Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <1534796770-10295-8-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Add the necessary code so that interrupts actually work from
the pm_smbus device.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1534796770-10295-7-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

There was no block transfer code in pm_smbus.c, and it is needed
for some devices.  So add it.

This adds both byte-by-byte block transfers and buffered block
transfers.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1534796770-10295-5-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

It did have write capability, but the manual says the behavior
with write enabled is undefined.  So just set an error in this
case.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1534796770-10295-4-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The I2C block transfer commands was not implemented correctly, it
read a length byte and such like it was an smbus transfer.

So fix the smbus_read_block() and smbus_write_block() functions
so they can properly handle I2C transfers, and normal SMBus
transfers (for upcoming changes).  Pass in a transfer size and
a bool to know whether to use the size byte (like SMBus) or use
the length given (like I2C).
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1534796770-10295-3-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Fix some spacing issues, remove extraneous comments, add some
defines instead of hard-coding numbers.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1534796770-10295-2-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

We can assign and verify the address before realizing and trying to plug.
reading/writing the address property should never fail for DIMMs, so let's
reduce error handling a bit by using &error_abort. Getting access to the
memory region now might however fail. So forward errors from
get_memory_region() properly.

As all memory devices should use the alignment of the underlying memory
region for guest physical address asignment, do detection of the
alignment in pc_dimm_pre_plug(), but allow pc.c to overwrite the
alignment for compatibility handling.
Reviewed-by: NEric Auger <eric.auger@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20180801133444.11269-5-david@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

All applicable memory regions always have an alignment > 0. All memory
backends result in file_ram_alloc() or qemu_anon_ram_alloc() getting
called, setting the alignment to > 0.

So a PCDIMM memory region always has an alignment > 0. NVDIMM copy the
alignment of the original memory memory region into the handcrafted memory
region that will be used at this place.

So the check for 0 can be dropped and we can reduce the special
handling.

Dropping this check makes factoring out of alignment handling easier as
compat handling only has to look at pcmc->enforce_aligned_dimm and not
care about the alignment of the memory region.
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20180801133444.11269-4-david@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

We can assign and verify the slot before realizing and trying to plug.
reading/writing the slot property should never fail, so let's reduce
error handling a bit by using &error_abort.

To do this during pre_plug, add and use (x86, ppc) pc_dimm_pre_plug().
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEric Auger <eric.auger@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20180801133444.11269-2-david@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The vmstate for isa_ipmi_bt was referencing into the bt structure,
instead create a bt structure separate and use that.

The version 1 of the BT transfer was fairly broken, if a migration
occured during an IPMI operation, it is likely the migration would
be corrupted because I misunderstood the VMSTATE_VBUFFER_UINT32()
handling, I thought it handled transferring the length field,
too.  So I just remove support for that.  I doubt anyone is using
it at this point.

This also removes the transfer of use_irq, since that should come
from configuration.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <1534798644-13587-1-git-send-email-minyard@acm.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Allow toggling on/off the VIRTIO_SCSI_F_T10_PI feature bit for both
vhost-scsi and vhost-user-scsi devices.
Signed-off-by: NGreg Edwards <gedwards@ddn.com>
Message-Id: <20180808195235.5843-4-gedwards@ddn.com>
Reviewed-by: NFelipe Franciosi <felipe@nutanix.com>
Reviewed-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Move the enablement of preset host features into the common
vhost_scsi_common_get_features() function.  This is in preparation for
having vhost-scsi also make use of host_features.
Signed-off-by: NGreg Edwards <gedwards@ddn.com>
Message-Id: <20180808195235.5843-3-gedwards@ddn.com>
Reviewed-by: NFelipe Franciosi <felipe@nutanix.com>
Reviewed-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

In preparation for having vhost-scsi also make use of host_features,
move it from struct VHostUserSCSI into struct VHostSCSICommon.
Signed-off-by: NGreg Edwards <gedwards@ddn.com>
Message-Id: <20180808195235.5843-2-gedwards@ddn.com>
Reviewed-by: NFelipe Franciosi <felipe@nutanix.com>
Reviewed-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Switch the apic away from using the old_mmio MemoryRegionOps
accessor functions.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-Id: <20180803101943.23722-1-peter.maydell@linaro.org>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This paves the way for implementing the CPU list with an RCU list,
which cannot be traversed in reverse order.

Note that this is the only caller of CPU_FOREACH_REVERSE.
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NEmilio G. Cota <cota@braap.org>
Message-Id: <20180819091335.22863-11-cota@braap.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The LSI 53c895a code does not handle the PPR Extended Message. Add
support to handle PPR Extended Message like SDTR and WDTR are handled.
That is, to skip past the message bytes and ignore the message.
Signed-off-by: NGeorge Kennedy <george.kennedy@oracle.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Use kernel common header for fw_cfg.

(unfortunately, optionrom.h must have its own define, since it's
actually an assembler header)
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180817155910.5722-2-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

There is currently a funny problem with the "mc146818rtc" device:
1) Start QEMU like this:
   qemu-system-ppc64 -M pseries -S
2) At the HMP monitor, enter "info qom-tree". Note that there is an
   entry for "/rtc (spapr-rtc)".
3) Introspect the mc146818rtc device like this:
   device_add mc146818rtc,help
4) Run "info qom-tree" again. The "/rtc" entry is gone now!

The rtc_finalize() function of the mc146818rtc device has two bugs: First,
it tries to remove a "rtc" property, while the rtc_realizefn() added a
"rtc-time" property instead. And second, it should have been done in an
unrealize function, not in a finalize function, to avoid that this causes
problems during introspection.

But since adding aliases to the global machine state should not be done
from a device's realize function anyway, let's rather fix this issue
by moving the creation of the alias to the code that creates the device
(and thus is run from the machine init functions instead), i.e. the
mc146818_rtc_init() function for most machines. The prep machines are
special, since the mc146818rtc device is created here in the realize
function of the i82378 device. Since we certainly don't want to add the
alias there, we add it to some code that is called from the ibm_40p_init()
machine init function instead.
Since the alias is now only created during the machine init, we can remove
the object_property_del() completely.

Fixes: 654a36d8Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1534419358-10932-5-git-send-email-thuth@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

mc146818rtc.c still contains some TABs. Replace them with spaces.
And while we're at it, also delete trailing whitespace in this file.
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1534419358-10932-4-git-send-email-thuth@redhat.com>
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

tests/cdrom-test -p /x86_64/cdrom/boot/megasas

Produces the following ASAN leak.

==25700==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7f06f8faac48 in malloc (/lib64/libasan.so.5+0xeec48)
    #1 0x7f06f87a73c5 in g_malloc (/lib64/libglib-2.0.so.0+0x523c5)
    #2 0x55a729f17738 in pci_dma_sglist_init /home/elmarco/src/qq/include/hw/pci/pci.h:818
    #3 0x55a729f2a706 in megasas_map_dcmd /home/elmarco/src/qq/hw/scsi/megasas.c:698
    #4 0x55a729f39421 in megasas_handle_dcmd /home/elmarco/src/qq/hw/scsi/megasas.c:1574
    #5 0x55a729f3f70d in megasas_handle_frame /home/elmarco/src/qq/hw/scsi/megasas.c:1955
    #6 0x55a729f40939 in megasas_mmio_write /home/elmarco/src/qq/hw/scsi/megasas.c:2119
    #7 0x55a729f41102 in megasas_port_write /home/elmarco/src/qq/hw/scsi/megasas.c:2170
    #8 0x55a729220e60 in memory_region_write_accessor /home/elmarco/src/qq/memory.c:527
    #9 0x55a7292212b3 in access_with_adjusted_size /home/elmarco/src/qq/memory.c:594
    #10 0x55a72922cf70 in memory_region_dispatch_write /home/elmarco/src/qq/memory.c:1473
    #11 0x55a7290f5907 in flatview_write_continue /home/elmarco/src/qq/exec.c:3255
    #12 0x55a7290f5ceb in flatview_write /home/elmarco/src/qq/exec.c:3294
    #13 0x55a7290f6457 in address_space_write /home/elmarco/src/qq/exec.c:3384
    #14 0x55a7290f64a8 in address_space_rw /home/elmarco/src/qq/exec.c:3395
    #15 0x55a72929ecb0 in kvm_handle_io /home/elmarco/src/qq/accel/kvm/kvm-all.c:1729
    #16 0x55a7292a0db5 in kvm_cpu_exec /home/elmarco/src/qq/accel/kvm/kvm-all.c:1969
    #17 0x55a7291c4212 in qemu_kvm_cpu_thread_fn /home/elmarco/src/qq/cpus.c:1215
    #18 0x55a72a966a6c in qemu_thread_start /home/elmarco/src/qq/util/qemu-thread-posix.c:504
    #19 0x7f06ed486593 in start_thread (/lib64/libpthread.so.0+0x7593)

Move the qemu_sglist_destroy() from megasas_complete_command() to
megasas_unmap_frame(), so map/unmap are balanced.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20180814141247.32336-1-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

Many of these are marked as "intentional/fix required" because they
just need adding a fall through comment.  This is exactly what this
patch does, except for target/mips/translate.c where it is easier to
duplicate the code, and hw/audio/sb16.c where I consulted the DOSBox
sources and decide to just remove the LOG_UNIMP before the fallthrough.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Use the automatic subregister extraction from the memory API, and avoid
that Coverity complains about missing fallthrough comments.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

mptsas1068 is currently listed as uncategorized device.
Mark it as storage device.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Message-Id: <1533076133-22745-1-git-send-email-linux@roeck-us.net>
Reviewed-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

x-root was renamed as such owing to the experimental nature of the
property; the underlying filesystem semantics were undecided
Signed-off-by: NBandan Das <bsd@redhat.com>
Message-id: 20180720214020.22897-6-bsd@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

To support larger file transfers, rely on a short packet
to detect end of the data phase and rewrite d->length to
the size received
Signed-off-by: NBandan Das <bsd@redhat.com>
Message-id: 20180720214020.22897-5-bsd@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

For large buffers, write may not copy the full buffer. For example,
on Linux, write imposes a limit of 0x7ffff000. Note that this does
not fix >4G transfers but ~>2G files will transfer successfully.
Signed-off-by: NBandan Das <bsd@redhat.com>
Message-id: 20180720214020.22897-4-bsd@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

usb_mtp_realloc() was being incorrectly used when allocating
buffer for incoming data. Set d->length only after resizing
the buffer.
Signed-off-by: NBandan Das <bsd@redhat.com>
Message-id: 20180720214020.22897-3-bsd@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The initiator can choose to cancel an ongoing request which
is specified by bRequest=0x64. If such a request arrives,
free up any pending state
Signed-off-by: NBandan Das <bsd@redhat.com>
Message-id: 20180720214020.22897-2-bsd@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This is mandated by the ohci specification. It tells at 6.4.4 on page 104
that for transfer descriptors that are retired with an error the done
queue interrupt counter is cleared as if the interrupt delay field of the
descriptions were zero.

Before this change, error conditions were handled similarly to the
successful condition which is especially troublesome for control transfers.
Some drivers (e.g., the AmigaOS-one) as well as the example code in the
spec, set the setup stage with an interrupt delay of seven (which means no
interrupt). This is fine under normal conditions, because one usually
doesn't want to be notified about the completion of this stage. However, if
an error occurs in this stage, these drivers will not get notified with the
current implementation. The fix addresses this by following the spec more
closely. Also, otherwise, the ability to set interrupt delay to seven would
be useless.

Note that Linux drivers that I looked at don't seem to be affected as they
set six as the interrupt delay presumably for the reason that they won't
get notified otherwise.
Signed-off-by: NSebastian Bauer <mail@sebastianbauer.info>
Message-id: 20180729191928.11254-1-mail@sebastianbauer.info
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>