Calls the new SPICE QXL interface function spice_qxl_set_device_info to
set the hardware address of the graphics device represented by the QXL
interface (e.g. a PCI path) and the device display IDs (the IDs of the
device's monitors that belong to this QXL interface).
Also stops using the deprecated spice_qxl_set_max_monitors, the new
interface function replaces it.
Signed-off-by: Lukáš Hrázký <lhrazky@redhat.com>
Message-Id: <20190215150919.8263-1-lhrazky@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
No caller of usb_ep_get() calls it with a NULL device (previous commits
have addressed the few remaining cases which didn't explicitly check).
Replace check for 'dev == NULL' with an assert instead.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 1549460216-25808-10-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add an assert and an explicit check before the two callers to
usb_ep_get() in the USB redirector code to ensure the device
passed in is not NULL.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 1549460216-25808-9-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In musb_packet(), the call to usb_find_device() can return NULL
if it doesn't find a device matching 'addr' so explicitly check
the return value before passing it to usb_ep_get(). This then
allows the subsequent calculation of 'id' to be streamlined.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 1549460216-25808-8-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In uhci_handle_td(), the call to ehci_find_device() can return NULL
if it doesn't find a device matching 'addr' so explicitly check
the return value before passing it to usb_ep_get().
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 1549460216-25808-7-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
A call to ohci_find_device() can return NULL if it doesn't find a
device matching 'addr' so for the two callers, explicitly check
the return value before passing it to usb_ep_get().
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 1549460216-25808-6-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In ehci_process_itd(), the call to ehci_find_device() can return NULL
if it doesn't find a device matching 'devaddr' so explicitly check
the return value before passing it to usb_ep_get().
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 1549460216-25808-5-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Most callers of xhci_port_update() and xhci_wakeup() pass in a pointer
to an array entry and can never be NULL but add two defensive asserts
to protect against future changes (e.g. adding a new port speed, etc.)
adding a path through xhci_lookup_port() that could result in the
return of a NULL XHCIPort.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 1549460216-25808-3-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There is no need to calculate the 'eps' variable in usb_ep_get()
if 'ep' is the control endpoint. Instead the calculation should
be done after validating the input before returning an entry
indexed by the endpoint 'ep'.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Reviewed-by: Darren Kenny <Darren.Kenny@oracle.com>
Reviewed-by: Mark Kanda <Mark.Kanda@oracle.com>
Reviewed-by: Ameya More <ameya.more@oracle.com>
Message-id: 1549460216-25808-2-git-send-email-liam.merwick@oracle.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Here's the next batch of ppc and spapr patches. Higlights are:
* A bunch of improvements to TCG handling of vector instructions from
Richard Henderson and Marc Cave-Ayland
* Cleanup to the XICS interrupt controller from Greg Kurz, removing
the special KVM subclasses which were a bad idea
* Some refinements to the XIVE interrupt controller from Cédric Le
Goater
* Fix from Fabiano Rosas for a really dumb buffer overflow in the
device tree code for memory hotplug
* Code for allowing access to SPRs from the gdb stub from Fabiano
Rosas
* Assorted minor fixes and cleanups
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAlxqt4oACgkQbDjKyiDZ
s5KeaBAAzHortvO/rKiQ0hkhKdy9MtaBbuPIYwMYA5dQXYH2gOi/VZxXHBhwDczy
MdXv+5Y+OYEWL0RC6kJGceM4xCD4b+WzZMriwYA5q32YeiUHmduyWxdq8Ulasm32
xok5DheVjyJLS970Q8Qp1Ck7vRXfYVd/7R/hNExcKkYU3wczqVEDqglHyThxaP0s
pTKrPGSuT+kHfi4kuLQ2qyKeNe6XWrvmgBAnXsud6lqWQ7D0ZAalnzhEoMrEMeyK
ldjh/suB68WyJZ7Sl0REV2DlILLKc/wDSL4HMmjmyuV5ldEKVyqhM8f7tHMtzeET
Ab8zKd0F4L1ffjyN3gmrh4WtyTa5L1s8av/bJFfESFNT3ioPFuDeMYQGQH4y3hJg
nNGSJaWXRu/3c0/uRcA9SSxWQYSzKCz2WFEV06UK2JlajVd6Wy5zpjy/7spZhbQH
z4TOSQrnRdIveRBTyUTUkJjbAitocUfHs2vCfzDBhACfj2LovSicNG284LlZXF1U
/d6F668Z2aoDpdpgKh1QSOJ6bTS/1KwKCvZ89L15EUYOcCrZlZjECJR+WtGhTP7A
YKyylvBkZ5a+M7t0f/Rm8KAy5QnpEAy7fKqLGQw8aldqX2MK46acjEwA5v696yZk
iCyAas5gu0U6ytKMOYwT1Lq1hmID/fyBApXIeFJhz2KFzTb4PqM=
=QQra
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190219' into staging
ppc patch queue 2019-02-19
Here's the next batch of ppc and spapr patches. Higlights are:
* A bunch of improvements to TCG handling of vector instructions from
Richard Henderson and Marc Cave-Ayland
* Cleanup to the XICS interrupt controller from Greg Kurz, removing
the special KVM subclasses which were a bad idea
* Some refinements to the XIVE interrupt controller from Cédric Le
Goater
* Fix from Fabiano Rosas for a really dumb buffer overflow in the
device tree code for memory hotplug
* Code for allowing access to SPRs from the gdb stub from Fabiano
Rosas
* Assorted minor fixes and cleanups
# gpg: Signature made Mon 18 Feb 2019 13:47:54 GMT
# gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full]
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full]
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full]
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown]
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* remotes/dgibson/tags/ppc-for-4.0-20190219: (43 commits)
target/ppc: convert vmin* and vmax* to vector operations
target/ppc: convert vadd*s and vsub*s to vector operations
target/ppc: Split out VSCR_SAT to a vector field
target/ppc: Add set_vscr_sat
target/ppc: Use mtvscr/mfvscr for vmstate
target/ppc: Add helper_mfvscr
target/ppc: Remove vscr_nj and vscr_sat
target/ppc: Use helper_mtvscr for reset and gdb
target/ppc: Pass integer to helper_mtvscr
target/ppc: convert xxsel to vector operations
target/ppc: convert xxspltw to vector operations
target/ppc: convert xxspltib to vector operations
target/ppc: convert VSX logical operations to vector operations
target/ppc: convert vsplt[bhw] to use vector operations
target/ppc: convert vspltis[bhw] to use vector operations
target/ppc: convert vaddu[b,h,w,d] and vsubu[b,h,w,d] over to use vector operations
target/ppc: convert VMX logical instructions to use vector operations
xics: Drop the KVM ICS class
spapr/irq: Use the "simple" ICS class for KVM
xics: Handle KVM interrupt presentation from "simple" ICS code
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcara+AAoJEDhwtADrkYZTmU4P/jt4seb0EQZBl/+YpqdyT75m
H8RvJWTbzh7mstSeJNbyeUG9P9hmNB7j9X9uVF978csnqnp9W8x8pK91SnG+hbcI
H6nPh+/tBxTFLdBkxiTbtr7BD4aDVLsspfdD7eT1ZticSYubfNiSd7g0rgIlrR7M
B/OPgE2vt9pKbMGcQoSjBiaui+qnuAnWcpJlHbzsPkaAS9x6U+5tkfA0YbuUgI7k
9CR9HrzZGB2YU1E93CUIE0JntmnRF/RUK1OoiKwZu9nVlcUI5K08RdqMBUTM1m9P
QouCEomzr63UXgSqSE0wCu5efwdluGOqbrDBqjzam6QOn5+Rqbn3krbbcXfY8Bub
fVYMYbeLuGkXbX/Uvyj9YoZRJ8JLvAjkLecuWz27+wEHR3V0CjqoFLCmNYQt8T9R
ti+jj9cWPt40kSoUPMF6QuboORBmTGITS/sy2akq6rMnXxsDeoN1SLdNdYC/4Rax
S9j5mh0gR/YkrWwWO7Ydr7xSF9ciYFltPVEsgxVtZy/biGj52IjpjnGhTST+gJeB
Icd65cs/vgoaN9gX+n0SKf0mna162aysw3DMT4hKO42iBVQ+P0c37j1xv80pXgdw
THMJcOJFJ/PGUWpWHl/Q0wr5RkUqRpHcVp9NvssYOsbQgMA8YH+/2NV4yoJ7TIK5
JLrDXbKvl18myezVKtz8
=pNCA
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2019-02-18' into staging
QAPI patches for 2019-02-18
# gpg: Signature made Mon 18 Feb 2019 13:44:30 GMT
# gpg: using RSA key 3870B400EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full]
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full]
# Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653
* remotes/armbru/tags/pull-qapi-2019-02-18:
qapi: move RTC_CHANGE to the target schema
qmp: Deprecate query-events in favor of query-qmp-schema
Revert "qapi-events: add 'if' condition to implicit event enum"
qapi: remove qmp_unregister_command()
qapi: make query-cpu-definitions depend on specific targets
qapi: make query-cpu-model-expansion depend on s390 or x86
qapi: make query-gic-capabilities depend on TARGET_ARM
target.json: add a note about query-cpu* not being s390x-specific
qapi: make s390 commands depend on TARGET_S390X
qapi: make rtc-reset-reinjection and SEV depend on TARGET_I386
qapi: New module target.json
build: Deal with all of QAPI's .o in qapi/Makefile.objs
build-sys: move qmp-introspect per target
qapi: Generate QAPIEvent stuff into separate files
qapi: Prepare for system modules other than 'builtin'
qapi: Clean up modular built-in code generation a bit
qapi: Fix up documentation for recent commit a95291007b
qapi: Belatedly document modular code generation
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A few targets don't emit RTC_CHANGE, we could restrict the event to
the tagets that do emit it.
Note: There is a lot more of events & commands that we could restrict
to capable targets, with the cost of some additional complexity, but
the benefit of added correctness and better introspection.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190214152251.2073-19-armbru@redhat.com>
Move rtc-reset-reinjection and SEV in target.json and make them
conditional on TARGET_I386.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190214152251.2073-10-armbru@redhat.com>
Latest systems and host kernels support mepoch, which is a
feature that was meant to be supported for z14 GA1 from the
get-go. Let's copy it to the z14 GA1 default CPU model.
Machines s390-ccw-virtio-3.1 and older will retain the old CPU
models and will not provide this bit nor the extended PTFF
functions in the default model.
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Message-Id: <20190212011657.18324-2-walling@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
As we now always have PCI support, let's add it to the "qemu" CPU model,
taking care of backwards compatibility.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190212112323.15904-1-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
We tried to make pci support optional on s390x in the past;
unfortunately, we still require the s390 phb to be created
unconditionally due to backwards compatibility issues.
Instead of sinking more effort into this (including compat
handling for older machines etc.) for non-obvious gains, let's
just make CONFIG_PCI something that is always set on s390x.
Note that you can still fence off pci for the _guest_ if you
provide a cpu model without the zpci feature.
Message-Id: <20190211113255.3837-1-cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The KVM ICS class isn't used anymore. Drop it.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023084177.1011724.14693955932559990358.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The "simple" ICS class knows how to interract with KVM. Adapt sPAPR to use
it instead of the ICS KVM class.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023083585.1011724.2868047424353921455.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We want to use the "simple" ICS type in both KVM and non-KVM setups.
Teach the "simple" ICS how to present interrupts to KVM and adapt
sPAPR accordingly.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023082996.1011724.16237920586343905010.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The KVM ICS reset handler simply writes the ICS state to KVM. This
doesn't need the overkill parent_reset logic we have today. Also
we want to use the same ICS type for the KVM and non-KVM case with
pseries.
Call icp_set_kvm_state() from the "simple" ICS reset function.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023082407.1011724.1983100830860273401.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The pre_save(), post_load() and synchronize_state() methods of the
ICSStateClass type are really KVM only things. Make that obvious
by dropping the indirections and directly calling the KVM functions
instead.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023081817.1011724.14078777320394028836.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The KVM ICP class isn't used anymore. Drop it.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023081228.1011724.12474992370439652538.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The base ICP class knows how to interact with KVM. Adapt sPAPR to use it
instead of the ICP KVM class.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023080638.1011724.792095453419098948.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The realization of KVM ICP currently follows the parent_realize logic,
which is a bit overkill here. Also we want to get rid of the KVM ICP
class. Explicitely call icp_kvm_realize() from the base ICP realize
function.
Note that ICPStateClass::parent_realize is retained because powernv
needs it.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023080049.1011724.15423463482790260696.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The KVM ICP reset handler simply writes the ICP state to KVM. This
doesn't need the overkill parent_reset logic we have today. Call
icp_set_kvm_state() from the base ICP reset function instead.
Since there are no other users for ICPStateClass::parent_reset, and
it isn't currently expected to change, drop it as well.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023079461.1011724.12644984391500635645.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The pre_save(), post_load() and synchronize_state() methods of the
ICPStateClass type are really KVM only things. Make that obvious
by dropping the indirections and directly calling the KVM functions
instead.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <155023078871.1011724.3083923389814185598.stgit@bahia.lan>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that we have changed the XICS and the XIVE interrupt backend to
have different size for their IRQ number space, we do not need to
align their source numbers anymore. Remove the offset adjustment and
wire the dual 'qirq' handler to the 'qirq' handler of the current
interrupt mode in use.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190213210756.27032-3-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When using the 'dual' interrupt mode, the source numbers of both sPAPR
IRQ backends are aligned to share a common IRQ number space and to use
a similar mapping of the machine qemu_irq array which is indexed by
the source number.
The XICS IRQ number range initially being [ 0x1000 - 0x2000 ], this
requires to change the XICS ICSState offset to 0 and to provision for
an extra 4K of source numbers and qemu_irqs which will never be used
by the machine when running under the XICS interrupt mode. This is not
an optimal solution.
Change the init() method to allocate an IRQ number space of the
expected size for the XICS sPAPR IRQ backend. It breaks the interrupt
signaling when under the 'dual' mode because source numbers have
unexpected values but next patch will fix that.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20190213210756.27032-2-clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
buf_len is uint8_t which is not large enough to hold the result of:
nr_entries * sizeof(struct sPAPRDrconfCellV2) + sizeof(uint32_t);
for a nr_entries greater than 10.
This causes the allocated buffer 'int_buf' to be smaller than expected
and we eventually overwrite some of glibc's control structures (see
"chunk" in https://sourceware.org/glibc/wiki/MallocInternals)
The following error is seen while trying to free int_buf:
"free(): invalid next size (fast)"
Fixes: a324d6f166 "spapr: Support ibm,dynamic-memory-v2 property"
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Message-Id: <20190213172926.21740-1-farosas@linux.ibm.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Certain devices types, like memory/CPU, are now being handled using a
hotplug interface provided by a top-level MachineClass. Hotpluggable
host bridges are another such device where it makes sense to use a
machine-level hotplug handler. However, unlike those devices,
host-bridges have a parent bus (the main system bus), and devices with
a parent bus use a different mechanism for registering their hotplug
handlers: qbus_set_hotplug_handler(). This interface currently expects
a handler to be a subclass of DeviceClass, but this is not the case
for MachineClass, which derives directly from ObjectClass.
Internally, the interface only requires an ObjectClass, so expose that
in qbus_set_hotplug_handler().
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <154999589921.690774.3640149277362188566.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
MSI is the default and LSI specific code is guarded by the
xive_source_irq_is_lsi() helper. The xive_source_irq_set()
helper is a nop for MSIs.
Simplify the code by turning xive_source_irq_set() into
xive_source_irq_set_lsi() and only call it for LSIs. The
call to xive_source_irq_set(false) in spapr_xive_irq_free()
is also a nop. Just drop it.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <154999584656.690774.18352404495120358613.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This model brings out-of-the-box networking for all of Linux, MacOS 9 and OS X
without requiring the installation of additional drivers.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20190208172201.29001-1-mark.cave-ayland@ilande.co.uk>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Split mode doesn't make sense on pseries, neither with XICS nor XIVE. But
passing kernel-irqchip=split silently behaves like kernel-irqchip=on.
Other architectures that support kernel-irqchip do terminate QEMU when
split mode is requested but not available though. Do the same with pseries
for consistency.
Similarly, passing kernel-irqchip=on,accel=tcg starts the machine with the
emulated interrupt controller, ie, behaves like kernel-irqchip=off. However,
when passing kernel-irqchip=on,accel=kvm, if we can't initialize the KVM
XICS for some reason, ie, xics_kvm_init() fails, then QEMU is terminated.
This is inconsistent. Terminate QEMU all the same when requesting the
in-kernel interrupt controller without KVM.
Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <154964986747.291716.2679312373018476920.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In order to handle a race condition in the MacOS 9 CUDA driver, a
delay was introduced when raising the VIA SR interrupt inspired by
similar code in MacOnLinux.
During original testing of the MacOS 9 patches it was found that the
30us delay used in MacOnLinux did not work reliably within QEMU, and a
value of 300us was required to function correctly.
Recent experiments have shown two things: firstly when booting Linux,
MacOS 9 and MacOS X the fast path which bypasses the delay is never
triggered once the OS kernel is loaded making it effectively
useless. Rather than leave this code in place where a guest could
potentially enable it by accident and break itself, we might as well
just remove it.
Secondly the previous reliability issues are no longer present, and
this value can be reduced down to 20us with no apparent ill
effects. This has the benefit of considerably improving the
responsiveness of the ADB keyboard and mouse within the guest.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that IRQ allocation has been split in two (first allocate IRQ numbers,
then claim them), if the claiming fails, we must release the IRQs.
Fixes: 4fe75a8ccd "spapr: split the IRQ allocation sequence"
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
All this code is used with both the XICS and XIVE interrupt controllers.
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In 47973a2dbf we split the last generic chipset out of the PC
board, but forgot to remove the include of "hw/i386/pc.h".
Since it is now unused, remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In commit 91c1e9fcbd where we added dual-CPU support to
the ARMSSE, we set up the wiring of the expansion IRQs via nested
loops: the outer loop on 'i' loops for each CPU, and the inner loop
on 'j' loops for each interrupt. Fix a typo which meant we were
wiring every expansion IRQ line to external IRQ 0 on CPU 0 and
to external IRQ 1 on CPU 1.
Fixes: 91c1e9fcbd ("hw/arm/armsse: Support dual-CPU configuration")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The code for handling the NVIC SHPR1 register intends to permit
byte and halfword accesses (as the architecture requires). However
the 'case' line for it only lists the base address of the
register, so attempts to access bytes other than the first one
end up in the "bad write" default logic. This bug was added
accidentally when we split out the SHPR1 logic from SHPR2 and
SHPR3 to support v6M.
Fixes: 7c9140afd5 ("nvic: Handle ARMv6-M SCS reserved registers")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
The Zephyr RTOS happens to access SHPR1 byte at a time,
which is how I spotted this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJcZZvnAAoJENSXKoln91plz6UH/iqtHfPhGEj6o4CGFIx/8Ru/
k7XU552LgTGvIA1aHt9+dHNYWW/JRl1CvmdeECeAN/yFkKSdDmruW6hLV78dV6Jy
8xnnYt8bQhMfMSCIlkGh+CxFF0BCRoPrtH64ZVgZ9AnN00E6hyFlTHAYJEk8ZlcM
ov05JYneKlZWYDcJnYaGX6T7s8ALcq2O6FDUS88J9AiN303yt+kmaEC2WEt+xju4
+xPPBIIg8nqd3MlrQ/shpFcCOTN0OLQ4V5mQYLvbL3HGTzeZ8eYBRdqQ2DXpW8M8
OOFGhJrmfBYEC/me0T7suZnzLLNGGYz2jQWLlHy32COIAJv6GcUylGd9TDbGGP8=
=Py0Z
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-feb-14-2019' into staging
MIPS queue for February 14th, 2019
# gpg: Signature made Thu 14 Feb 2019 16:48:39 GMT
# gpg: using RSA key D4972A8967F75A65
# gpg: Good signature from "Aleksandar Markovic <amarkovic@wavecomp.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8526 FBF1 5DA3 811F 4A01 DD75 D497 2A89 67F7 5A65
* remotes/amarkovic/tags/mips-queue-feb-14-2019:
tests/tcg: target/mips: Add tests for MSA logic instructions
tests/tcg: target/mips: Add wrappers for MSA logic instructions
tests/tcg: target/mips: Add tests for MSA interleave instructions
tests/tcg: target/mips: Add wrappers for MSA interleave instructions
tests/tcg: target/mips: Add tests for MSA bit counting instructions
tests/tcg: target/mips: Add wrappers for MSA bit counting instructions
tests/tcg: target/mips: Add a header with test utilities
tests/tcg: target/mips: Add a header with test inputs
tests/tcg: target/mips: Remove an unnecessary file
target/mips: introduce MTTCG-enabled builds
hw/mips_cpc: kick a VP when putting it into Run statewq
target/mips: hold BQL in mips_vpe_wake()
hw/mips_int: hold BQL for all interrupt requests
target/mips: reimplement SC instruction emulation and use cmpxchg
target/mips: compare virtual addresses in LL/SC sequence
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
While testing mttcg VP0 could get stuck in a loop waiting for other
VPs to come up (which never actually happens). To fix this, kick VPs
while they are being powered up by Cluster Power Controller in an
async task which is triggered once the host thread is being spawned.
Signed-off-by: Miodrag Dinic <miodrag.dinic@imgtec.com>
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Make sure BQL is held for all interrupt requests.
For MTTCG-enabled configurations, handling soft and hard interrupts
between vCPUs must be properly locked. By acquiring BQL, make sure
all paths triggering an IRQ are synchronized.
Signed-off-by: Miodrag Dinic <miodrag.dinic@imgtec.com>
Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcZENcAAoJENro4Ql1lpzlR1IP/3VJbeI4RjOoO/Y1TLLF6y9u
p0vvkf+HGleQ87h2fe5GPQ0r5XJ7hRA7EGPerTKES10fo+Ctvd+0/kZJPnY8B072
JPi1qA++1dF14LtePuDJhmibirwFM2+USKjUAkAZ9D7QjhnbvJjCDnf7pIOfHB+K
WzFVZ42yCSPAjP9PNSJgdru/xydJInxEx4HoHelLW97MF9prK0CZPl1omW5v7z25
JCKmp1TGvxLFoyy3okZ49n675ECjogSzjnUkQxi1aw3d5jouREadvchrpka4GnYm
txT8YiybKbM2tHc2M8Y6fL0I/cKWsyqJcTnpgU0RfVHT1HiGYpXnHbRBQWw5VFO7
MWTCJKQ23KNXZDtvj42jaMDe+ZU4ptfsI750ZQ22f/HFAd/ox/4Lqb4n2pWac4F/
pJ1bN8y0TO316pdlIi41l+FTF5utRzZaErBHojfCTrKZjjWvbF9qkZRXpA7KlKE7
8dC7yoZY7QS/vP4+iy0l+dTImsKOdTCqG+sGoy8SCR8EZAPDJauUNxbRjT/qVkim
OfkHpadS3kZEOkrVhLdLRVfZza6EHgVj3uY/FpvsCNJycQ9BpYBm8SCJN/TUDZNB
92z2KZaYFkIEXiWP8XX5oRbPKCDZWariuMdv8XXnOnafU/Gr1Pw5flSjNzB/NPh5
QWFqg+KEqJ4szkW5uy/n
=I5Qi
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/elmarco/tags/chardev-pull-request' into staging
Chardev fixes
# gpg: Signature made Wed 13 Feb 2019 16:18:36 GMT
# gpg: using RSA key DAE8E10975969CE5
# gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full]
# gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full]
# Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5
* remotes/elmarco/tags/chardev-pull-request: (25 commits)
char-pty: remove write_lock usage
char-pty: remove the check for connection on write
chardev: add a note about frontend sources and context switch
terminal3270: do not use backend timer sources
char: update the mux handlers in class callback
chardev/wctablet: Fix a typo
char: allow specifying a GMainContext at opening time
chardev: ensure termios is fully initialized
tests: expand coverage of socket chardev test
chardev: fix race with client connections in tcp_chr_wait_connected
chardev: disallow TLS/telnet/websocket with tcp_chr_wait_connected
chardev: honour the reconnect setting in tcp_chr_wait_connected
chardev: use a state machine for socket connection state
chardev: split up qmp_chardev_open_socket connection code
chardev: split tcp_chr_wait_connected into two methods
chardev: remove unused 'sioc' variable & cleanup paths
chardev: ensure qemu_chr_parse_compat reports missing driver error
chardev: remove many local variables in qemu_chr_parse_socket
chardev: forbid 'wait' option with client sockets
chardev: forbid 'reconnect' option with server sockets
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This patch set contains a handful of patches I've collected over the
last few weeks. There's nothing really fundamental, but I thought it
would be good to send these out now as there are some other patch sets
on the mailing list that are getting ready to go.
As far as the actual patches, there's:
* A set that cleans up our FS dirty-mode handling.
* Support for writing MISA.
* The removal of Michael as a maintainer.
* A fix to {m,s}counteren handling.
* A fix to make sure the kernel's start address is computed correctly on
32-bit targets.
This makes my "RISC-V Patches for 3.2, Part 3" pull request defunct, as
it contains the same patches but based on a newer master. As usual,
I've tested this using a Fedora boot on the latest Linux. This patch
set does not include Bastian's decodetree patches because there were
some merge conflicts and while I've cleaned them up I want to get a
round of review first.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEAM520YNJYN/OiG3470yhUCzLq0EFAlxkOc4THHBhbG1lckBk
YWJiZWx0LmNvbQAKCRDvTKFQLMurQZwhEACZtcbDNgXFnV3lpN4mQ7np3EYUsiFv
lEGip+/iBlTp2IWA7pXxw4wTV584/0uK9Y7errHoIB16JSNPpK1si5RTiUVWe8yo
QfYI8/c8zrXHkupMr+T4WZEu1WP6dgl5ZFO8tE/3xF2G/uMJwtTEXZ29OxUAa9tr
8Xsk8Sbs8LBa3YYY+8fGCEa/duG9Bb2DNIgyC6U0Iz3liKCFYWHnjODvs8c+Hpft
0A+VJ3zhAKLAoPymrKmbJc6mYdNNljHMaVg7uDnoxDpLo2Hb0pNuCd0AwmnJVKr5
eI6HV7XzEAxXOY96z4YWtS+/Mqxlo1wUhlkDO0acDoxFSz7XDSMecxowwdNWuwzM
WlHPUAd7VQ8j8oSO4dnRAZnC7Trn172q1tpg+xjWxm8FZuyBzTrOjwoVUW9hoXTt
62GQKtDhWt++Uzq1q0hdaVAckz3c+yBGBCXlQG9wAJVyFSdowQTeYkcW5PU3f6nv
CkZ/nY4hQgtwgxB+PAIobcgkt07bhMnWAxQYRVJaKBAX5Ea7dudQHw9eSL6eI40X
GXhzt5jsj9HRhzSqaKqcIixO1ouIsvAoCD1QNLrCeXNEoa7xMOo7FCLWT3lpj49G
TWmUjrNA/qMB25HMVOaF7lH7mwRShg3wx5oqDQII35TcGx4u+psi9oApPyRUHOFx
syEZaIPiIn+nCw==
=Q/8G
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/palmer/tags/riscv-for-master-4.0-sf1' into staging
RISC-V Patches for the 4.0 Soft Freeze, Part 1
This patch set contains a handful of patches I've collected over the
last few weeks. There's nothing really fundamental, but I thought it
would be good to send these out now as there are some other patch sets
on the mailing list that are getting ready to go.
As far as the actual patches, there's:
* A set that cleans up our FS dirty-mode handling.
* Support for writing MISA.
* The removal of Michael as a maintainer.
* A fix to {m,s}counteren handling.
* A fix to make sure the kernel's start address is computed correctly on
32-bit targets.
This makes my "RISC-V Patches for 3.2, Part 3" pull request defunct, as
it contains the same patches but based on a newer master. As usual,
I've tested this using a Fedora boot on the latest Linux. This patch
set does not include Bastian's decodetree patches because there were
some merge conflicts and while I've cleaned them up I want to get a
round of review first.
# gpg: Signature made Wed 13 Feb 2019 15:37:50 GMT
# gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41
# gpg: issuer "palmer@dabbelt.com"
# gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown]
# gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41
* remotes/palmer/tags/riscv-for-master-4.0-sf1:
riscv: Ensure the kernel start address is correctly cast
target/riscv: fix counter-enable checks in ctr()
MAINTAINERS: Remove Michael Clark as a RISC-V Maintainer
RISC-V: Add misa runtime write support
RISC-V: Add misa.MAFD checks to translate
RISC-V: Add misa to DisasContext
RISC-V: Add priv_ver to DisasContext
RISC-V: Use riscv prefix consistently on cpu helpers
RISC-V: Implement mstatus.TSR/TW/TVM
RISC-V: Mark mstatus.fs dirty
RISC-V: Split out mstatus_fs from tb_flags
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The sun4uv_init() function expects vga_interface_type to be either
VGA_STD or VGA_NONE and sets up a stdvga device or no vga card
accordingly.
However, the code in vl.c prefers the Cirrus VGA card to stdvga if
it is available and the user and the machine did not specify anything
else.
So far this has not been a problem, since the Cirrus VGA was not linked
into the sparc64 target. But with the upcoming Kconfig build system,
all theoretically possible PCI cards will be enabled by default, so the
Cirrus VGA card might become available on the sparc64 target, too. vl.c
then picks the wrong card, causing sun4uv_init() to abort.
Thus let's make it explicit that we always want stdvga for sparc64 and
so set default_display = "std" for these machines.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <1550041639-10232-1-git-send-email-thuth@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20181016112232.23241-1-dgilbert@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
terminal3270 uses the front-end side of the chardev. It shouldn't
create sources from backend side context (with backend
functions).
send_timing_mark_cb calls qemu_chr_fe_write_all() which should be
thread safe.
This partially reverts changes from commit
2c716ba150.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190206174328.9736-4-marcandre.lureau@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
This will be needed by vhost-user-test, when each test switches to
its own GMainLoop and GMainContext. Otherwise, for a reconnecting
socket the initial connection will happen on the default GMainContext,
and no one will be listening on it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190202110834.24880-1-pbonzini@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Commit caa1ee43 "vhost-user-blk: add discard/write zeroes features
support" added fields to struct virtio_blk_config. This changes
the size of the config space and breaks migration from QEMU 3.1
and older:
qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x10 read: 41 device: 1 cmask: ff wmask: 80 w1cmask:0
qemu-system-ppc64: Failed to load PCIDevice:config
qemu-system-ppc64: Failed to load virtio-blk:virtio
qemu-system-ppc64: error while loading state for instance 0x0 of device 'pci@800000020000000:01.0/virtio-blk'
qemu-system-ppc64: load of migration failed: Invalid argument
Since virtio-blk doesn't support the "discard" and "write zeroes"
features, it shouldn't even expose the associated fields in the
config space actually. Just include all fields up to num_queues to
match QEMU 3.1 and older.
Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-id: 1550022537-27565-1-git-send-email-changpeng.liu@intel.com
Message-Id: <1550022537-27565-1-git-send-email-changpeng.liu@intel.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
HP-UX 10.20 uses busmaster writes to the CPU EIR to signal
interrupts from the SCSI constroller. (Similar to what is known
as MSI on x86)
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Message-Id: <20190211192039.5457-1-svens@stackframe.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
In several part we still using req->dev or VIRTIO_DEVICE(req->dev)
when we have already defined s and vdev pointers:
VirtIOBlock *s = req->dev;
VirtIODevice *vdev = VIRTIO_DEVICE(s);
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Message-id: 20190208142347.214815-1-sgarzare@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Cast the kernel start address to the target bit length.
This ensures that we calculate the initrd offset to a valid address for
the architecture.
Steps to reproduce the original problem (reported by Alex):
Build U-Boot for the virt machine for riscv32. Then run it with
$ qemu-system-riscv32 -M virt -kernel u-boot -nographic -initrd <a file>
You can find the initrd address with
U-Boot# fdt addr $fdtcontroladdr
U-Boot# fdt ls /chosen
Then take a peek at that address:
U-Boot# md.b <addr>
and you will see that there is nothing there without this patch. The
reason is that the binary was loaded to a negative address.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Suggested-by: Alexander Graf <agraf@suse.de>
Reported-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
This is to enable OpenBIOS to claim the initrd memory as in-use before attempting
to boot the kernel.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
The sun4u/sun4v machine currently always creates a VGA device, even if
the user started QEMU with "-nodefaults" or "-vga none". That's likely
not what the users expect in this case, so add a check whether the VGA
adapter has really been requested.
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
When building with TSC_VERBOSE not defined, we get:
CC arm-softmmu/hw/input/tsc210x.o
hw/input/tsc210x.c: In function ‘tsc2102_data_register_write’:
hw/input/tsc210x.c:554:5: error: label at end of compound statement
default:
^~~~~~~
hw/input/tsc210x.c: In function ‘tsc2102_control_register_write’:
hw/input/tsc210x.c:638:5: error: label at end of compound statement
bad_reg:
^~~~~~~
hw/input/tsc210x.c: In function ‘tsc2102_audio_register_write’:
hw/input/tsc210x.c:766:5: error: label at end of compound statement
default:
^~~~~~~
make[1]: *** [rules.mak:69: hw/input/tsc210x.o] Error 1
Fix this by replacing the culprit fprintf(stderr) calls by a more
recent API: qemu_log_mask(LOG_GUEST_ERROR). Other fprintf() calls
are left untouched.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Message-Id: <20190204204517.23698-1-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
The device can not be instantiated by the user and QEMU currently
aborts when you try to use it:
$ x86_64-softmmu/qemu-system-x86_64 -device cpu-cluster
qemu-system-x86_64: hw/cpu/cluster.c:73: cpu_cluster_realize:
Assertion `cbdata.cpu_count > 0' failed.
Aborted (core dumped)
Since this is an internal device only, mark it with user_creatable = false.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Luc Michel <luc.michel@greensocs.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <1549371525-29899-1-git-send-email-thuth@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In 47973a2dbf we split the last generic chipset out of the PC
board, but forgot to remove the include of "hw/i386/pc.h".
Since it is now unused, remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190204210433.26088-3-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
In 47973a2dbf we split the last generic chipset out of the PC
board, but forgot to remove the include of "hw/i386/pc.h".
Since it is now unused, remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-Id: <20190204210433.26088-2-philmd@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
* Implement Armv8.5-BTI extension for system emulation mode
* Implement the PR_PAC_RESET_KEYS prctl() for linux-user mode's Armv8.3-PAuth support
* Support TBI (top-byte-ignore) properly for linux-user mode
* gdbstub: allow killing QEMU via vKill command
* hw/arm/boot: Support DTB autoload for firmware-only boots
* target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAlxZwhYZHHBldGVyLm1h
eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3uoCEACm4ds3KGV+bA1dtC367Th7
UKsxiVJ6xD7d1BaN3TyofkLTp0aJZgaYKqFjFhnagP8JoDgerdbno0xZ/9Wu2xIC
CFopSO9MP373wdBy/fbIoYoiSle0P/Gofk40C8HnbRb+C4mj2X0oft33DVlo50RK
p7JZSvHUqvCGrWLqeIKjJ1R+U31/dBx9Xprcg75EOiGGc+9Urb9w3Zmj11QE/eHh
X6cFMM6xUn2aDYLRkbyHNjSOADHehtC/UhnHOpnsiQSnIfkYudF/pwDOPuBjmZkm
9rv8DzR9KvAy2ybbD4lrywH7W00QAnS2COVmpcFidWe9ur+glPMCk2XAuuWOK5J3
+WFsWxCg3VuZ74PL/DclKNp7QqgKhloTV0Q1TPp0z894HYca8faIXEJLoLtHSR7+
2cAFJ7vaj9FMw4wn6XGrcx7olhPy81BhzM2g0eTSOb8T8Fe1mje0Q9Zg5Sc+sTYj
5vIjl37fHclBjxhnD3+F+ZQ+P2GK4/5gFPY9gezXPQWJAtD80MLBn6h/fvT8tTJm
DlaMqFrIiQatllQDm9DmhNJg8707t6m8A6FIjhRDbfjS8Uw45Q+H2KdUfnVQJP8N
1ZCbTGRfhl4qwUy3jigYM448W10/T1l4/0BFcXdt/qc6C3QSjsqfHPlsft4XIaRf
rUgbqfNBHr/i1n+SN5L4KQ==
=XEy2
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190205' into staging
target-arm queue:
* Implement Armv8.5-BTI extension for system emulation mode
* Implement the PR_PAC_RESET_KEYS prctl() for linux-user mode's Armv8.3-PAuth support
* Support TBI (top-byte-ignore) properly for linux-user mode
* gdbstub: allow killing QEMU via vKill command
* hw/arm/boot: Support DTB autoload for firmware-only boots
* target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI
# gpg: Signature made Tue 05 Feb 2019 17:04:22 GMT
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20190205: (22 commits)
target/arm: Make FPSCR/FPCR trapped-exception bits RAZ/WI
hw/arm/boot: Support DTB autoload for firmware-only boots
hw/arm/boot: Clarify why arm_setup_firmware_boot() doesn't set env->boot_info
hw/arm/boot: Factor out "set up firmware boot" code
hw/arm/boot: Factor out "direct kernel boot" code into its own function
hw/arm/boot: Fix block comment style in arm_load_kernel()
gdbstub: allow killing QEMU via vKill command
target/arm: Enable TBI for user-only
target/arm: Compute TB_FLAGS for TBI for user-only
target/arm: Clean TBI for data operations in the translator
target/arm: Add TBFLAG_A64_TBID, split out gen_top_byte_ignore
tests/tcg/aarch64: Add pauth smoke test
linux-user: Implement PR_PAC_RESET_KEYS
target/arm: Enable BTI for -cpu max
target/arm: Set btype for indirect branches
target/arm: Reset btype for direct branches
target/arm: Default handling of BTYPE during translation
target/arm: Cache the GP bit for a page in MemTxAttrs
exec: Add target-specific tlb bits to MemTxAttrs
target/arm: Add BT and BTYPE to tb->flags
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The arm_boot_info struct has a skip_dtb_autoload flag: if this is
set to true by the board code then arm_load_kernel() will not
load the DTB itself, but will leave this for the board code to
do itself later. However, the check for this is done in a
code path which is only executed for the case where we load
a kernel image file. If we're taking the "boot via firmware"
code path then the flag isn't honoured and the DTB is never
loaded.
We didn't notice this because the only real user of "boot
via firmware" that cares about the DTB is the virt board
(for UEFI boot), and that always wants skip_dtb_autoload
anyway. But the SBSA reference board model we're planning to
add will want the flag to behave correctly.
Now we've refactored the arm_load_kernel() function, the
fix is simple: drop the early 'return' so we fall into
the same "load the DTB" code the boot-direct-kernel path uses.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20190131112240.8395-6-peter.maydell@linaro.org
The code path for booting firmware doesn't set env->boot_info. At
first sight this looks odd, so add a comment saying why we don't.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20190131112240.8395-5-peter.maydell@linaro.org
Factor out the "boot via firmware" code path from arm_load_kernel()
into its own function.
This commit only moves code around; no semantic changes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20190131112240.8395-4-peter.maydell@linaro.org
Factor out the "direct kernel boot" code path from arm_load_kernel()
into its own function; this function is getting long enough that
the code flow is a bit confusing.
This commit only moves code around; no semantic changes.
We leave the "load the dtb" code in arm_load_kernel() -- this
is currently only used by the "direct kernel boot" path, but
this is a bug which we will fix shortly.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20190131112240.8395-3-peter.maydell@linaro.org
Fix the block comment style in arm_load_kernel() to QEMU's
current style preferences. This will allow us to do some
refactoring of this function without checkpatch complaining
about the code-motion patches.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-id: 20190131112240.8395-2-peter.maydell@linaro.org
vhost user blk discard/write zeroes features
misc cleanups and fixes all over the place
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcWbMUAAoJECgfDbjSjVRp2acH+wa8abfyQIpVMji+cdvcw7Wo
yJjCoPxX0y+tm7FGp6YjyyQhSzjUYRS+71NL6xkZVxs8yh4ZCbb/xDRYmrVG2cb6
6tUcqp1zlMp+w+kVKS4m4WTb0Z1bIODOi99tNBXxYjWY9lXF/hjZbhRpt6vL/NaP
hqYtp+wlhyjxsY/GFn5XZLY7F6+QKq/lsMJD80FvbtHBh/ngqmgyoouNwYzg1faW
M3wD5A3IOXLzU+MGK6uCtKK0+t3xzvaVJL7zChimKkn+y+Pg9T+s04zQS739bJRg
dYYrVK3IOt2tvVxBZnnUm9eBIxxElAxRssmERPe2i0mBRSXYKomuVZrXJ6ROhjA=
=TxWc
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pci, pc, virtio: fixes, cleanups, features
vhost user blk discard/write zeroes features
misc cleanups and fixes all over the place
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Tue 05 Feb 2019 16:00:20 GMT
# gpg: using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream:
contrib/libvhost-user: cleanup casts
r2d: fix build on mingw
mmap-alloc: fix hugetlbfs misaligned length in ppc64
mmap-alloc: unfold qemu_ram_mmap()
i386, acpi: cleanup build_facs by removing second unused argument
fw_cfg: fix the life cycle and the name of "qemu_extra_params_fw"
acpi: Make TPM 2.0 with TIS available as MSFT0101
hw/virtio: Use CONFIG_VIRTIO_PCI switch instead of CONFIG_PCI
vhost-user-blk: add discard/write zeroes features support
contrib/vhost-user-blk: fix the compilation issue
pci/msi: export msi_is_masked()
intel_iommu: reset intr_enabled when system reset
intel_iommu: fix operator in vtd_switch_address_space
hw: virtio-pci: drop DO_UPCAST
include: update Linux headers to 4.21-rc1/5.0-rc1
scripts/update-linux-headers.sh: adjust for Linux 4.21-rc1 (or 5.0-rc1)
contrib/libvhost-user: switch to uint64_t
virtio: add checks for the size of the indirect table
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Comment near strncpy explains kernel_cmdline does
not need to be 0-terminated.
Accordingly mark it as QEMU_NONSTRING.
Without this, gcc warns:
'strncpy' specified bound 256 equals destination size
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The second argument of build_facs() is not used, just remove it.
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Commit 19bcc4bc32 ("fw_cfg: Make qemu_extra_params_fw locally",
2019-01-04) changed the storage duration of the "qemu_extra_params_fw"
array from static to automatic. This broke the interface contract on the
fw_cfg_add_file() function, which is documented as follows, in
"include/hw/nvram/fw_cfg.h":
> [...] The data referenced by the starting pointer is only linked, NOT
> copied, into the data structure of the fw_cfg device. [...]
As a result, when guest firmware fetches the "etc/boot-menu-wait" fw_cfg
file, it now sees garbage. Fix the regression by changing the storage
duration to allocated. (The call is reached at most once, on the realize
path of the board-specific fw_cfg sysbus device.)
While at it, clean up the name and the assignment of the object as well.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: 19bcc4bc32
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>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This patch makes the a TPM 2.0 with TIS interface available under the
HID 'MSF0101'. This is supported by Linux and also Windows now
recognizes the TPM 2.0 with TIS interface. Leave the TPM 1.2 as before.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
For downstream s390x builds, we'd like to be able to build QEMU with
CONFIG_VIRTIO_PCI disabled (since virtio-ccw is used here instead),
but still with CONFIG_PCI enabled. This currently fails since the
virtio-*-pci.o files are still included in the build, but virtio-pci.o
is missing. Use the right config switch CONFIG_VIRTIO_PCI to exclude
the virtio-*-pci.o files from the build.
Reported-by: Miroslav Rezanina <mrezanin@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Linux commit 1f23816b8 "virtio_blk: add discard and write zeroes support"
added the support in the Guest kernel, while here also enable the features
support with vhost-user-blk driver. Also enable the test example utility
with DISCARD and WRITE ZEROES commands.
Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
It is going to be used later on outside MSI code to detect whether one
MSI vector is masked out.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This is found when I was debugging another problem. Until now no bug
is reported with this but we'd better reset the IR status correctly
after a system reset.
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When calculating use_iommu, we wanted to first detect whether DMAR is
enabled, then check whether PT is enabled if DMAR is enabled. However
in the current code we used "&" rather than "&&" so the ordering
requirement is lost (instead it'll be an "AND" operation). This could
introduce errors dumped in QEMU console when rebooting a guest with
both assigned device and vIOMMU, like:
qemu-system-x86_64: vtd_dev_to_context_entry: invalid root entry:
rsvd=0xf000ff53f000e2c3, val=0xf000ff53f000ff53 (reserved nonzero)
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Use VIRTIO_PCI MACRO instead.
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Let's avoid manually looking up the hotplug handler class. Use the
existing wrappers instead.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20181212095707.19358-1-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make hw/vfio configurable and add new CONFIG_VFIO_* to the
default-configs/s390x*-softmmu.mak. This allow a finer-grain
selection of the various VFIO backends.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-28-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Create separate variables for these components, they are
used in many boards but not all. This allows finer-grain
selection of the included code with default-configs/*.mak.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-27-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/tricore-sofmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-26-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/or1k-sofmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-25-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_MOXIE added for moxiesim board.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-24-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/hppa-sofmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20190202072456.6468-23-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/cris-sofmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-22-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/alpha-sofmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20190202072456.6468-21-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/sparc64-sofmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-20-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/riscv*-sofmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-19-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_NIOS2_10M50 added for 10m50 dev board.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-18-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new CONFIG_* values to default-config/xtensa*-softmmu.mak.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Message-Id: <20190202072456.6468-17-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_LM32 and CONFIG_MILKYMIST added for lm32 and milkmyst build.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-16-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_LEON3 added to default-configs/sparc-softmmu.mak.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-15-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make hw/s390x configurable and add new CONFIG_* to the
default-configs/s390x*-softmmu.mak. This will be used to
enable/disable vfio-ccw.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-14-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make hw/sh4 configurable and add new CONFIG_* to the
default-configs/sh4*-softmmu.mak.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-13-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_PPC405, CONFIG_PPC440, CONFIG_MAC_OLDWORLD, CONFIG_MAX_NEWWORLD
and CONFIG_VIRTEX configuration options created for
default-configs/ppc*-softmmu.mak.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-12-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add the new configs to default-configs/mips*-sofmmu.mak.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-11-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_PETALOGIX_* and CONFIG_XLNX_* configs added to
default-configs/microblaze-softmmu.mak and
default-configs/microblazeel-softmmu.mak.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-10-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_AN5206, CONFIG_MCF5206 and CONFIG_MCF5208 make
variables created for m68k boards, and added to
default-configs/m86k-softmmu.mak.
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-9-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Make ARM virt code configurable and the new CONFIG_ARM_VIRT
definitions added to the default-configs/arm-softmmu.mak.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-8-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CONFIG_PIIX and CONFIG_Q35 created for the pc board object files. These
are enabled automatically at default-configs/i386-softmmu.mak and
default-configs/x86_64-softmmu.mak
Signed-off-by: Ákos Kovács <akoskovacs@gmx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-7-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Do not link it unconditionally into all binaries.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-6-yang.zhong@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Change the CONFIGs for PCI EXPRESS and make module name more
clear for code files.
Signed-off-by: Yang Zhong <yang.zhong@intel.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-5-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Instead of wrapping the entire Makefile.objs with an ifeq/endif, just
include the directory only for Linux.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-4-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is not needed on ARM, and brings in ISA bus code which is otherwise not
necessary.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190202072456.6468-3-yang.zhong@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Whenever the allocation length of a SCSI request is shorter than the size of the
VPD page list, page_idx is used blindly to index into r->buf. Even though
the stores in the insertion sort are protected against overflows, the same is not
true of the reads and the final store of 0xb0.
This basically does the same thing as commit 57dbb58d80 ("scsi-generic: avoid
out-of-bounds access to VPD page list", 2018-11-06), except that here the
allocation length can be chosen by the guest. Note that according to the SCSI
standard, the contents of the PAGE LENGTH field are not altered based
on the allocation length.
The code was introduced by commit 6c219fc8a1 ("scsi-generic: keep VPD
page list sorted", 2018-11-06) but the overflow was already possible before.
Reported-by: Kevin Wolf <kwolf@redhat.com>
Fixes: a71c775b24
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (version 2)")
linux has supported initrd up to 4 GB, but the header field
ramdisk_max is still set to 2 GB to avoid "possible bootloader bugs".
When use '-kernel vmlinux -initrd initrd.cgz' to launch a VM,
the firmware(it could be linuxboot_dma.bin) helps to read initrd
contents into guest memory(below ramdisk_max) and jump to kernel.
that's similar with what bootloader does, like grub.
In addition, initrd_max is uint32_t simply because QEMU doesn't support
the 64-bit boot protocol (specifically the ext_ramdisk_image field).
Therefore here just limit initrd_max to UINT32_MAX simply as well to
allow initrd to be loaded below 4 GB.
NOTE: it's possible that linux protocol within [0x208, 0x20c]
supports up to 4 GB initrd as well.
CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Eduardo Habkost <ehabkost@redhat.com>
CC: "Michael S. Tsirkin" <mst@redhat.com>
CC: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
it's from v4.20-rc5.
CC: Stefano Garzarella <sgarzare@redhat.com>
CC: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Don't expect read(2) can always read as many as it's told.
CC: Richard Henderson <richard.henderson@linaro.org>
CC: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In order to avoid migration issues, we enable PVH only for
machine type >= 4.0
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Use pvh.bin option rom when we are booting an uncompressed
kernel using the x86/HVM direct boot ABI.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Based-on: <1547554687-12687-1-git-send-email-liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When initrd is specified, load and expose it to the guest firmware
through fw_cfg. The firmware will fill the hvm_start_info for the
kernel.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Based-on: <1545422632-24444-5-git-send-email-liam.merwick@oracle.com>
Signed-off-by: Liam Merwick <Liam.Merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These changes (along with corresponding Linux kernel and qboot changes)
enable a guest to be booted using the x86/HVM direct boot ABI.
This commit adds a load_elfboot() routine to pass the size and
location of the kernel entry point to qboot (which will fill in
the start_info struct information needed to to boot the guest).
Having loaded the ELF binary, load_linux() will run qboot
which continues the boot.
The address for the kernel entry point is read from an ELF Note
in the uncompressed kernel binary by a helper routine passed
to load_elf().
Co-developed-by: George Kennedy <George.Kennedy@oracle.com>
Signed-off-by: George Kennedy <George.Kennedy@oracle.com>
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch adds an optional function pointer, 'elf_note_fn', to
load_elf() which causes load_elf() to additionally parse any
ELF program headers of type PT_NOTE and check to see if the ELF
Note is of the type specified by the 'translate_opaque' arg.
If a matching ELF Note is found then the specfied function pointer
is called to process the ELF note.
Passing a NULL function pointer results in ELF Notes being skipped.
The first consumer of this functionality is the PVHboot support
which needs to read the XEN_ELFNOTE_PHYS32_ENTRY ELF Note while
loading the uncompressed kernel binary in order to discover the
boot entry address for the x86/HVM direct boot ABI.
Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- fix CPU wakeup on runstall changes; expose runstall as an IRQ line;
- place mini-bootloader at the BSP reset vector;
- expose CPU core frequency in XTFPGA board FPGA register;
- rearrange access to external interrupts of xtensa cores;
- add MX interrupt distributor and use it on SMP XTFPGA boards;
- add test_mmuhifi_c3 xtensa core variant;
- raise number of CPUs that can be instantiated on XTFPGA boards.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEK2eFS5jlMn3N6xfYUfnMkfg/oEQFAlxYi5QTHGpjbXZia2Jj
QGdtYWlsLmNvbQAKCRBR+cyR+D+gRCyJEACR/IQ7LVFYBczo450yLOoAPWU/8/iU
BmmeqM/BKZHBZN5HyS7zdBbDGHe/aQd+hlwG3hnxaJTfqTSOW0QxOmXkI2U5yQrl
SfGErboON0FnDreQuLlsRN0QQYI7pFJiwpUj5sqOYYghfbEfwmefUNzWlJr17AyC
AusLrGe3SBJuv40S78C+S7e4XlaGxPn5OwCvpvH+o8iDj9TCP7+vXV8N4fdackH+
i323F9OdNSmtKXL/lDVG2bf5eFw+koLOGPsqjdT/WIfRVg45VXd7ZFQeMZxuQrh4
8NwlQx9bxM4rbPBrUpsPDulic5udmMJvJ31CFe3YXu48skG90E3NxtOmUBGvTgMl
lpM9RzZfCZTAIfPqw0LHiQ4kaioMlAO40wtCNxqm78R5UL/FseuzNUN+eLz7qCL1
rTBKOQ5CJMFZWDkQjcwIYz54vi8QCt0jMWD4MzzIaU3Nf3Ak5uAaeEQE+b48lBvQ
0EhUzwh1Ea9An2JAyhAqlNqifs+0HsG4M5tqhVj+9IITlzbZe/zLswgYaHd5D75v
ElGoFov9Gi/GM5LxFzNRN1HwFCFWeHTt6sIHIo2oR1+mPrNhS+MJyqrnkKgIYOA/
plSJqO//iyS8wGL7c7UXVV3cixGOv7SSZDtSKFZb+sD7aML/y3DJnFTmABOl4kdt
OBYFg8+jcrma3g==
=8D60
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/xtensa/tags/20190204-xtensa' into staging
target/xtensa: SMP updates and various fixes
- fix CPU wakeup on runstall changes; expose runstall as an IRQ line;
- place mini-bootloader at the BSP reset vector;
- expose CPU core frequency in XTFPGA board FPGA register;
- rearrange access to external interrupts of xtensa cores;
- add MX interrupt distributor and use it on SMP XTFPGA boards;
- add test_mmuhifi_c3 xtensa core variant;
- raise number of CPUs that can be instantiated on XTFPGA boards.
# gpg: Signature made Mon 04 Feb 2019 18:59:32 GMT
# gpg: using RSA key 2B67854B98E5327DCDEB17D851F9CC91F83FA044
# gpg: issuer "jcmvbkbc@gmail.com"
# gpg: Good signature from "Max Filippov <filippov@cadence.com>" [unknown]
# gpg: aka "Max Filippov <max.filippov@cogentembedded.com>" [full]
# gpg: aka "Max Filippov <jcmvbkbc@gmail.com>" [full]
# Primary key fingerprint: 2B67 854B 98E5 327D CDEB 17D8 51F9 CC91 F83F A044
* remotes/xtensa/tags/20190204-xtensa:
hw/xtensa: xtfpga: raise CPU number limit
target/xtensa: add test_mmuhifi_c3 core
hw/xtensa: xtfpga: use MX PIC for SMP
target/xtensa: add MX interrupt controller
target/xtensa: expose core runstall as an IRQ line
target/xtensa: rearrange access to external interrupts
target/xtensa: drop function xtensa_timer_irq
target/xtensa: fix access to the INTERRUPT SR
hw/xtensa: xtfpga: use core frequency
hw/xtensa: xtfpga: fix bootloader placement in SMP
target/xtensa: add qemu_cpu_kick to xtensa_runstall
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
When resetting the guest we should unplug and remove all devices that
are still pending.
With this patch, the requested device will be unplugged on reboot
(S390_RESET_EXTERNAL and S390_RESET_REIPL, which reset the pcihost bridge
via qemu_devices_reset()).
This approach is similar to what's done for acpi PCI hotplug in
acpi_pcihp_reset() -> acpi_pcihp_update() ->
acpi_pcihp_update_hotplug_bus() -> acpi_pcihp_eject_slot().
s390_pci_generate_plug_event()'s will still be generated, I guess this
is not an issue. The same thing would happen right now when unplugging
a device just before starting the guest.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190130155733.32742-7-david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
We decided to always create the PCI host bridge, even if 'zpci' is not
enabled (due to migration compatibility). This however right now allows
to add zPCI/PCI devices to a VM although the guest will never actually see
them, confusing people that are using a simple CPU model that has no
'zpci' enabled - "Why isn't this working" (David Hildenbrand)
Let's check for 'zpci' and at least print a warning that this will not
work as expected. We could also bail out, however that might break
existing QEMU commandlines.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190130155733.32742-4-david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
When hotplugging a PCI bridge right now to the root port, we resolve
pci_get_bus(pdev)->parent_dev, which results in a SEGFAULT. Hotplugging
really only works right now when hotplugging to another bridge.
Instead, we have to properly check if we are already at the root.
Let's cleanup the code while at it a bit and factor out updating the
subordinate bus number into a separate function. The check for
"old_nr < nr" is right now not strictly necessary, but makes it more
obvious what is actually going on.
Most probably fixing up the topology is not our responsibility when
hotplugging. The guest has to sort this out. But let's keep it for now
and only fix current code to not crash.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190130155733.32742-3-david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
The primary bus number corresponds always to the bus number of the
bus the bridge is attached to.
Right now, if we have two bridges attached to the same bus (e.g. root
bus) this is however not the case. The first bridge will have primary
bus 0, the second bridge primary bus 1, which is wrong. Fix the assignment.
While at it, drop setting the PCI_SUBORDINATE_BUS temporarily to 0xff.
Setting it temporarily to that value (as discussed e.g. in [1]), is
only relevant for a running system that probes the buses. The value is
effectively unused for us just doing a DFS.
Also add a comment why we have to reassign during every reset (which I
found to be surprising.
Please note that hotplugging of bridges is in general still broken, will
be fixed next.
[1] http://www.science.unitn.it/~fiorella/guidelinux/tlk/node76.html
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190130155733.32742-2-david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
We currently don't migrate any state for zpci devices, which are
coupled with standard pci devices. This means funny things happen
when we e.g. try to migrate with a virtio-pci device but the s390x-
specific zpci state is not migrated (vfio-pci is not affected, as
it is not migratable anyway.)
Until this is fixed, mark zpci devices as unmigratable.
Reported-by: David Hildenbrand <david@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Let's handle it similar to x86 ACPI PCI code and don't use a timer.
Instead, remember if an unplug request is pending and keep it pending
for eternity. (a follow up patch will process the request on
reboot).
We expect that a guest that is up and running, will process the unplug
request and trigger the unplug. This is normal operation, no timer needed.
If the guest does not react, this usually means something in the guest
is going wrong. Simply removing the device after 30 seconds does not
really sound like a good idea. It might sometimes be wanted, but I
consider this rather an "opt-in" decision as it might harm a guest not
prepared for it.
If we ever actually want a "forced/surprise removal", we will have to
implement something on top of the existing "device_del" framework. E.g.
also x86 might want to do a forced/surprise removal of PCI devices under
some conditions. "device_del X, forced=true" could be an option and will
require changes to the hotplug handler infrastructure.
This will then move the responsibility on when to do a forced removal
to a higher level. Doing a forced removal right now over-complicates
things and doesn't really seem to be required.
Let's allow to send multiple requests.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190130155733.32742-6-david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
PCI on s390x is really weird and how it was modeled in QEMU might not have
been the right choice. Anyhow, right now it is the case that:
- Hotplugging a PCI device will silently create a zPCI device
(if none is provided)
- Hotunplugging a zPCI device will unplug the PCI device (if any)
- Hotunplugging a PCI device will unplug also the zPCI device
As far as I can see, we can no longer change this behavior. But we
should fix it.
Both device types are handled via a single hotplug handler call. This
is problematic for various reasons:
1. Unplugging via the zPCI device allows to unplug devices that are not
hot removable. (check performed in qdev_unplug()) - bad.
2. Hotplug handler chains are not possible for the unplug case. In the
future, the machine might want to override hotplug handlers, to
process device specific stuff and to then branch off to the actual
hotplug handler. We need separate hotplug handler calls for both the
PCI and zPCI device to make this work reliably. All other PCI
implementations are already prepared to handle this correctly, only
s390x is missing.
Therefore, introduce the unplug_request handler and properly perform
unplug checks by redirecting to the separate unplug_request handlers.
When finally unplugging, perform two separate hotplug_handler_unplug()
calls, first for the PCI device, followed by the zPCI device. This now
nicely splits unplugging paths for both devices.
The redirect part is a little hairy, as the user is allowed to trigger
unplug either via the PCI or the zPCI device. So redirect always to the
PCI unplug request handler first and remember if that check has been
performed in the zPCI device. Redirect then to the zPCI device unplug
request handler to perform the magic. Remembering that we already
checked the PCI device breaks the redirect loop.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190130155733.32742-5-david@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Some frontend drivers will handle dynamic resizing of PV disks, so set up
the BlockDevOps resize_cb() method during xen_block_realize() to allow
this to be done.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
There is a flaw in the xen-bus state model. To allow a frontend to re-
connect the backend state of an online XenDevice is transitioned from
Closed to InitWait, but this is currently done unilaterally which is
incorrect. The backend state should remain Closed until the frontend state
transitions to Initialising.
This patch removes the automatic backend state transition from
xen_device_backend_state_changed() and, instead, adds an extra check in
xen_device_frontend_state_changed() to determine whether a frontend is
trying to re-connect to a previously Closed XenDevice. Only if this is
found to be the case is the backend state transitioned from Closed to
InitWait. Note that this transition will be common amongst all XenDevice
classes and hence xen_device_frontend_state_changed() returns immediately
afterwards without calling into the XenDeviceClass frontend_changed()
method.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
These files don't use anything from m48t59.h, so no need to include
this header here.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
reg->phys_hi and assigned->phys_hi are big endian but we do an extra
byteswap anyway when copying reg->phys_hi to assigned->phys_hi.
To make things slightly more messy, we also add a relocatable bit (b_n())
although in the right endianness.
This fixes endianness of assigned->phys_hi.
This is unlikely to produce any visible difference though as we should end up
there only in the case of PCI hotplug and even then I am not sure if
(d->io_regions[i].addr == PCI_BAR_UNMAPPED) == true.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The cirrus VGA card has been enabled in the PPC builds with
commit 29f9cef39e ("ppc: Include vga cirrus card into
the compiling process") last year. It also works on the pseries
machine, even SLOF contains support for this card, so we can
also support this for the "-vga" parameter here.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
spapr_load_rtas() handles now RTAS address and size information in the FDT
so drop them from spapr_build_fdt().
While we are here, fix a small typo.
Fixes: 3f5dabceba "pseries: Consolidate construction of /rtas device tree node"
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Currently, it is not possible to build a QEMU binary without the
ppc405_uc.c file, even if you do not want to have the embedded machines
in the binary. This is bad since it's quite a bit of code and this code
pulls in some more dependencies (e.g. via the usage of serial_mm_init())
which would not be needed otherwise - especially with the upcoming
Kconfig-style configuration system for QEMU.
The only functions from this file which are really always required for
linking are the ppc40x_*reset() functions, so move these functions to
ppc.c, close to the ppc40x_set_irq() function that calls them. Now we
can flag ppc405_uc.c and ppc4xx_devs.c with the CONFIG_PPC4XX config
switch, too.
And while we're at it, replace the printf()s in these ppc40x_*reset()
functions with proper calls to qemu_log_mask().
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Next step is to remove them from under the PowerPCCPU
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Include the interrupt presenter under the machine_data as we plan to
remove it from under PowerPCCPU
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
It provides a mean to retrieve the XiveTCTX of a CPU. This will become
necessary with future changes which move the interrupt presenter
object pointers under the PowerPCCPU machine_data.
The PowerNV machine has an extra requirement on TIMA accesses that
this new method addresses. The machine can perform indirect loads and
stores on the TIMA on behalf of another CPU. The PIR being defined in
the controller registers, we need a way to peek in the controller
model to find the PIR value.
The XiveTCTX is moved above the XiveRouter definition to avoid forward
typedef declarations.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
While looking at the s390x implementation, looks like spapr has a
similar BUG when building the topology.
The primary bus number corresponds always to the bus number of the
bus the bridge is attached to.
Right now, if we have two bridges attached to the same bus (e.g. root
bus) this is however not the case. The first bridge will have primary
bus 0, the second bridge primary bus 1, which is wrong. Fix the assignment.
While at it, drop setting the PCI_SUBORDINATE_BUS temporarily to 0xff.
Setting it temporarily to that value (as discussed e.g. in [1]), is
only relevant for a running system that probes the buses. The value is
effectively unused for us just doing a DFS.
[1] http://www.science.unitn.it/~fiorella/guidelinux/tlk/node76.html
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Machine types 3.0 and older only know about the legacy XICS backend.
Make it clear by erroring out if the user tries to set ic-mode on
such machines.
Signed-off-by: Greg Kurz <groug@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
In hw/scsi/spapr_vio.c we declare that the controller supports multiple
buses by specifying "max_channel = 7" there. So in the code that fixes
up the device tree nodes, we must encode the channel number (a.k.a. bus
number in the "Logical unit addressing format" table of SAM5) into the
64-bit LUN, too.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1663160
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
commit efe2add7cb ("spapr/vio: deprecate the "irq" property") was
merged in QEMU version 3.0. The "irq" property" can be removed for
QEMU version 4.0.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
When reading base register of RAM slot with no RAM we should not try
to calculate register value because that will result printing an error
due to invalid RAM size. Just return 0 without the error in this case.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fix the encoding of larger memory modules in the SoC registers which
allows specifying more than 1GB memory for sam460ex. Well, only 2GB
due to SoC and firmware restrictions which was the only missing value
compared to what the real hardware supports. The SoC should support up
to 4GB but when setting that the firmware hangs during memory test.
This may be an overflow bug in the firmware which I did not try to
debug but this may affect real hardware as well.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The sdram_set_bcr() function in ppc440_uc.c takes a pointer into an
array then calculates its index from that. It's simpler and easier to
just pass the index which simplifies both the function and its callers.
Do similar cleanup in ppc4xx_devs.c to similar function.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There's already a struct with the same name in ppc4xx_devs.c. They are
not used outside their files so don't clash but they are also not
identical so rename the ppc440 specific one to distinguish them.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
To avoid overflow if larger values are added later use ram_addr_t for
the sdram_bank_sizes parameter to match ram_size to which it is compared.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Get rid of code from MIPS Malta board used to create SPD EEPROM data
(parts of which was not even needed for sam460ex) and use the generic
spd_data_generate() function to simplify this.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
There are several boards with SPD EEPROMs that are now using
duplicated or slightly different hard coded data. Add a helper to
generate SPD data for a memory module of given type and size that
could be used by these boards (either as is or with further changes if
needed) which should help cleaning this up and avoid further duplication.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
The virtqueue_pop() and virtqueue_get_avail_bytes() routines can use the
INDIRECT table to get the data. It is possible to create a packet which
will lead to the assert message like:
include/exec/memory.h:1995: void
address_space_read_cached(MemoryRegionCache *, hwaddr, void *, int):
Assertion `addr < cache->len && len <= cache->len - addr' failed.
Aborted
To do it the first descriptor should have a link to the INDIRECT table
and set the size of it to 0. It doesn't look good that the guest should
be able to trigger the assert in qemu. Add additional check for the size
of the INDIRECT table, which should not be 0.
Signed-off-by: Dima Stepanov <dimastep@yandex-team.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
- vmdk: Support for blockdev-create
- block: Apply auto-read-only for ro-whitelist drivers
- virtio-scsi: Fixes related to attaching/detaching iothreads
- scsi-disk: Fixed erroneously detected multipath setup with multiple
disks created with node-names. Added device_id property.
- block: Fix hangs in synchronous APIs with iothreads
- block: Fix invalidate_cache error path for parent activation
- block-backend, mirror, qcow2, vpc, vdi, qemu-iotests:
Minor fixes and code improvements
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcVGReAAoJEH8JsnLIjy/WyXAQAMYGNa5sBndKTsRWvNfwn8p8
GwiLrmhHreEGQrEoMrBl4O2uVq7B37j6yWRYeP5ZNboex/eLGgk8tnM6BxlIBldb
ffi9g7o7cLPOFuJxGvJMR6q38TG7yEr4Mp/QkI6hZRq3brAwBsQaVmBCtgGsOaW6
UBayRY5K/yfTdt21bZZd/78UwRz60v5YHUQYjbq5CBWeJv5WLlgwC+8k0cIeUl1f
l/dNB21ZyVxBHpZRlqonJ0YyvW6JxMQ/93btVBwFS+D60Y0jUvlExtnEbMojozfp
fcEPicByjRFK/jUUkXVlC0BJnBjhPNo2pMWgbMvCvOCMvMYT5JuKTXsdljs1Y2Gs
UHJePa8GLp1Z1ZvMQOWRFb7NpTdGlbTv7FgngY6bkSLZuQ15Dc/OGpBpnYxq3y+j
u7JbZJ+00ivygw51GwsQhu1pcgasOFxG2PJtV797+imtKnMk69wixAu25aC64sz5
1LEiLNrnJqBhxy5k4OJSOFPH/UEzP4lcH6wjH8VMz7yvIUfMG1hqk040b7bWzRCQ
c5ZRhvI530LGAgXRMlUmP4d7RUvzz3HFA5qA1DuGmnhA+qn3MGzvWHOurM98SDrL
yzNXoaMt8pqQ8RgSbB6cNmRcV7anr+VES8tbffo+tbLMM7GcKYvgsioXfI8t6d+m
Eahd3giMhdIXgEQ2LCkV
=oaAn
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches:
- vmdk: Support for blockdev-create
- block: Apply auto-read-only for ro-whitelist drivers
- virtio-scsi: Fixes related to attaching/detaching iothreads
- scsi-disk: Fixed erroneously detected multipath setup with multiple
disks created with node-names. Added device_id property.
- block: Fix hangs in synchronous APIs with iothreads
- block: Fix invalidate_cache error path for parent activation
- block-backend, mirror, qcow2, vpc, vdi, qemu-iotests:
Minor fixes and code improvements
# gpg: Signature made Fri 01 Feb 2019 15:23:10 GMT
# gpg: using RSA key 7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* remotes/kevin/tags/for-upstream: (27 commits)
scsi-disk: Add device_id property
scsi-disk: Don't use empty string as device id
qtest.py: Wait for the result of qtest commands
block: Fix invalidate_cache error path for parent activation
iotests/236: fix transaction kwarg order
iotests: Filter second BLOCK_JOB_ERROR from 229
virtio-scsi: Forbid devices with different iothreads sharing a blockdev
scsi-disk: Acquire the AioContext in scsi_*_realize()
virtio-scsi: Move BlockBackend back to the main AioContext on unplug
block: Eliminate the S_1KiB, S_2KiB, ... macros
block: Remove blk_attach_dev_legacy() / legacy_dev code
block: Apply auto-read-only for ro-whitelist drivers
uuid: Make qemu_uuid_bswap() take and return a QemuUUID
block/vdi: Don't take address of fields in packed structs
block/vpc: Don't take address of fields in packed structs
vmdk: Reject excess extents in blockdev-create
iotests: Add VMDK tests for blockdev-create
iotests: Filter cid numbers in VMDK extent info
vmdk: Implement .bdrv_co_create callback
vmdk: Refactor vmdk_create_extent
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The nRF51 contains three regions of non-volatile memory (NVM):
- CODE (R/W): contains code
- FICR (R): Factory information like code size, chip id etc.
- UICR (R/W): Changeable configuration data. Lock bits, Code
protection configuration, Bootloader address, Nordic SoftRadio
configuration, Firmware configuration.
Read and write access to the memories is managed by the
Non-volatile memory controller.
Memory schema:
[ CPU ] -+- [ NVM, either FICR, UICR or CODE ]
| |
\- [ NVMC ]
Signed-off-by: Steffen Görtz <contrib@steffen-goertz.de>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20190201023357.22596-2-stefanha@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Until now, the set_pc logic was unclear, which raised questions about
whether it should be used directly, applying a value to PC or adding
additional checks, for example, set the Thumb bit in Arm cpu. Let's set
the set_pc logic for “Configure the PC, as was done in the ELF file”
and implement synchronize_with_tb hook for preserving PC to cpu_tb_exec.
Signed-off-by: Julia Suvorova <jusual@mail.ru>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20190129121817.7109-1-jusual@mail.ru
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add a model of the MPS2 FPGA image described in Application Note
AN521. This is identical to the AN505 image, except that it uses
the SSE-200 rather than the IoTKit and so has two Cortex-M33 CPUs.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-24-peter.maydell@linaro.org
In preparation for adding support for the AN521 MPS2 image, we need
to handle wiring up the MPS2 device interrupt lines to both CPUs in
the SSE-200, rather than just the one that the IoTKit has.
Abstract out a "connect to the IoTKit interrupt line" function
and make it connect to a splitter which feeds both sets of inputs
for the SSE-200 case.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-23-peter.maydell@linaro.org
Add a model of the SSE-200, now we have put in all
the code that lets us make it different from the IoTKit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-22-peter.maydell@linaro.org
Instantiate a copy of the CPU_IDENTITY register block for each CPU
in an SSE-200.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-21-peter.maydell@linaro.org
The SSE-200 has a CPU_IDENTITY register block, which is a set of
read-only registers. As well as the usual PID/CID registers, there
is a single CPUID register which indicates whether the CPU is CPU 0
or CPU 1. Implement a model of this register block.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-20-peter.maydell@linaro.org
The SSE-200 has a "CPU local security control" register bank; add an
unimplemented-device stub for it. (The register bank has only one
interesting register, which allows the guest to lock down changes
to various CPU registers so they cannot be modified further. We
don't support that in our Cortex-M33 model anyway.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-19-peter.maydell@linaro.org
The SSE-200 gives each CPU a register bank to use to control its
L1 instruction cache. Put in an unimplemented-device stub for this.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-18-peter.maydell@linaro.org
Add unimplemented-device stubs for the various Power Policy Unit
devices that the SSE-200 has.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-17-peter.maydell@linaro.org
The SSE-200 has two Message Handling Units (MHUs), which sit behind
the APB PPC0. Wire up some unimplemented-device stubs for these,
since we don't yet implement a real model of this device.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-16-peter.maydell@linaro.org
The SYS_VERSION and SYS_CONFIG register values differ between the
IoTKit and SSE-200. Make them configurable via QOM properties rather
than hard-coded, and set them appropriately in the ARMSSE code that
instantiates the IOTKIT_SYSINFO device.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-15-peter.maydell@linaro.org
Create a cluster object to hold each CPU in the SSE. They are
logically distinct and may be configured differently (for instance
one may not have an FPU where the other does).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-14-peter.maydell@linaro.org
Give each CPU its own container memory region. This is necessary
for two reasons:
* some devices are instantiated one per CPU and the CPU sees only
its own device
* since a memory region can only be put into one container, we must
give each armv7m object a different MemoryRegion as its 'memory'
property, or a dual-CPU configuration will assert on realize when
the second armv7m object tries to put the MR into a container when
it is already in the first armv7m object's container
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-13-peter.maydell@linaro.org
The SSE-200 has two Cortex-M33 CPUs. These see the same view
of memory, with the exception of the "private CPU region" which
has per-CPU devices. Internal device interrupts for SSE-200
devices are mostly wired up to both CPUs, with the exception of
a few per-CPU devices. External GPIO inputs on the SSE-200
device are provided for the second CPU's interrupts above 32,
as is already the case for the first CPU.
Refactor the code to support creation of multiple CPUs.
For the moment we leave all CPUs with the same view of
memory: this will not work in the multiple-CPU case, but
we will fix this in the following commit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-12-peter.maydell@linaro.org
For the IoTKit the SRAM bank size is always 32K (15 bits); for the
SSE-200 this is a configurable parameter, which defaults to 32K but
can be changed when it is built into a particular SoC. For instance
the Musca-B1 board sets it to 128K (17 bits).
Make the bank size a QOM property. We follow the SSE-200 hardware in
naming the parameter SRAM_ADDR_WIDTH, which specifies the number of
address bits of a single SRAM bank.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-11-peter.maydell@linaro.org
The SSE-200 has four banks of SRAM, each with its own
Memory Protection Controller, where the IoTKit has only one.
Make the number of SRAM banks a field in ARMSSEInfo.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-10-peter.maydell@linaro.org
The SSE-200 has 4 banks of SRAM, each with its own internal
Memory Protection Controller. The interrupt status for these
extra MPCs appears in the same security controller SECMPCINTSTATUS
register as the MPC for the IoTKit's single SRAM bank. Enhance the
iotkit-secctl device to allow 4 MPCs. (If the particular IoTKit/SSE
variant in use does not have all 4 MPCs then the unused inputs will
simply result in the SECMPCINTSTATUS bits being zero as required.)
The hardcoded constant "1"s in armsse.c indicate the actual number
of SRAM MPCs the IoTKit has, and will be replaced in the following
commit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-9-peter.maydell@linaro.org
Rename the files that used to be iotkit.[ch] to
armsse.[ch] to reflect the fact they new cover
multiple Arm subsystems for embedded.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-8-peter.maydell@linaro.org
Rename various internal uses of 'iotkit' in hw/arm/iotkit.c to
'armsse', for consistency. The remaining occurences are:
* related to the devices TYPE_IOTKIT_SYSCTL, TYPE_IOTKIT_SYSINFO,
etc, which this refactor is not touching
* references that apply specifically to the IoTKit (like
the lack of a private CPU region)
* the vmstate, which keeps its old "iotkit" name for
migration compatibility reasons
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-7-peter.maydell@linaro.org
The Arm SSE-200 Subsystem for Embedded is a revised and
extended version of the older IoTKit SoC. Prepare for
adding a model of it by refactoring the IoTKit code into
an abstract base class which contains the functionality,
driven by a class data block specific to each subclass.
(This is the same approach used by the existing bcm283x
SoC family implementation.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-6-peter.maydell@linaro.org
The Arm IoTKit was effectively the forerunner of a series of
subsystems for embedded SoCs, named the SSE-050, SSE-100 and SSE-200:
https://developer.arm.com/products/system-design/subsystems
These are generally quite similar, though later iterations have
extra devices that earlier ones do not.
We want to add a model of the SSE-200, which means refactoring the
IoTKit code into an abstract base class and subclasses (using the
same design that the bcm283x SoC and Aspeed SoC family
implementations do). As a first step, rename the IoTKit struct and
QOM macros to ARMSSE, which is what we're going to name the base
class. We temporarily retain TYPE_IOTKIT to avoid changing the
code that instantiates a TYPE_IOTKIT device here and then changing
it back again when it is re-introduced as a subclass.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-5-peter.maydell@linaro.org
Expose "start-powered-off" as a property of the ARMv7M container,
which we just pass through to the CPU object in the same way that we
do for "init-svtor" and "idau". (We want this for the SSE-200, which
powers up only the first CPU at reset and leaves the second powered
down.)
As with the other CPU properties here, we can't just use alias
properties, because the CPU QOM object is not created until armv7m
realize time.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-4-peter.maydell@linaro.org
Rather than just creating the CPUs with object_new, make them child
objects of the armv7m container. This will allow the cluster code to
find the CPUs if an armv7m object is made a child of a cluster object.
object_new_with_props() will do the parenting for us.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-3-peter.maydell@linaro.org
Currently the ARMv7M NVIC object's realize method assumes that the
CPU the NVIC is attached to is CPU 0, because it thinks there can
only ever be one CPU in the system. To allow a dual-Cortex-M33
setup we need to remove this assumption; instead the armv7m
wrapper object tells the NVIC its CPU, in the same way that it
already tells the CPU what the NVIC is.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20190121185118.18550-2-peter.maydell@linaro.org
set object owner in memory_region_init_ram() instead
of NULL.
Signed-off-by: kumar sourav <sourav.jb1988@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20190125155630.17430-1-sourav.jb1988@gmail.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The new device_id property specifies which value to use for the vendor
specific designator in the Device Identification VPD page.
In particular, this is necessary for libvirt to maintain guest ABI
compatibility when no serial number is given and a VM is switched from
-drive (where the BlockBackend name is used) to -blockdev (where the
vendor specific designator is left out by default).
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
scsi-disk includes in the Device Identification VPD page, depending on
configuration amongst others, a vendor specific designator that consists
either of the serial number if given or the BlockBackend name (which is
a host detail that better shouldn't have been leaked to the guest, but
now we have to maintain it for compatibility).
With anonymous BlockBackends, i.e. scsi-disk devices constructed with
drive=<node-name>, and no serial number explicitly specified, this ends
up as an empty string. If this happens to more than one disk, we have
accidentally signalled to the OS that this is a multipath setup, which
is obviously not what was intended.
Instead of using an empty string for the vendor specific designator,
simply leave out that designator, which makes Linux detect such setups
as separate disks again.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This patch forbids attaching a disk to a SCSI device if its using a
different AioContext. Test case included.
Signed-off-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This fixes a crash when attaching two disks with the same blockdev to
a SCSI device that is using iothreads. Test case included.
Signed-off-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
This fixes a crash when attaching a disk to a SCSI device using
iothreads, then detaching it and reattaching it again. Test case
included.
Signed-off-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Currently qemu_uuid_bswap() takes a pointer to the QemuUUID to
be byte-swapped. This means it can't be used when the UUID
to be swapped is in a packed member of a struct. It's also
out of line with the general bswap*() functions we provide
in bswap.h, which take the value to be swapped and return it.
Make qemu_uuid_bswap() take a QemuUUID and return the swapped version.
This fixes some clang warnings about taking the address of
a packed struct member in block/vdi.c.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Move the complexity of milkymist_tmu2_create() into the
source file. Doing so we avoid to include the X11/OpenGL
headers in all LM32 devices, and we also avoid the duplicate
declaration of glx_fbconfig_attr[] (it is already declared
in hw/display/milkymist-tmu2.c).
Since TYPE_MILKYMIST_TMU2 is now accessible, use it.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190130120005.23123-5-philmd@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The TMU device requires both X11 and OpenGL.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190130120005.23123-4-philmd@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The Milkymist specific hardware is only used by the LM32 target,
it is pointless to compile those objects in other targets.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190130120005.23123-2-philmd@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
- New debugging QMP command to explore block graphs
- Converted DPRINTF()s to trace events
- Fixed qemu-io's use of getopt() for systems with optreset
- Minor NVMe emulation fixes
- An iotest fix
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcUkaiAAoJEPQH2wBh1c9AHsEIAIU0+FNjtdz7lNgyeBCSFCFa
/qWNk4+w6QBfhTTx/N0hGwh5/FvNYQhby8VHtZitE4/QcLbJwHYgWf14pwce3tP3
3qNB87AdQpKMpbajQM2x2Xy8lnlPeM7fe21Q/12vuX7AlEDT3gH+W9rg94bw2oFN
r+xBk6H5F2aVElw3CwMM7eary4+dPnnCQwAnoqM+g5hdpL+0scrIyARGw7v0hmSn
LDWESCM4a55lEYmwj1wS3J3uj6Fj00yzBvcEuCcT1GO+lXlV8/ciO9r2HqxVKwgz
4GAi/BERoMKjfn+/77/yI5flprPx2voNGgkyBY4C3z9ncnN6u02QBZSusBIWpSg=
=Kt4r
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/xanclic/tags/pull-block-2019-01-31' into staging
Block patches:
- New debugging QMP command to explore block graphs
- Converted DPRINTF()s to trace events
- Fixed qemu-io's use of getopt() for systems with optreset
- Minor NVMe emulation fixes
- An iotest fix
# gpg: Signature made Thu 31 Jan 2019 00:51:46 GMT
# gpg: using RSA key F407DB0061D5CF40
# gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full]
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/xanclic/tags/pull-block-2019-01-31:
iotests: Allow 147 to be run concurrently
iotests: Bind qemu-nbd to localhost in 147
iotests.py: Add qemu_nbd_pipe()
nvme: use pci_dev directly in nvme_realize
nvme: ensure the num_queues is not zero
nvme: use TYPE_NVME instead of constant string
qemu-io: Add generic function for reinitializing optind.
block/sheepdog: Convert from DPRINTF() macro to trace events
block/file-posix: Convert from DPRINTF() macro to trace events
block/curl: Convert from DPRINTF() macro to trace events
block/ssh: Convert from DPRINTF() macro to trace events
scripts: add render_block_graph function for QEMUMachine
qapi: add x-debug-query-block-graph
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
- code clean-up
- LGPL information clean-up
- fix typo (acpi)
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJcUaTuAAoJEPMMOL0/L748/ZMP/AwJM0P7AjFSuPxC5ETNK2Nn
kJSMOMhAYs4oZppwQ25tphHNFd7xEzQd1JBS5aT4svp5qN0kzoUoPY6IpxvfXueW
aFmXJPgCZvWPvD8xebHYPiH1wr0ITeRKDjZBV+YykCwIOiigg5RraMslon+Djf2f
WNB7L/abhb4eTf5vNvS7cpCLOSXbslYYtj4Z5WcSARRAFlvBzHczooiYMuovMhtP
zCOhG7tW9scqoEJyIW2Bxmw4QqHAuOtrDnqN3DHseM1Eh4PoJCNLVf4lTU8qWhF4
W8IGysjQQot2V2JIkD9XkNcfGlQNniwNj/vYhpKCDLACE65ztZ42DV7j+oe2SDB2
ljqTc2Vi4pmqEuIGcT3MykBKdsjdLOS3KBP3S6fgMV7/R347xeRf85bGcZQb/AnS
rsL5MLA4nkd0xdztpuvHcqJdxhk+SbwsY8Zlj4agSELhFuIuEKz4VLd/WrxQvAhp
yimX2+m7dHvIsHWpRduZ8I5nR2U0O+sxmIhPbaQNCcHTU/JZjtZEKxU0kpCHkBtd
AdMVXf8NMGe8NecY8n9Y80Veencpq+nCthGtRRJwWOptlXXYdR5aYHaX6IlJaVFV
jmVZITn1HxddPsVqGW0ZAJip78xVi8eYHiMvQO4+dfECLAH6m7TyLRKh8MyIyCHD
VJ6roxeKSgosPaw1tzc2
=1OOM
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/vivier2/tags/trivial-branch-pull-request' into staging
- add device category (edu, i8042, sd memory card)
- code clean-up
- LGPL information clean-up
- fix typo (acpi)
# gpg: Signature made Wed 30 Jan 2019 13:21:50 GMT
# gpg: using RSA key F30C38BD3F2FBE3C
# gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full]
# gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full]
# gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full]
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C
* remotes/vivier2/tags/trivial-branch-pull-request:
virtio-blk: remove duplicate definition of VirtIOBlock *s pointer
hw/block: clean up stale xen_disk trace entries
target/m68k: Fix LGPL information in the file headers
target/s390x: Fix LGPL version in the file header comments
tcg: Fix LGPL version number
target/tricore: Fix LGPL version number
target/openrisc: Fix LGPL version number
COPYING.LIB: Synchronize the LGPL 2.1 with the version from gnu.org
Don't talk about the LGPL if the file is licensed under the GPL
hw: sd: set category of the sd memory card
hw: input: set category of the i8042 device
typo: apci->acpi
hw: edu: set category of the edu device
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
User-visible changes:
* The new qemu-trace-stap script makes it convenient to collect traces without
writing SystemTap scripts. See "man qemu-trace-stap" for details.
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcURdlAAoJEJykq7OBq3PIPqAH/iSkYDDeWLQy4eqeTPpbsxd4
U6mUYC/m2g1bevj1TxdFmr2g5LReGTd4w35w6/SUaLMHsu701T7gK+0z1gP2/N/D
qzJiM9xxF6xYq1P4hWJGf+XsbJ0OVf7oRwn1j8qXVBxjIxERX98z0ZUtbk/aulGi
wnNXycBufpKGk2PkQC+pBfhU2775dMqpUV49z9mqyVzsiZQlzbx8WMDQj1Ic1fbe
ZcAvX5D350HJjB3Z+9wJ1V2pC9Gu+z3TIup+YR1Bkch0ywyTCVTqcepoOXwzQamm
84bifPdObBm7SbbwtrwoVKYLrdIrbb3PTWaOlWVUKruKIIf8hzn5BxC3wChb2Qk=
=bex6
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' into staging
Pull request
User-visible changes:
* The new qemu-trace-stap script makes it convenient to collect traces without
writing SystemTap scripts. See "man qemu-trace-stap" for details.
# gpg: Signature made Wed 30 Jan 2019 03:17:57 GMT
# gpg: using RSA key 9CA4ABB381AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full]
# gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full]
# Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8
* remotes/stefanha/tags/tracing-pull-request:
trace: rerun tracetool after ./configure changes
trace: improve runstate tracing
trace: add ability to do simple printf logging via systemtap
trace: forbid use of %m in trace event format strings
trace: enforce that every trace-events file has a final newline
display: ensure qxl log_buf is a nul terminated string
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
There is no need to make another reference.
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190120055558.32984-4-liq3ea@163.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
When it is zero, it causes segv.
Using following command:
"-drive file=//home/test/test1.img,if=none,id=id0
-device nvme,drive=id0,serial=test,num_queues=0"
causes following Backtrack:
Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9735700 (LWP 30952)]
0x0000555555a7a77c in nvme_start_ctrl (n=0x5555577473f0) at hw/block/nvme.c:825
825 if (unlikely(n->cq[0])) {
(gdb) bt
0 0x0000555555a7a77c in nvme_start_ctrl (n=0x5555577473f0)
at hw/block/nvme.c:825
1 0x0000555555a7af7f in nvme_write_bar (n=0x5555577473f0, offset=20,
data=4587521, size=4) at hw/block/nvme.c:969
2 0x0000555555a7b81a in nvme_mmio_write (opaque=0x5555577473f0, addr=20,
data=4587521, size=4) at hw/block/nvme.c:1163
3 0x0000555555869236 in memory_region_write_accessor (mr=0x555557747cd0,
addr=20, value=0x7fffe97320f8, size=4, shift=0, mask=4294967295, attrs=...)
at /home/test/qemu1/qemu/memory.c:502
4 0x0000555555869446 in access_with_adjusted_size (addr=20,
value=0x7fffe97320f8, size=4, access_size_min=2, access_size_max=8,
access_fn=0x55555586914d <memory_region_write_accessor>,
mr=0x555557747cd0, attrs=...) at /home/test/qemu1/qemu/memory.c:568
5 0x000055555586c479 in memory_region_dispatch_write (mr=0x555557747cd0,
addr=20, data=4587521, size=4, attrs=...)
at /home/test/qemu1/qemu/memory.c:1499
6 0x00005555558030af in flatview_write_continue (fv=0x7fffe0061130,
addr=4273930260, attrs=..., buf=0x7ffff7ff0028 "\001", len=4, addr1=20,
l=4, mr=0x555557747cd0) at /home/test/qemu1/qemu/exec.c:3234
7 0x00005555558031f9 in flatview_write (fv=0x7fffe0061130, addr=4273930260,
attrs=..., buf=0x7ffff7ff0028 "\001", len=4)
at /home/test/qemu1/qemu/exec.c:3273
8 0x00005555558034ff in address_space_write (
---Type <return> to continue, or q <return> to quit---
as=0x555556758480 <address_space_memory>, addr=4273930260, attrs=...,
buf=0x7ffff7ff0028 "\001", len=4) at /home/test/qemu1/qemu/exec.c:3363
9 0x0000555555803550 in address_space_rw (
as=0x555556758480 <address_space_memory>, addr=4273930260, attrs=...,
buf=0x7ffff7ff0028 "\001", len=4, is_write=true)
at /home/test/qemu1/qemu/exec.c:3374
10 0x00005555558884a1 in kvm_cpu_exec (cpu=0x555556920e40)
at /home/test/qemu1/qemu/accel/kvm/kvm-all.c:2031
11 0x000055555584cd9d in qemu_kvm_cpu_thread_fn (arg=0x555556920e40)
at /home/test/qemu1/qemu/cpus.c:1281
12 0x0000555555dbaf6d in qemu_thread_start (args=0x5555569438a0)
at util/qemu-thread-posix.c:502
13 0x00007ffff5dc86db in start_thread (arg=0x7fffe9735700)
at pthread_create.c:463
14 0x00007ffff5af188f in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190120055558.32984-3-liq3ea@163.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
