This replaces the balloon_page() internal interface with
ballon_inflate_page(), with a slightly different interface. The new
interface will make future alterations simpler.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20190214043916.22128-4-david@gibson.dropbear.id.au>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The virtio-balloon device's verification of the address given to it by the
guest has a number of faults:
* The addresses here are guest physical addresses, which should be
'hwaddr' rather than 'ram_addr_t' (the distinction is admittedly
pretty subtle and confusing)
* We don't check for section.mr being NULL, which is the main way that
memory_region_find() reports basic failures. We really need to check
that before looking at any other section fields, because
memory_region_find() doesn't initialize them on the failure path
* We're passing a length of '1' to memory_region_find(), but really the
guest is requesting that we put the entire page into the balloon,
so it makes more sense to call it with BALLOON_PAGE_SIZE
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20190214043916.22128-3-david@gibson.dropbear.id.au>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When the balloon is inflated, we discard memory place in it using madvise()
with MADV_DONTNEED. And when we deflate it we use MADV_WILLNEED, which
sounds like it makes sense but is actually unnecessary.
The misleadingly named MADV_DONTNEED just discards the memory in question,
it doesn't set any persistent state on it in-kernel; all that's necessary
to bring the memory back is to touch it. MADV_WILLNEED in contrast
specifically says that the memory will be used soon and faults it in.
This patch simplify's the balloon operation by dropping the madvise()
on deflate. This might have an impact on performance - it will move a
delay at deflate time until that memory is actually touched, which
might be more latency sensitive. However:
* Memory that's being given back to the guest by deflating the
balloon *might* be used soon, but it equally could just sit around
in the guest's pools until needed (or even be faulted out again if
the host is under memory pressure).
* Usually, the timescale over which you'll be adjusting the balloon
is long enough that a few extra faults after deflation aren't
going to make a difference.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Message-Id: <20190214043916.22128-2-david@gibson.dropbear.id.au>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
[get|set]_addr are two counterpart to access PCDIMMDevice.addr.
Since we have already set up a property PC_DIMM_ADDR_PROP for this
field and use this mechanism in set_addr, it would be more proper to use
the same mechanism in get_addr.
This patch uses object_property_get_uint() to replace the direct memory
access to make [get|set]_addr with the same mechanism.
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Message-Id: <20190211064629.20186-1-richardw.yang@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Detect all invalid configurations (e.g. mingw32 with vhost-user,
non-Linux with vhost-kernel). As a collateral benefit, all vhost-kernel
backends can be now disabled if one wants to reduce the attack surface.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1543851204-41186-6-git-send-email-pbonzini@redhat.com>
Message-Id: <1550165756-21617-7-git-send-email-pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This shows a preexisting bug: if a KVM target did not have virtio-net enabled,
it would fail with undefined symbols when vhost was enabled. This must now
be fixed, lest targets that have no virtio-net fail to compile.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1543851204-41186-5-git-send-email-pbonzini@redhat.com>
Message-Id: <1550165756-21617-6-git-send-email-pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
vhost-user does not depend on Linux; it can run on any POSIX system. Restrict
vhost-kernel to Linux in hw/virtio/vhost-backend.c, everything else can be
compiled on all POSIX systems.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1543851204-41186-4-git-send-email-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1550165756-21617-4-git-send-email-pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/net/vhost_net.c needs functions that are declared in net/vhost-user.c: the
vhost-user code is always compiled into QEMU, only the constructor
net_init_vhost_user is unreachable. Also, net/vhost-user.c needs functions
declared in hw/virtio/vhost-stub.c even if no virtio device exists.
Break this dependency. First, add a minimal version of net/vhost-user.c,
with no functionality and no dependency on vhost code. Second, #ifdef out
the calls back to net/vhost-user.c from hw/net/vhost_net.c.
While at it, this patch fixes the CONFIG_VHOST_NET_USE*D* typo.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <1543851204-41186-3-git-send-email-pbonzini@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1550165756-21617-3-git-send-email-pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
There is no reason for CONFIG_VHOST_NET to be specific to a single target;
it is a host feature that can be add to all targets, as long as they support
the virtio-net device. Currently CONFIG_VHOST_NET depends on CONFIG_KVM,
but ioeventfd support is present in the core memory API and works with
other accelerators as well.
As a first step, move the vhost-net stubs to a separate file. Later, they
will become conditional on CONFIG_VIRTIO_NET, which is not available in .c
files.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1543851204-41186-2-git-send-email-pbonzini@redhat.com>
Message-Id: <1550165756-21617-2-git-send-email-pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@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>