aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-09-06s390x/kvm: don't enable key wrapping if msa3 is disabledDavid Hildenbrand
As the CPU model now controls msa3, trying to set wrapping keys without msa3 being around/enable in the kernel will produce misleading errors. So let's simply not configure key wrapping if msa3 is not enabled and make compat machines with disabled CPU model work correctly. Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-25-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/kvm: let the CPU model control CMM(A)David Hildenbrand
Starting with recent kernels, if the cmma attributes are available, we actually have hardware support. Enabling CMMA then means providing the guest VCPU with CMM, therefore enabling its CMM facility. Let's not blindly enable CMM anymore but let's control it using CPU models. For disabled CPU models, CMMA will continue to always get enabled. Also enable it in the applicable default models. Please note that CMM doesn't work with hugetlbfs, therefore we will warn the user and keep it disabled. Migrating from/to a hugetlbfs configuration works, as it will be disabled on both sides. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-24-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/kvm: disable host model for problematic compat machinesDavid Hildenbrand
Compatibility machines that touch runtime-instrumentation should not be used with the CPU model. Otherwise the host model will look different, depending on the QEMU machine QEMU has been started with. So let's simply disable the host model for existing compatibility machines that all disable ri. This, in return, disables the CPU model for these compat machines completely. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-23-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/kvm: implement CPU model supportDavid Hildenbrand
Let's implement our two hooks so we can support CPU models. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-22-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/kvm: allow runtime-instrumentation for "none" machineDavid Hildenbrand
To be able to query the correct host model for the "none" machine, let's allow runtime-instrumentation for that machine. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-21-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/sclp: propagate hmfaiDavid Hildenbrand
hmfai is provided on CPU models >= z196. Let's propagate it properly. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-19-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/sclp: propagate the mha via sclpDavid Hildenbrand
The mha is provided in the CPU model, so get any CPU and extract the value. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-18-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/sclp: propagate the ibc val (lowest and unblocked ibc)David Hildenbrand
If we have a lowest ibc, we can indicate the ibc to the guest. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-17-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/sclp: indicate sclp featuresDavid Hildenbrand
We have three different blocks in the SCLP read-SCP information response that indicate sclp features. Let's prepare propagation. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-16-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/sclp: introduce sclp feature blocksDavid Hildenbrand
The sclp "read cpu info" and "read scp info" commands can include features for the cpu info and configuration characteristics (extended), decribing some advanced features available in the configuration. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-15-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/sclp: factor out preparation of cpu entriesDavid Hildenbrand
Let's factor out the common code of "read cpu info" and "read scp info". This will make the introduction of new cpu entry fields easier. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-14-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: check and apply the CPU modelDavid Hildenbrand
We have to test if a configured CPU model is runnable in the current configuration, and if not report why that is the case. This is done by comparing it to the maximum supported model (host for KVM or z900 for TCG). Also, we want to do some base sanity checking for a configured CPU model. We'll cache the maximum model and the applied model (for performance reasons and because KVM can only be configured before any VCPU is created). For unavailable "host" model, we have to make sure that we inform KVM, so it can do some compatibility stuff (enable CMMA later on to be precise). Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-13-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: let the CPU model handle feature checksDavid Hildenbrand
If we have certain features enabled, we have to migrate additional state (e.g. vector registers or runtime-instrumentation registers). Let the CPU model control that unless we have no "host" CPU model in the KVM case. This will later on be the case for compatibility machines, so migration from QEMU versions without the CPU model will still work. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-12-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: expose features and feature groups as propertiesDavid Hildenbrand
Let's add all features and feature groups as properties to all CPU models. If the "host" CPU model is unknown, we can neither query nor change features. KVM will just continue to work like it did until now. We will not allow to enable features that were not part of the original CPU model, because that could collide with the IBC in KVM. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-11-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: store the CPU model in the CPU instanceDavid Hildenbrand
A CPU model consists of a CPU definition, to which delta changes are applied - features added or removed (e.g. z13-base,vx=on). In addition, certain properties (e.g. cpu id) can later on change during migration but belong into the CPU model. This data will later be filled from the host model in the KVM case. Therefore, store the configured CPU model inside the CPU instance, so we can later on perform delta changes using properties. For the "qemu" model, we emulate in TCG a z900. "host" will be uninitialized (cpu->model == NULL) unless we have CPU model support in KVM later on. The other models are all initialized from their definitions. Only the "host" model can have a cpu->model == NULL. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-10-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: register defined CPU models as subclassesDavid Hildenbrand
This patch adds the CPU model definitions that are known on s390x - like z900, zBC12 or z13. For each definition, introduce two CPU models: 1. Base model (e.g. z13-base): Minimum feature set we expect to be around on all z13 systems. These models are migration-safe and will never change. 2. Flexible models (e.g. z13): Models that can change between QEMU versions and will be extended over time as we implement further features that are already part of such a model in real hardware of certain configurations. We want to work on features using ordinary bitmap operations, however we can't initialize a bitmap statically (unsigned long[] ...). Therefore we store the generated feature lists in separate arrays and convert them to proper bitmaps before registering all our CPU model classes. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-9-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: introduce CPU feature group definitionsDavid Hildenbrand
Let's use the generated groups to create feature group representations for the user. These groups can later be used to enable/disable multiple features in one shot and will be used to reduce the amount of reported features to the user if all subfeatures are in place. We want to work on features using ordinary bitmap operations, however we can't initialize a bitmap statically (unsigned long[] ...). Therefore we store the generated feature lists in separate arrays and convert them to a proper bitmaps before they will ever be used. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-8-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: generate CPU feature group listsDavid Hildenbrand
Feature groups will be very helpful to reduce the amount of features typically available in sane configurations. E.g. the MSA facilities introduced loads of subfunctions, which could - in theory - go away in the future, but we want to avoid reporting hundrets of features to the user if usually all of them are in place. Groups only contain features that were introduced in one shot, not just random features. Therefore, groups can never change. This is an important property regarding migration. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-7-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: generate CPU feature lists for CPU modelsMichael Mueller
This patch introduces the helper "gen-features" which allows to generate feature list definitions at compile time. Its flexibility is better and the error-proneness is lower when compared to static programming time added statements. The helper includes "target-s390x/cpu_features.h" to be able to use named facility bits instead of numbers. The generated defines will be used for the definition of CPU models. We generate feature lists for each HW generation and GA for EC models. BC models are always based on a EC version and have no separate definitions. Base features: Features we expect to be always available in sane setups. Migration safe - will never change. Can be seen as "minimum features required for a CPU model". Default features: Features we expect to be stable and around in latest setups (e.g. having KVM support) - not migration safe. Max features: All supported features that are theoretically allowed for a CPU model. Exceeding these features could otherwise produce problems with IBC (instruction blocking controls) in KVM. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> [generate base, default and models. renaming and cleanup] Message-Id: <20160905085244.99980-6-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: introduce CPU featuresMichael Mueller
The patch introduces s390x CPU features (most of them refered to as facilities) along with their discription and some functions that will be helpful when working with the features later on. Please note that we don't introduce all known CPU features, only the ones currently supported by KVM + QEMU. We don't want to enable later on blindly any facilities, for which we don't know yet if we need QEMU support to properly support them (e.g. migrate additional state when active). We can update QEMU later on. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> [reworked to include non-stfle features, added definitions] Message-Id: <20160905085244.99980-5-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: expose CPU class propertiesDavid Hildenbrand
Let's expose the description and migration safety and whether a definition is static, as class properties, this can be helpful in the future. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-4-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-06s390x/cpumodel: "host" and "qemu" as CPU subclassesDavid Hildenbrand
This patch introduces two CPU models, "host" and "qemu". "qemu" is used as default when running under TCG. "host" is used as default when running under KVM. "host" cannot be used without KVM. "host" is not migration-safe. They both inherit from the base s390x CPU, which is turned into an abstract class. This patch also changes CPU creation to take care of the passed CPU string and reuses common code parse_features() function for that purpose. Unknown CPU definitions are now reported. The "-cpu ?" and "query-cpu-definition" commands are changed to list all CPU subclasses automatically, including migration-safety and whether static. Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-3-dahi@linux.vnet.ibm.com> [CH: fix up self-assignments in s390_cpu_list, as spotted by clang] Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05qmp: details about CPU definitions in query-cpu-definitionsDavid Hildenbrand
It might be of interest for tooling whether a CPU definition can be safely used when migrating, or if e.g. CPU features might get lost during migration when migrationg from/to a different QEMU version or host, even if the same compatibility machine is used. Also, we want to know if a CPU definition is static and will never change. Beause these definitions can then be used independantly of a compatibility machine and will always have the same feature set, they can e.g. be used to indicate the "host" model in libvirt later on. Let's add two return values to query-cpu-definitions, stating for each returned CPU definition, if it is migration-safe and if it is static. While "migration-safe" is optional, "static" will be set to "false" automatically by all implementing architectures. If a model really was static all the time and will be in the future, this can simply be changed later. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Message-Id: <20160905085244.99980-2-dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390x/kvm: 2 byte software breakpoint supportDavid Hildenbrand
Diag 501 (4 bytes) was used until now for software breakpoints on s390. As instructions on s390 might be 2 bytes long, temporarily overwriting them with 4 bytes is evil and can result in very strange guest behaviour. We make use of invalid instruction 0x0000 as new sw breakpoint instruction. We have to enable interception of that instruction in KVM using a capability. If no software breakpoint has been inserted at the reported position, an operation exception has to be injected into the guest. Otherwise a breakpoint has been hit and the pc has to be rewound. If KVM doesn't yet support interception of instruction 0x0000 the existing mechanism exploiting diag 501 is used. To keep overhead low, interception of instruction 0x0000 will only be enabled if sw breakpoints are really used. Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05linux-headers: updateCornelia Huck
Update headers against 4.8-rc2. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390x/css: handle cssid 255 correctlyCornelia Huck
The cssid 255 is reserved but still valid from an architectural point of view. However, feeding a bogus schid of 0xffffffff into the virtio hypercall will lead to a crash: Stack trace of thread 138363: #0 0x00000000100d168c css_find_subch (qemu-system-s390x) #1 0x00000000100d3290 virtio_ccw_hcall_notify #2 0x00000000100cbf60 s390_virtio_hypercall #3 0x000000001010ff7a handle_hypercall #4 0x0000000010079ed4 kvm_cpu_exec (qemu-system-s390x) #5 0x00000000100609b4 qemu_kvm_cpu_thread_fn #6 0x000003ff8b887bb4 start_thread (libpthread.so.0) #7 0x000003ff8b78df0a thread_start (libc.so.6) This is because the css array was only allocated for 0..254 instead of 0..255. Let's fix this by bumping MAX_CSSID to 255 and fencing off the reserved cssid of 255 during css image allocation. Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Cc: qemu-stable@nongnu.org Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390x/ioinst: advertise fcs facilityCornelia Huck
As we provide format 1 chsc scpd data (and don't support any ficon channels), we de facto already have the ficon-cascaded-switch facility. Reviewed-by: Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390x: wrap flic savevm calls into vmstateCornelia Huck
Just a simple conversion to get rid of register_savevm. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390/sclp: cache the sclp deviceChristian Borntraeger
With the current code a simple sclp command takes about 13000 ns The biggest part seems to be the resolver of the object model. By caching the sclp device the time for an sclp command goes down to 2500ns. Talking about real life scenarios, this change doubles the speed of the sclp console when sending single bytes outputs to /dev/console. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390x/pci: assert zpci always existingYi Min Zhao
If one pci device is plugged successfully, there must be a zpci device existing. This means that during hot-unplugging a pci device, its corresponding zpci device must be found. Therefore we use an assert to replace current code. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390x/pci: return directly if create zpci failedYi Min Zhao
In the case that zpci is automatically created, we did not return immediately on failure, which would lead to NULL pointer dereferencing. Let's fix it. Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05s390x: add compat machine for 2.8Cornelia Huck
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2016-09-05Open 2.8 development treePeter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-09-02Update version for v2.7.0 releasev2.7.0Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-30Update version for v2.7.0-rc5 releasev2.7.0-rc5Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-309pfs: handle walk of ".." in the root directoryGreg Kurz
The 9P spec at http://man.cat-v.org/plan_9/5/intro says: All directories must support walks to the directory .. (dot-dot) meaning parent directory, although by convention directories contain no explicit entry for .. or . (dot). The parent of the root directory of a server's tree is itself. This means that a client cannot walk further than the root directory exported by the server. In other words, if the client wants to walk "/.." or "/foo/../..", the server should answer like the request was to walk "/". This patch just does that: - we cache the QID of the root directory at attach time - during the walk we compare the QID of each path component with the root QID to detect if we're in a "/.." situation - if so, we skip the current component and go to the next one Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-309pfs: forbid . and .. in file namesGreg Kurz
According to the 9P spec http://man.cat-v.org/plan_9/5/open about the create request: The names . and .. are special; it is illegal to create files with these names. This patch causes the create and lcreate requests to fail with EINVAL if the file name is either "." or "..". Even if it isn't explicitly written in the spec, this patch extends the checking to all requests that may cause a directory entry to be created: - mknod - rename - renameat - mkdir - link - symlink The unlinkat request also gets patched for consistency (even if rmdir("foo/..") is expected to fail according to POSIX.1-2001). The various error values come from the linux manual pages. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-309pfs: forbid illegal path namesGreg Kurz
Empty path components don't make sense for most commands and may cause undefined behavior, depending on the backend. Also, the walk request described in the 9P spec [1] clearly shows that the client is supposed to send individual path components: the official linux client never sends portions of path containing the / character for example. Moreover, the 9P spec [2] also states that a system can decide to restrict the set of supported characters used in path components, with an explicit mention "to remove slashes from name components". This patch introduces a new name_is_illegal() helper that checks the names sent by the client are not empty and don't contain unwanted chars. Since 9pfs is only supported on linux hosts, only the / character is checked at the moment. When support for other hosts (AKA. win32) is added, other chars may need to be blacklisted as well. If a client sends an illegal path component, the request will fail and ENOENT is returned to the client. [1] http://man.cat-v.org/plan_9/5/walk [2] http://man.cat-v.org/plan_9/5/intro Suggested-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-30Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* pc-bios/optionrom/Makefile fix for -O0 * revert socket_connect change # gpg: Signature made Tue 30 Aug 2016 15:36:59 BST # gpg: using RSA key 0xBFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: optionrom: cope with multiple -O options Revert "Change net/socket.c to use socket_*() functions" Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-30optionrom: cope with multiple -O optionsPaolo Bonzini
Reproducer: CFLAGS="-g3 -O0" ./configure --target-list=aarch64-softmmu,arm-softmmu --enable-vhost-net --enable-virtfs Here CFLAGS ends up with "-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 ... -g3 -O0" and pc-bios/optionrom/Makefile forgets to add the -O2 it needs. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-08-30Revert "Change net/socket.c to use socket_*() functions"Paolo Bonzini
Since commit 7e8449594c929, the socket connect code is blocking, because calling socket_connect() without callback is blocking. This reverts the commit. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-08-30translate: early exit in tb_flush if there is no tcgChristian Borntraeger
tb_flush does all kind of things, which are very tcg specific. As it is called from some places even for KVM (e.g. gdb server) it is better to detect these cases and do an early exit. This also fixes a crash in the gdb server that was triggered by commit 909eaac9bbc2 ("tb hash: track translated blocks with qht"). Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Reported-by: Richard Henderson <rth@twiddle.net> Reported-by: Brent Baccala <cosine@freesoft.org> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-id: 1472148686-39841-1-git-send-email-borntraeger@de.ibm.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-30ui: fix refresh of VNC server surfaceDaniel P. Berrange
In previous commit commit c7628bff4138ce906a3620d12e0820c1cf6c140d Author: Gerd Hoffmann <kraxel@redhat.com> Date: Fri Oct 30 12:10:09 2015 +0100 vnc: only alloc server surface with clients connected the VNC server was changed so that the 'vd->server' pixman image was only allocated when a client is connected. Since then if a client disconnects and then reconnects to the VNC server all they will see is a black screen until they do something that triggers a refresh. On a graphical desktop this is not often noticed since there's many things going on which cause a refresh. On a plain text console it is really obvious since nothing refreshes frequently. The problem is that the VNC server didn't update the guest dirty bitmap, so still believes its server image is in sync with the guest contents. To fix this we must explicitly mark the entire guest desktop as dirty after re-creating the server surface. Move this logic into vnc_update_server_surface() so it is guaranteed to be call in all code paths that re-create the surface instead of only in vnc_dpy_switch() Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Peter Lieven <pl@kamp.de> Tested-by: Peter Lieven <pl@kamp.de> Message-id: 1471365032-18096-1-git-send-email-berrange@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-24Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
virtio: fixes some bugfixes for virtio balloon is still broken wrt migration Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 23 Aug 2016 17:33:11 BST # gpg: using RSA key 0x281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # 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: virtio: decrement vq->inuse in virtqueue_discard() virtio: recalculate vq->inuse after migration Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-24Fix bsd-user build after d915b7bbEd Maste
Must include "qemu-version.h" for the QEMU_PKGVERSION definition. Signed-off-by: Ed Maste <emaste@freebsd.org> Message-id: 1471877833-52343-1-git-send-email-emaste@freebsd.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-23virtio: decrement vq->inuse in virtqueue_discard()Stefan Hajnoczi
virtqueue_discard() moves vq->last_avail_idx back so the element can be popped again. It's necessary to decrement vq->inuse to avoid "leaking" the element count. Cc: qemu-stable@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-08-23virtio: recalculate vq->inuse after migrationStefan Hajnoczi
The vq->inuse field is not migrated. Many devices don't hold VirtQueueElements across migration so it doesn't matter that vq->inuse starts at 0 on the destination QEMU. At least virtio-serial, virtio-blk, and virtio-balloon migrate while holding VirtQueueElements. For these devices we need to recalculate vq->inuse upon load so the value is correct. Cc: qemu-stable@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-08-22Update version for v2.7.0-rc4 releasev2.7.0-rc4Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-22Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into ↵Peter Maydell
staging # gpg: Signature made Mon 22 Aug 2016 09:06:32 BST # gpg: using RSA key 0xEF04965B398D6211 # gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211 * remotes/jasowang/tags/net-pull-request: e1000e: remove internal interrupt flag slirp: fix segv when init failed Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-08-22e1000e: remove internal interrupt flagCao jin
Commit 66bf7d58 removed internal msi state flag E1000E_USE_MSI, E1000E_USE_MSIX is not necessary too, remove it now. And interrupt flag field intr_state also can be removed now. CC: Dmitry Fleytman <dmitry@daynix.com> CC: Jason Wang <jasowang@redhat.com> CC: Markus Armbruster <armbru@redhat.com> CC: Marcel Apfelbaum <marcel@redhat.com> CC: Michael S. Tsirkin <mst@redhat.com> CC: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Dmitry Fleytman <dmitry@daynix.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-14 01:53:39 +0000