The function will be also used for microMIPS Release 6.
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Reviewed-by: Leon Alrae <leon.alrae@imgtec.com>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Refactor those instructions in order to reuse them for microMIPS32
Release 6.
Rearrange gen_move_low32().
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Reviewed-by: Leon Alrae <leon.alrae@imgtec.com>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Remove an unused argument from decode_micromips32_opc()
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Reviewed-by: Leon Alrae <leon.alrae@imgtec.com>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
rt, rs were swapped
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Leon Alrae <leon.alrae@imgtec.com>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Convert only errno values which can be returned by system calls in
mips-semi.c and are not generic to all archs.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Add UHI semihosting support for MIPS. QEMU run with "-semihosting" option
will alter the behaviour of SDBBP 1 instruction -- UHI operation will be
called instead of generating a debug exception.
Also tweak Malta's pseudo-bootloader. On CPU reset the $4 register is set
to -1 if semihosting arguments are passed to indicate that the UHI
operations should be used to obtain input arguments.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
The BEV flag controls whether the boot exception vector is still
in place when starting a kernel. When cleared the exception vector
at EBASE (or hard coded address of 0x80000000) is used instead.
The early stages of the linux kernel would benefit from BEV still
being set to ensure any faults get handled by the boot rom exception
handlers. This is a moot point for system qemu as there aren't really
any BEV handlers, but there are other good reasons to change this...
The UHI (semi-hosting interface) defines special behaviours depending
on whether an application starts in an environment with BEV set or
cleared. When BEV is set then UHI assumes that a bootloader is
relatively dumb and has no advanced exception handling logic.
However, when BEV is cleared then UHI assumes that the bootloader
has the ability to handle UHI exceptions with its exception handlers
and will unwind and forward UHI SYSCALL exceptions to the exception
vector that was installed prior to running the application.
Signed-off-by: Matthew Fortune <matthew.fortune@imgtec.com>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Correct addresses passed around in semihosting to use a data type suitable
for both 32-bit and 64-bit targets.
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Reviewed-by: Aurelien Jarno <aurelien@aurel32.net>
Version: GnuPG v1
iQEcBAABAgAGBQJVis6zAAoJEJykq7OBq3PIB24H/in+3QORzkisfV4Z3t1AePZj
CZk4ETMKIVpDozD/3FmezqMyj7sMaX4fkBBvwxsaNC3Lvj6evr7b99iU8R20qthk
qhrfSyFsOtG+cx7MpkUpF5lXiQDhuYY1waLbPi9ql4FWyhuFU7wpsyhAJivCcBUr
rUVR+EEZrAutzq1EaY60GJJ3MKkkSVcPNZM+EEtdfMbceKpOGrkZmptUIUw6FWt9
Fs8ZyLI88H2Xny+nzBNB5yjqskI6oGWBzJXRWXeDGBOu9Z+OPQYJWT0ij3mxikju
fWDopvK0HokJPrMM536p8IauzORjOl09O0HYAXGpdpJAOU6il1XcCi6euAFiNOk=
=JjTf
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stefanha/tags/net-pull-request' into staging
# gpg: Signature made Wed Jun 24 16:37:23 2015 BST using RSA key ID 81AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
# gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>"
* remotes/stefanha/tags/net-pull-request:
net: simplify net_client_init1()
net: drop if expression that is always true
net: raise an error if -net type is invalid
net: replace net_client_init1() netdev whitelist with blacklist
net: add missing "netmap" to host_net_devices[]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Version: GnuPG v1
iQEcBAABAgAGBQJVisx5AAoJEJykq7OBq3PIbasIALJC/7BEyCSEubcjH25CIzao
D20ufmo8/Et6KGuD1r2zdGRXQ79q/SDCGStQK8QEEfvRxPMehngfCUb5aJXkcGbu
/bRIaHh7DFxSiPGJI1/1wwR1MC7tjjR6ZrpSd2OTF0VOZvuXlP3noWpX1eiRAcvu
ekK2vvYtDi03/Xzhbx8MIRSuYPAdh/tXZ3mrDfUQNrtO47QYAxh0C9ABzZVrHJCa
RFCFXPoqZroOcrVe20ZHLt82AUL0H3cfHvF74Z+LbOlPJ7JbP/5+PzLisAqX7VeE
VYvK78mQih41Ww+qYYx4lwhUMUW1fYYnN/MHpdU2LBHcF/tPqxz5kyvQ6GJhD5w=
=rdVl
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging
# gpg: Signature made Wed Jun 24 16:27:53 2015 BST using RSA key ID 81AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
# gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>"
* remotes/stefanha/tags/block-pull-request:
virito-blk: drop duplicate check
qemu-iotests: fix 051.out after qdev error message change
iov: don't touch iov in iov_send_recv()
raw-posix: Introduce hdev_is_sg()
raw-posix: Use DPRINTF for DEBUG_FLOPPY
raw-posix: DPRINTF instead of DEBUG_BLOCK_PRINT
Fix migration in case of scsi-generic
block: Use bdrv_is_sg() everywhere
nvme: Fix memleak in nvme_dma_read_prp
vvfat: add a label option
util/hbitmap: Add an API to reset all set bits in hbitmap
virtio-blk: Use blk_drain() to drain IO requests
block-backend: Introduce blk_drain()
throttle: Check current timers before updating any_timer_armed[]
block: Let bdrv_drain_all() to call aio_poll() for each AioContext
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Drop the union and move the hubport creation into the !is_netdev case.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 1432743412-15943-6-git-send-email-stefanha@redhat.com
Both is_netdev and !is_netdev paths already check that
net_client_init_func[opts->kind] is non-NULL so there is no need for the
if statement.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 1432743412-15943-5-git-send-email-stefanha@redhat.com
When a -net type is used that was not compiled into the binary there
should be an error message.
Note the special case for -net none, which is a no-op.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 1432743412-15943-4-git-send-email-stefanha@redhat.com
It's cumbersome to keep the whitelist up-to-date. New netdev backends
should most likely be allowed so a blacklist makes more sense than a
whitelist.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 1432743412-15943-3-git-send-email-stefanha@redhat.com
Although hmp-commands.hx lists "netmap" as a valid host_net_add type,
the command rejects it because it's missing from the list.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1432743412-15943-2-git-send-email-stefanha@redhat.com
in_num = req->elem.in_num, and req->elem.in_num is
checked in line 489, so the check about in_num variable
is superflous, let's drop it.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Message-id: 1435138164-11728-1-git-send-email-arei.gonglei@huawei.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Commit f006cf7fa9 ("qdev-monitor:
Propagate errors through qdev_device_add()") dropped a meaningless error
message. This change in output caused qemu-iotests 051 to fail:
QEMU_PROG: -device ide-drive,drive=disk: Device initialization failed.
-QEMU_PROG: -device ide-drive,drive=disk: Device 'ide-drive' could not be initialized
Update 051.out so the test passes again.
Cc: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Message-id: 1435071369-30936-1-git-send-email-stefanha@redhat.com
A typo means that the tests dependent on glib with subprocess
support are never run.
Fixes: 9d41401b90
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
We have agreed that OpenFirmware device paths in the "bootorder" fw_cfg
file should follow the pattern
/pci@i0cf8,%x/...
for devices that live behind an extra root bus. The extra root bus in
question is the %x'th among the extra root buses. (In other words, %x
gives the position of the affected extra root bus relative to the other
extra root buses, in bus_nr order.) %x starts at 1, and is formatted in
hex.
The portion of the unit address that comes before the comma is dynamically
taken from the main host bridge, similarly to sysbus_get_fw_dev_path().
Cc: Kevin O'Connor <kevin@koconnor.net>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The sysbus_get_fw_dev_path() function formats OpenFirmware device path
nodes ("driver-name@unit-address") for sysbus devices. The first choice
for "unit-address" is the base address of the device's first MMIO region.
The second choice is its first IO port.
However, if two sysbus devices with the same "driver-name" lack both MMIO
and PIO resources, then there is no good way to distinguish them based on
their OFW nodes, because in this case unit-address is omitted completely
for both devices. An example is TYPE_PXB_HOST ("pxb-host").
For the sake of such devices, introduce the explicit_ofw_unit_address()
"virtual member function". With this function, each sysbus device in the
same SysBusDeviceClass can state its own address.
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Tested-by: Marcel Apfelbaum <marcel@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI
Bus driver globally signals the firmware that PCI enumeration and resource
allocation have completed. At this point QEMU regenerates the ACPI payload
in an fw_cfg read callback, and this is when the PXB's _CRS gets
populated.
Unfortunately, when this happens, the PCI_COMMAND_MEMORY bit is clear in
the root bus's command register, *unlike* under SeaBIOS. The consequences
unfold as follows:
- When build_crs() fetches dev->io_regions[i].addr, it is all-bits-one,
because pci_update_mappings() --> pci_bar_address() calculated it as
PCI_BAR_UNMAPPED, due to the PCI_COMMAND_MEMORY bit being clear.
- Consequently, the SHPC MMIO BAR (bar 0) of the bridge is not added to
the _CRS, *despite* having been programmed in PCI config space.
- Similarly, the SHPC MMIO BAR of the PXB is not removed from the main
root bus's DWordMemory descriptor.
- Guest OSes (Linux and Windows alike) notice the pre-programmed SHPC BAR
within the PXB's config space, and notice that it conflicts with the
main root bus's memory resource descriptors. Linux reports
pci 0000:04:00.0: BAR 0: can't assign mem (size 0x100)
pci 0000:04:00.0: BAR 0: trying firmware assignment [mem
0x88200000-0x882000ff 64bit]
pci 0000:04:00.0: BAR 0: [mem 0x88200000-0x882000ff 64bit] conflicts
with PCI Bus 0000:00 [mem
0x88200000-0xfebfffff]
While Windows Server 2012 R2 reports
https://technet.microsoft.com/en-us/library/cc732199%28v=ws.10%29.aspx
This device cannot find enough free resources that it can use. If you
want to use this device, you will need to disable one of the other
devices on this system. (Code 12)
This issue was apparently encountered earlier, see the "hack" in:
https://lists.nongnu.org/archive/html/qemu-devel/2015-01/msg02983.html
and the current hole-punching logic in build_crs() and build_ssdt() is
probably supposed to remedy exactly that problem -- however, for OVMF they
don't work, because at the end of the PCI enumeration and resource
allocation, which cues the ACPI linker/loader client, the command register
is clear.
The "shpc" property of "pci-bridge", introduced in the previous patches,
allows us to disable the standard hotplug controller cleanly, eliminating
the SHPC bar and the conflict.
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
In the PCI expander bridge, we will want to disable those features of
pci-bridge that relate to SHPC (standard hotplug controller):
- SHPC bar and underlying MemoryRegion
- interrupt (INTx or MSI)
- effective hotplug callbacks
- other SHPC hooks (initialization, cleanup, migration etc)
Introduce a new feature request bit in the PCIBridgeDev.flags field, and
turn off the above if the bit is explicitly cleared.
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
It follows msi_present() in "include/hw/pci/msi.h".
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This should help catch property name typos at compile time.
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This should help catch property name typos at compile time.
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Change the signature of the function-like macro SHPC_VMSTATE(), so that we
can produce and expect this field conditionally in the migration stream,
starting with an upcoming patch.
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There is no _TEST() variant of VMSTATE_BUFFER_UNSAFE_INFO() yet, but we'll
soon need it. Introduce it and rebase the original
VMSTATE_BUFFER_UNSAFE_INFO() on top.
The parameter order of the new function-like macro follows that of
VMSTATE_SINGLE_TEST(): "_test" is introduced between "_state" and
"_version".
Cc: Juan Quintela <quintela@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
*) Do not use AI_ADDRCONFIG on listening sockets, because this flag
makes it impossible to explicitly listen on '127.0.0.1' if no global
ipv4 address is configured additionally, making this a very
uncomfortable option.
*) Add AI_V4MAPPED hint for connecting sockets.
If your system is globally only connected via ipv6 you often still want
to be able to use '127.0.0.1' and 'localhost' (even if localhost doesn't
also have an ipv6 entry).
For example, PVE - unless explicitly asking for insecure mode - uses
ipv4 loopback addresses with QEMU for live migrations tunneled over SSH.
These fail to start because AI_ADDRCONFIG makes getaddrinfo refuse to
work with '127.0.0.1'.
As for the AI_V4MAPPED flag: glibc uses it by default, and providing
non-0 flags removes it. I think it makes sense to use it.
I also want to point out that glibc explicitly sidesteps POSIX standards
when passing 0 as hints by then assuming both AI_V4MAPPED and
AI_ADDRCONFIG (the latter being a rather weird choice IMO), while
according to POSIX.1-2001 it should be assumed 0. (glibc considers its
choice an improvement.)
Since either AI_CANONNAME or AI_PASSIVE are passed in our cases, glibc's
default flags in turn are disabled again unless explicitly added, which
I do with this patch.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Cscope and TAGS files work in source directory rather than the build
directory, also, don't ask users to run configure first, because they
may have an out of tree build.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Doesn't appear to make a difference, but let's use it consistently.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Recent commit 3751d7c "vl: allow full-blown QemuOpts syntax for
-global" overloaded its existing argument syntax DRIVER.PROP=VALUE
with QemuOpts syntax. Unambigious as long as no DRIVER contains '='.
Its documentation claims that "the two syntaxes are equivalent."
Improve it to spell out how exactly the old syntax gets desugared into
the new one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This is an attempt to rearrange configure --help output a bit
and consolidate pairs of --enable/disable into its own section.
After this, help text is easier to sort, manage and read.
More descriptive text can be added as well, since we now have
more space.
While at it, mention en/dis-able-vte.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
libcacard.pc file lists only one package in Requires
field, which is nss, while glib-2.0 is also a requiriment.
Furthermore, for libraries used internally by the library
(this is the way nss and glib are used by libcacard),
Requires.private shold be used instead of Requires.
Fix both issues.
This does not affect linking of qemu because it links
with objects from libcacard directly.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
When loading migration fails due to a disagreement about
PCI config data we don't currently get any errors explaining
that was the cause of the problem or which byte in the config
data was at fault.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit 72ac97cdfc added two equivalent versions of decimal128Local.h,
one in libdecnumber/dpd/ and another in include/libdecnumber/dpd/.
Being identical by the code, the two files however differs in the
licensing terms. The one in libdecnumber/dpd/ (which is being
removed by this patch) is licensed as GPL3.1 (plus gcc runtime
exception), which, as far as I know, is not compatible with GPL-2.
This file is not used (it is included from
include/libdecnumber/dpd/decimal128.h, so version in include/ is
used).
More, the version in include/ can also be removed, since none
of the 3 defines from that file are actually used by the code.
Even more, one of the defines from there, decimal128SetSign,
is redefined (to equivalent value) in libdecnumber/dpd/decimal128.c,
but again, never used.
What a mess...
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Yongbok Kim