aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2017-07-03pci: Convert shpc_init() to ErrorMao Zhongyi3-20/+16
In order to propagate error message better, convert shpc_init() to Error also convert the pci_bridge_dev_initfn() to realize. Cc: mst@redhat.com Cc: marcel@redhat.com Cc: armbru@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Convert to realizeMao Zhongyi6-48/+52
Convert i82801b11, io3130_upstream, io3130_downstream and pcie_root_port devices to realize. Cc: mst@redhat.com Cc: marcel@redhat.com Cc: armbru@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Replace pci_add_capability2() with pci_add_capability()Mao Zhongyi6-31/+15
After the patch 'Make errp the last parameter of pci_add_capability()', pci_add_capability() and pci_add_capability2() now do exactly the same. So drop the wrapper pci_add_capability() of pci_add_capability2(), then replace the pci_add_capability2() with pci_add_capability() everywhere. Cc: pbonzini@redhat.com Cc: rth@twiddle.net Cc: ehabkost@redhat.com Cc: mst@redhat.com Cc: dmitry@daynix.com Cc: jasowang@redhat.com Cc: marcel@redhat.com Cc: alex.williamson@redhat.com Cc: armbru@redhat.com Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Make errp the last parameter of pci_add_capability()Mao Zhongyi11-41/+92
Add Error argument for pci_add_capability() to leverage the errp to pass info on errors. This way is helpful for its callers to make a better error handling when moving to 'realize'. Cc: pbonzini@redhat.com Cc: rth@twiddle.net Cc: ehabkost@redhat.com Cc: mst@redhat.com Cc: jasowang@redhat.com Cc: marcel@redhat.com Cc: alex.williamson@redhat.com Cc: armbru@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Fix the wrong assertion.Mao Zhongyi4-4/+4
pci_add_capability returns a strictly positive value on success, correct asserts. Cc: dmitry@daynix.com Cc: jasowang@redhat.com Cc: kraxel@redhat.com Cc: alex.williamson@redhat.com Cc: armbru@redhat.com Cc: marcel@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Add comment for pci_add_capability2()Mao Zhongyi1-0/+6
Comments for pci_add_capability2() to explain the return value. This may help to make a correct return value check for its callers. Cc: mst@redhat.com Cc: marcel@redhat.com Cc: armbru@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Clean up error checking in pci_add_capability()Mao Zhongyi1-5/+1
On success, pci_add_capability2() returns a positive value. On failure, it sets an error and return a negative value. pci_add_capability() laboriously checks this behavior. No other caller does. Drop the checks from pci_add_capability(). Cc: mst@redhat.com Cc: marcel@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03intel_iommu: relax iq tail check on VTD_GCMD_QIE enableLadi Prosek2-15/+20
The VT-d spec (section 6.5.2) prescribes software to zero the Invalidation Queue Tail Register before enabling the VTD_GCMD_QIE Global Command Register bit. Windows Server 2012 R2 and possibly other older Windows versions violate the protocol and set a non-zero queue tail first, which in effect makes them crash early on boot with -device intel-iommu,intremap=on. This commit relaxes the check and instead of failing to enable VTD_GCMD_QIE with vtd_err_qi_enable, it behaves as if the tail register was set just after enabling VTD_GCMD_QIE (see vtd_handle_iqt_write). Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03hw/pci-bridge/dec: Classify the DEC PCI bridge as bridge deviceThomas Huth1-0/+2
This way the bridge shows up in the correct section of the "-device help" text. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
2017-07-03virtio-net: enable configurable tx queue sizeWei Wang1-2/+30
This patch enables the virtio-net tx queue size to be configurable between 256 (the default queue size) and 1024 by the user when the vhost-user backend is used. Currently, the maximum tx queue size for other backends is 512 due to the following limitations: - QEMU backend: the QEMU backend implementation in some cases may send 1024+1 iovs to writev. - Vhost_net backend: there are possibilities that the guest sends a vring_desc of memory which crosses a MemoryRegion thereby generating more than 1024 iovs after translation from guest-physical address in the backend. Signed-off-by: Wei Wang <wei.w.wang@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-06-30Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell3-11/+13
staging # gpg: Signature made Fri 30 Jun 2017 12:46:17 BST # gpg: using RSA key 0x9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/block-pull-request: virtio-pci: use ioeventfd even when KVM is disabled tests: fix virtio-net-test ISR dependence tests: fix virtio-blk-test ISR dependence tests: fix virtio-scsi-test ISR dependence libqos: add virtio used ring support libqos: fix typo in virtio.h QVirtQueue->used comment virtio-blk: trace vdev so devices can be distinguished Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-06-30virtio-pci: use ioeventfd even when KVM is disabledStefan Hajnoczi1-1/+1
Old kvm.ko versions only supported a tiny number of ioeventfds so virtio-pci avoids ioeventfds when kvm_has_many_ioeventfds() returns 0. Do not check kvm_has_many_ioeventfds() when KVM is disabled since it always returns 0. Since commit 8c56c1a592b5092d91da8d8943c17777d6462a6f ("memory: emulate ioeventfd") it has been possible to use ioeventfds in qtest or TCG mode. This patch makes -device virtio-blk-pci,iothread=iothread0 work even when KVM is disabled. I have tested that virtio-blk-pci works under TCG both with and without iothread. This patch fixes qemu-iotests 068, which was accidentally merged early despite the dependency on ioeventfd. Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> Tested-by: Kevin Wolf <kwolf@redhat.com> Message-id: 20170628184724.21378-7-stefanha@redhat.com Message-id: 20170615163813.7255-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-06-30spapr: Clean up DRC set_isolation_state() pathDavid Gibson1-42/+103
There are substantial differences in the various paths through set_isolation_state(), both for setting to ISOLATED versus UNISOLATED state and for logical versus physical DRCs. So, split the set_isolation_state() method into isolate() and unisolate() methods, and give it different implementations for the two DRC types. Factor some minimal common checks, including for valid indicator values (which we weren't previously checking) into rtas_set_isolation_state(). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-06-30spapr: Clean up DRC set_allocation_state pathDavid Gibson1-28/+45
The allocation-state indicator should only actually be implemented for "logical" DRCs, not physical ones. Factor a check for this, and also for valid indicator state values into rtas_set_allocation_state(). Because they don't exist for physical DRCs, there's no reason that we'd ever want more than one method implementation, so it can just be a plain function. In addition, the setting to USABLE and setting to UNUSABLE paths in set_allocation_state() don't actually have much in common. So, split the method separate functions for each parameter value (drc_set_usable() and drc_set_unusable()). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-06-30spapr: Make DRC reset force DRC into known stateDavid Gibson2-34/+16
The reset handler for DRCs attempts several state transitions which are subject to various checks and restrictions. But at reset time we know there is no guest, so we can ignore most of the usual sequencing rules and just set the DRC back to a known state. In fact, it's safer to do so. The existing code also has several redundant checks for drc->awaiting_release inside a block which has already tested that. This patch removes those and sets the DRC to a fixed initial state based only on whether a device is currently plugged or not. With DRCs correctly reset to a state based on device presence, we don't need to force state transitions as cold plugged devices are processed. This allows us to remove all the callers of the set_*_state() methods from outside spapr_drc.c. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-06-30spapr: Split DRC release from DRC detachDavid Gibson1-22/+27
spapr_drc_detach() is called when qemu generic code requests a device be unplugged. It makes a number of tests, which could well delay further action until later, before actually detach the device from the DRC. This splits out the part which actually removes the device from the DRC into spapr_drc_release(). This will be useful for further cleanups. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-06-30spapr: Eliminate DRC 'signalled' state variableDavid Gibson2-54/+1
The 'signalled' field in the DRC appears to be entirely a torturous workaround for the fact that PCI devices were started in UNISOLATED state for unclear reasons. 1) 'signalled' is already meaningless for logical (so far, all non PCI) DRCs. It's always set to true (at least at any point it might be tested), and can't be assigned any real meaning due to the way signalling works for logical DRCs. 2) For PCI DRCs, the only time signalled would be false is when non-zero functions of a multifunction device are hotplugged, followed by function zero (the other way around is explicitly not permitted). In that case the secondary function DRCs are attached, but the notification isn't sent to the guest until function 0 is plugged. 3) signalled being false is used to allow a DRC detach to switch mode back to ISOLATED state, which allows a secondary function to be hotplugged then unplugged with function 0 never inserted. Without this a secondary function starting in UNISOLATED state couldn't be detached again without function 0 being inserted, all the functions configured by the guest, then sent back to ISOLATED state. 4) But now that PCI DRCs start in ISOLATED state, there's nothing to be done. If the guest doesn't get the notification, it won't switch the device to UNISOLATED state, so nothing prevents it from being unplugged. If the guest does move it to UNISOLATED state without the signal (due to a manual drmgr call, for instance) then it really isn't safe to unplug it. So, this patch removes the signalled variable and all code related to it. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-06-30spapr: Start hotplugged PCI devices in ISOLATED stateDavid Gibson1-10/+0
PCI DRCs, and only PCI DRCs, are immediately moved to UNISOLATED isolation state once the device is attached. This has been there from the initial implementation, and it's not clear why. The state diagram in PAPR 13.4 suggests PCI devices should start in ISOLATED state until the guest moves them into UNISOLATED, and the code in the guest-side drmgr tool seems to work that way too. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org>
2017-06-30target-ppc: Enable open-pic timers to count and generate interruptsAaron Larson1-6/+111
Previously QEMU open-pic implemented the 4 open-pic timers including all timer registers, but the timers did not "count" or generate any interrupts. The patch makes the timers both count and generate interrupts. The timer clock frequency is fixed at 25MHZ. -- Responding to V2 patch comments. - Simplify clock frequency logic and commentary. - Remove camelCase variables. - Timer objects now created at init rather than lazily. Signed-off-by: Aaron Larson <alarson@ddci.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30hw/ppc/spapr.c: consecutive 'spapr->patb_entry = 0' statementsDaniel Henrique Barboza1-1/+0
In ppc_spapr_reset(), if the guest is using HPT, the code was executing: } else { spapr->patb_entry = 0; spapr_setup_hpt_and_vrma(spapr); } And, at the end of spapr_setup_hpt_and_vrma: /* We're setting up a hash table, so that means we're not radix */ spapr->patb_entry = 0; Resulting in spapr->patb_entry being assigned to 0 twice in a row. Given that 'spapr_setup_hpt_and_vrma' is also called inside 'spapr_check_setup_free_hpt' of spapr_hcall.c, this trivial patch removes the 'patb_entry = 0' assignment from the 'else' clause inside ppc_spapr_reset to avoid this behavior. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30spapr: prevent QEMU crash when CPU realization failsBharata B Rao1-3/+4
ICPState objects were being allocated before CPU thread realization. However commit 9ed656631d73 (xics: setup cpu at realize time) reversed it by allocating ICPState objects after CPU thread is realized. But it didn't take care to fix the error path because of which we observe a SIGSEGV when CPU thread realization fails during cold/hotplug. Fix this by ensuring that we do object_unparent() of ICPState object only in case when is was created earlier. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30spapr: fix migration of ICPState objects from/to older QEMUGreg Kurz1-2/+86
Commit 5bc8d26de20c ("spapr: allocate the ICPState object from under sPAPRCPUCore") moved ICPState objects from the machine to CPU cores. This is an improvement since we no longer allocate ICPState objects that will never be used. But it has the side-effect of breaking migration of older machine types from older QEMU versions. This patch allows spapr to register dummy "icp/server" entries to vmstate. These entries use a dedicated VMStateDescription that can swallow and discard state of an incoming migration stream, and that don't send anything on outgoing migration. As for real ICPState objects, the instance_id is the cpu_index of the corresponding vCPU, which happens to be equal to the generated instance_id of older machine types. The machine can unregister/register these entries when CPUs are dynamically plugged/unplugged. This is only available for pseries-2.9 and older machines, thanks to a compat property. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30xics: directly register ICPState objects to vmstateGreg Kurz1-1/+4
The ICPState objects are currently registered to vmstate as qdev objects. Their instance ids are hence computed automatically in the migration code, and thus depends on the order the CPU cores were plugged. If the destination had its CPU cores plugged in a different order than the source, then ICPState objects will have different instance_ids and load the wrong state. Since CPU objects have a reliable cpu_index which is already used as instance_id in vmstate, let's use it for ICPState as well. Please note that this doesn't break migration. Older machine types used to allocate and realize all ICPState objects at machine init time, for the whole lifetime of the machine. The qdev instance ids are thus 0,1,2... nr_servers and happen to map to the vCPU indexes. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30spapr: Fix migration of Radix guestsBharata B Rao1-0/+12
Fix migration of radix guests by ensuring that we issue KVM_PPC_CONFIGURE_V3_MMU for radix case post migration. Reported-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30spapr: Add a "no HPT" encoding to HTAB migration streamBharata B Rao1-4/+25
Add a "no HPT" encoding (using value -1) to the HTAB migration stream (in the place of HPT size) when the guest doesn't allocate HPT. This will help the target side to match target HPT with the source HPT and thus enable successful migration. Suggested-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-30ppc: Rework CPU compatibility testing across migrationDavid Gibson1-1/+6
Migrating between different CPU versions is a bit complicated for ppc. A long time ago, we ensured identical CPU versions at either end by checking the PVR had the same value. However, this breaks under KVM HV, because we always have to use the host's PVR - it's not virtualized. That would mean we couldn't migrate between hosts with different PVRs, even if the CPUs are close enough to compatible in practice (sometimes identical cores with different surrounding logic have different PVRs, so this happens in practice quite often). So, we removed the PVR check, but instead checked that several flags indicating supported instructions matched. This turns out to be a bad idea, because those instruction masks are not architected information, but essentially a TCG implementation detail. So changes to qemu internal CPU modelling can break migration - this happened between qemu-2.6 and qemu-2.7. That was addressed by 146c11f1 "target-ppc: Allow eventual removal of old migration mistakes". Now, verification of CPU compatibility across a migration basically doesn't happen. We simply ignore the PVR of the incoming migration, and hope the cpu on the destination is close enough to work. Now that we've cleaned up handling of processor compatibility modes for pseries machine type, we can do better. For new machine types (pseries-2.10+) We allow migration if: * The source and destination PVRs are for the same type of CPU, as determined by CPU class's pvr_match function OR * When the source was in a compatibility mode, and the destination CPU supports the same compatibility mode For older machine types we retain the existing behaviour - current CAS code will usually set a compat mode which would break backwards migration if we made them use the new behaviour. [Fixed from an earlier version by Greg Kurz]. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Tested-by: Andrea Bolognani <abologna@redhat.com>
2017-06-30pseries: Reset CPU compatibility modeDavid Gibson2-10/+2
Currently, the CPU compatibility mode is set when the cpu is initialized, then again when the guest negotiates features. This means if a guest negotiates a compatibility mode, then reboots, that compatibility mode will be retained across the reset. Usually that will get overridden when features are negotiated on the next boot, but it's still not really correct. This patch moves the initial set up of the compatibility mode from cpu init to reset time. The mode *is* retained if the reboot was caused by the feature negotiation (it might be important in that case, though it's unlikely). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Tested-by: Andrea Bolognani <abologna@redhat.com>
2017-06-30pseries: Move CPU compatibility property to machineDavid Gibson3-7/+62
Server class POWER CPUs have a "compat" property, which is used to set the backwards compatibility mode for the processor. However, this only makes sense for machine types which don't give the guest access to hypervisor privilege - otherwise the compatibility level is under the guest's control. To reflect this, this removes the CPU 'compat' property and instead creates a 'max-cpu-compat' property on the pseries machine. Strictly speaking this breaks compatibility, but AFAIK the 'compat' option was never (directly) used with -device or device_add. The option was used with -cpu. So, to maintain compatibility, this patch adds a hack to the cpu option parsing to strip out any compat options supplied with -cpu and set them on the machine property instead of the now deprecated cpu property. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Tested-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Tested-by: Andrea Bolognani <abologna@redhat.com>
2017-06-30hw/ppc/prep: Remove superfluous call to soundhw_init()Thomas Huth1-4/+0
When using the 40p machine, soundhw_init() is currently called twice, one time from vl.c and one time from ibm_40p_init(). The call in ibm_40p_init() was likely just a copy-and-paste from a old version of the prep machine - but there the call to audio_init() (which was the previous name of this function) has been removed many years ago already, with commit b3e6d591b05538056d665572f3e3bbfb3cbb70e7 ("audio: enable PCI audio cards for all PCI-enabled targets"), so we certainly also do not need the soundhw_init() in the 40p function anymore nowadays. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Sahid Ferdjaoui <sferdjao@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-06-29Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into stagingPeter Maydell6-49/+155
- fixes a minor bug that could possibly prevent old guests to remove directories - makes default permissions for new files configurable from the cmdline when using mapped security modes - handle transport errors - g_malloc()+memcpy() converted to g_memdup() # gpg: Signature made Thu 29 Jun 2017 14:12:42 BST # gpg: using DSA key 0x02FC3AEB0101DBC2 # gpg: Good signature from "Greg Kurz <groug@kaod.org>" # gpg: aka "Greg Kurz <groug@free.fr>" # gpg: aka "Greg Kurz <gkurz@linux.vnet.ibm.com>" # gpg: aka "Gregory Kurz (Groug) <groug@free.fr>" # gpg: aka "[jpeg image of size 3330]" # 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: 2BD4 3B44 535E C0A7 9894 DBA2 02FC 3AEB 0101 DBC2 * remotes/gkurz/tags/for-upstream: 9pfs: handle transport errors in pdu_complete() xen-9pfs: disconnect if buffers are misconfigured virtio-9p: break device if buffers are misconfigured virtio-9p: message header is 7-byte long virtio-9p: record element after sanity checks 9pfs: replace g_malloc()+memcpy() with g_memdup() 9pfs: local: Add support for custom fmode/dmode in 9ps mapped security modes 9pfs: local: remove: use correct path component Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-06-29virtio-blk: trace vdev so devices can be distinguishedStefan Hajnoczi2-10/+12
It is hard to analyze trace logs with multiple virtio-blk devices because none of the trace events include the VirtIODevice *vdev. This patch adds vdev so it's clear which device a request is associated with. I considered using VirtIOBlock *s instead but VirtIODevice *vdev is more general and may be correlated with generic virtio trace events like virtio_set_status. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20170614092930.11234-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-06-299pfs: handle transport errors in pdu_complete()Greg Kurz1-8/+15
Contrary to what is written in the comment, a buggy guest can misconfigure the transport buffers and pdu_marshal() may return an error. If this ever happens, it is up to the transport layer to handle the situation (9P is transport agnostic). This fixes Coverity issue CID1348518. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-06-29xen-9pfs: disconnect if buffers are misconfiguredStefano Stabellini1-21/+64
Implement xen_9pfs_disconnect by unbinding the event channels. On xen_9pfs_free, call disconnect if any event channels haven't been disconnected. If the frontend misconfigured the buffers set the backend to "Closing" and disconnect it. Misconfigurations include requesting a read of more bytes than available on the ring buffer, or claiming to be writing more data than available on the ring buffer. Signed-off-by: Stefano Stabellini <stefano@aporeto.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-06-29virtio-9p: break device if buffers are misconfiguredGreg Kurz4-7/+40
The 9P protocol is transport agnostic: if the guest misconfigured the buffers, the best we can do is to set the broken flag on the device. Signed-off-by: Greg Kurz <groug@kaod.org>
2017-06-29virtio-9p: message header is 7-byte longGreg Kurz2-5/+8
The 9p spec at http://man.cat-v.org/plan_9/5/intro reads: "Each 9P message begins with a four-byte size field specify- ing the length in bytes of the complete message including the four bytes of the size field itself. The next byte is the message type, one of the constants in the enumeration in the include file <fcall.h>. The next two bytes are an iden- tifying tag, described below." ie, each message starts with a 7-byte long header. The core 9P code already assumes this pretty much everywhere. This patch does the following: - makes the assumption explicit in the common 9p.h header, since it isn't related to the transport - open codes the header size in handle_9p_output() and hardens the sanity check on the space needed for the reply message Signed-off-by: Greg Kurz <groug@kaod.org> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
2017-06-29virtio-9p: record element after sanity checksGreg Kurz1-1/+2
If the guest sends a malformed request, we end up with a dangling pointer in V9fsVirtioState. This doesn't seem to cause any bug, but let's remove this side effect anyway. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2017-06-299pfs: replace g_malloc()+memcpy() with g_memdup()Marc-André Lureau1-2/+1
I found these pattern via grepping the source tree. I don't have a coccinelle script for it! Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-06-299pfs: local: Add support for custom fmode/dmode in 9ps mapped security modesTobias Schramm2-4/+24
In mapped security modes, files are created with very restrictive permissions (600 for files and 700 for directories). This makes file sharing between virtual machines and users on the host rather complicated. Imagine eg. a group of users that need to access data produced by processes on a virtual machine. Giving those users access to the data will be difficult since the group access mode is always 0. This patch makes the default mode for both files and directories configurable. Existing setups that don't know about the new parameters keep using the current secure behavior. Signed-off-by: Tobias Schramm <tobleminer@gmail.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-06-299pfs: local: remove: use correct path componentBruce Rogers1-1/+1
Commit a0e640a8 introduced a path processing error. Pass fstatat the dirpath based path component instead of the entire path. Signed-off-by: Bruce Rogers <brogers@suse.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-06-29Merge remote-tracking branch 'remotes/juanquintela/tags/migration/20170628' ↵Peter Maydell22-44/+61
into staging migration/next for 20170628 # gpg: Signature made Wed 28 Jun 2017 12:16:44 BST # gpg: using RSA key 0xF487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" # 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: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * remotes/juanquintela/tags/migration/20170628: exec: fix access to ram_list.dirty_memory when sync dirty bitmap migration: add "return-path" capability vmstate: error hint for failed equal checks migration: add comment for TYPE_MIGRATE migration: hmp: dump globals migration: merge enforce_config_section somewhat migration: move skip_section_footers migration: move skip_configuration out migration: move only_migratable to MigrationState migration: move global_state.optional out migration: let MigrationState be a qdev vl: clean up global property registration accel: introduce AccelClass.global_props machine: export register_compat_prop() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-06-28vmstate: error hint for failed equal checksHalil Pasic17-20/+20
In some cases a failing VMSTATE_*_EQUAL does not mean we detected a bug, but it's actually the best we can do. Especially in these cases a verbose error message is required. Let's introduce infrastructure for specifying a error hint to be used if equal check fails. Let's do this by adding a parameter to the _EQUAL macros called _err_hint. Also change all current users to pass NULL as last parameter so nothing changes for them. Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170623144823.42936-1-pasic@linux.vnet.ibm.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-28migration: move skip_section_footersPeter Xu3-5/+5
Move it into MigrationState, revert its meaning and renaming it to send_section_footer, with a property bound to it. Same trick is played like previous patches. Removing savevm_skip_section_footers(). Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-9-git-send-email-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-28migration: move skip_configuration outPeter Xu3-3/+5
It was in SaveState but now moved to MigrationState altogether, reverted its meaning, then renamed to "send_configuration". Again, using HW_COMPAT_2_3 for old PC/SPAPR machines, and accel_register_prop() for xen_init(). Removing savevm_skip_configuration(). Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-8-git-send-email-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-28migration: move global_state.optional outPeter Xu3-3/+10
Put it into MigrationState then we can use the properties to specify whether to enable storing global state. Removing global_state_set_optional() since now we can use HW_COMPAT_2_3 for x86/power, and AccelClass.global_props for Xen. Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-6-git-send-email-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-28accel: introduce AccelClass.global_propsPeter Xu1-0/+7
Introduce this new field for the accelerator classes so that each specific accelerator in the future can register its own global properties to be used further by the system. It works just like how the old machine compatible properties do, but only tailored for accelerators. Introduce register_compat_props_array() for it. Export it so that it may be used in other codes as well in the future. Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-3-git-send-email-peterx@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-28machine: export register_compat_prop()Peter Xu2-13/+14
We have HW_COMPAT_*, however that's only bound to machines, not other things (like accelerators). Behind it, it was register_compat_prop() that played the trick. Let's export the function for further use outside HW_COMPAT_* magic. Meanwhile, move it to qdev-properties.c where seems more proper (since it'll be used not only in machine codes). Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1498536619-14548-2-git-send-email-peterx@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-06-27xen-disk: add support for multi-page shared ringsPaul Durrant1-31/+113
The blkif protocol has had provision for negotiation of multi-page shared rings for some time now and many guest OS have support in their frontend drivers. This patch makes the necessary modifications to xen-disk support a shared ring up to order 4 (i.e. 16 pages). Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-06-27xen-disk: only advertize feature-persistent if grant copy is not availablePaul Durrant1-7/+8
If grant copy is available then it will always be used in preference to persistent maps. In this case feature-persistent should not be advertized to the frontend, otherwise it may needlessly copy data into persistently granted buffers. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2017-06-27xen/disk: don't leak stack data via response ringStefano Stabellini1-13/+12
Rather than constructing a local structure instance on the stack, fill the fields directly on the shared ring, just like other (Linux) backends do. Build on the fact that all response structure flavors are actually identical (aside from alignment and padding at the end). This is XSA-216. Reported by: Anthony Perard <anthony.perard@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
2017-06-27xilinx_spips: allow mmio executionKONRAD Frederic1-19/+55
This allows to execute from the lqspi area. When the request_ptr is called the device loads 1024bytes from the SPI device. Then this code can be executed by the guest. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: KONRAD Frederic <fred.konrad@greensocs.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
generated by cgit v1.1 at 2024-07-21 23:24:39 +0000