- 22 9月, 2017 2 次提交
-
-
由 Alexey Kardashevskiy 提交于
This adds an AS** parameter to address_space_do_translate() to make it easier for the next patch to share FlatViews. This should cause no behavioural change. Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-2-aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
It's possible for address_space_get_flatview() as it currently stands to cause a use-after-free for the returned FlatView, if the reference count is incremented after the FlatView has been replaced by a writer: thread 1 thread 2 RCU thread ------------------------------------------------------------- rcu_read_lock read as->current_map set as->current_map flatview_unref '--> call_rcu flatview_ref [ref=1] rcu_read_unlock flatview_destroy <badness> Since FlatViews are not updated very often, we can just detect the situation using a new atomic op atomic_fetch_inc_nonzero, similar to Linux's atomic_inc_not_zero, which performs the refcount increment only if it hasn't already hit zero. This is similar to Linux commit de09a9771a53 ("CRED: Fix get_task_cred() and task_state() to not resurrect dead credentials", 2010-07-29). Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 21 9月, 2017 6 次提交
-
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 KONRAD Frederic 提交于
This avoids a name clash with the access macro on windows 64: make CHK version_gen.h CC aarch64-softmmu/memory.o /home/konrad/qemu/memory.c: In function 'access_with_adjusted_size': /home/konrad/qemu/memory.c:591:73: error: macro "access" passed 7 arguments, \ but takes just 2 (size - access_size - i) * 8, access_mask, attrs); ^ Signed-off-by: NKONRAD Frederic <frederic.konrad@adacore.com> Message-Id: <1505988260-8483-1-git-send-email-frederic.konrad@adacore.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 David Hildenbrand 提交于
pflash toggles mr->romd_mode. So this assert does not always hold. 1) a device was added with !mr->romd_mode, therefore effectively not creating a kvm slot as we want to trap every access (add = false). 2) mr->romd_mode was toggled on before remove it. There is now actually no slot to remove and the assert is wrong. So let's just drop the assert. Reported-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170920145025.19403-1-david@redhat.com> Tested-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Pavel Butsykin 提交于
We should guarantee that RAM will not be modified while VM has a stopped state, otherwise it can lead to negative consequences during post-copy migration. In RUN_STATE_FINISH_MIGRATE step, it's expected that RAM on source side will not be modified as this could lead to non-consistent vm state on the destination side. Also RAM access during postcopy-ram migration with enabled release-ram capability can lead to sad consequences. Let's add enable_backend() callback to avoid undesirable virtioqueue changes in the guest memory. Signed-off-by: NPavel Butsykin <pbutsykin@virtuozzo.com> Message-Id: <20170919120733.22020-1-pbutsykin@virtuozzo.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Peter Maydell 提交于
These patches fix regressions in 2.10 # gpg: Signature made Wed 20 Sep 2017 07:51:07 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: check the size of transport buffer before marshaling 9pfs: fix name_to_path assertion in v9fs_complete_rename() 9pfs: fix readdir() for 9p2000.u Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
Machine/CPU/NUMA queue, 2017-09-19 # gpg: Signature made Tue 19 Sep 2017 21:17:01 BST # gpg: using RSA key 0x2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/machine-next-pull-request: MAINTAINERS: Update git URLs for my trees hw/acpi-build: Fix SRAT memory building in case of node 0 without RAM NUMA: Replace MAX_NODES with nb_numa_nodes in for loop numa: cpu: calculate/set default node-ids after all -numa CLI options are parsed arm: drop intermediate cpu_model -> cpu type parsing and use cpu type directly pc: use generic cpu_model parsing vl.c: convert cpu_model to cpu type and set of global properties before machine_init() cpu: make cpu_generic_init() abort QEMU on error qom: cpus: split cpu_generic_init() on feature parsing and cpu creation parts hostmem-file: Add "discard-data" option osdep: Define QEMU_MADV_REMOVE vl: Clean up user-creatable objects when exiting Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 20 9月, 2017 32 次提交
-
-
由 Jan Dakinevich 提交于
v9fs_do_readdir_with_stat() should check for a maximum buffer size before an attempt to marshal gathered data. Otherwise, buffers assumed as misconfigured and the transport would be broken. The patch brings v9fs_do_readdir_with_stat() in conformity with v9fs_do_readdir() behavior. Signed-off-by: NJan Dakinevich <jan.dakinevich@gmail.com> [groug, regression caused my commit 8d37de41 # 2.10] Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Jan Dakinevich 提交于
The third parameter of v9fs_co_name_to_path() must not contain `/' character. The issue is most likely related to 9p2000.u protocol only. Signed-off-by: NJan Dakinevich <jan.dakinevich@gmail.com> [groug, regression caused by commit f57f5878 # 2.10] Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Jan Dakinevich 提交于
If the client is using 9p2000.u, the following occurs: $ cd ${virtfs_shared_dir} $ mkdir -p a/b/c $ ls a/b ls: cannot access 'a/b/a': No such file or directory ls: cannot access 'a/b/b': No such file or directory a b c instead of the expected: $ ls a/b c This is a regression introduced by commit f57f5878; local_name_to_path() now resolves ".." and "." in paths, and v9fs_do_readdir_with_stat()->stat_to_v9stat() then copies the basename of the resulting path to the response. With the example above, this means that "." and ".." are turned into "b" and "a" respectively... stat_to_v9stat() currently assumes it is passed a full canonicalized path and uses it to do two different things: 1) to pass it to v9fs_co_readlink() in case the file is a symbolic link 2) to set the name field of the V9fsStat structure to the basename part of the given path It only has two users: v9fs_stat() and v9fs_do_readdir_with_stat(). v9fs_stat() really needs 1) and 2) to be performed since it starts with the full canonicalized path stored in the fid. It is different for v9fs_do_readdir_with_stat() though because the name we want to put into the V9fsStat structure is the d_name field of the dirent actually (ie, we want to keep the "." and ".." special names). So, we only need 1) in this case. This patch hence adds a basename argument to stat_to_v9stat(), to be used to set the name field of the V9fsStat structure, and moves the basename logic to v9fs_stat(). Signed-off-by: NJan Dakinevich <jan.dakinevich@gmail.com> (groug, renamed old name argument to path and updated changelog) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Eduardo Habkost 提交于
List the branches where I queue patches for Machine Core, NUMA, Memory Backends, and X86. Update the NUMA section to list the "machine-next" branch instead of "numa". Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Message-Id: <20170901153928.17058-1-ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Eduardo Habkost 提交于
Currently, Using the fisrt node without memory on the machine makes QEMU unhappy. With this example command line: ... \ -m 1024M,slots=4,maxmem=32G \ -numa node,nodeid=0 \ -numa node,mem=1024M,nodeid=1 \ -numa node,nodeid=2 \ -numa node,nodeid=3 \ Guest reports "No NUMA configuration found" and the NUMA topology is wrong. This is because when QEMU builds ACPI SRAT, it regards node 0 as the default node to deal with the memory hole(640K-1M). this means the node0 must have some memory(>1M), but, actually it can have no memory. Fix this problem by cut out the 640K hole in the same way the PCI 4G hole does. Signed-off-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com> Message-Id: <1504231805-30957-2-git-send-email-douly.fnst@cn.fujitsu.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Dou Liyang 提交于
In QEMU, the number of the NUMA nodes is determined by parse_numa_opts(). Then, QEMU uses it for iteration, for example: for (i = 0; i < nb_numa_nodes; i++) However, in memory_region_allocate_system_memory(), it uses MAX_NODES not nb_numa_nodes. So, replace MAX_NODES with nb_numa_nodes to keep code consistency and reduce the loop times. Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com> Message-Id: <1503387936-3483-1-git-send-email-douly.fnst@cn.fujitsu.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Igor Mammedov 提交于
Calculating default node-ids for CPUs in possible_cpu_arch_ids() is rather fragile since defaults calculation uses nb_numa_nodes but callback might be potentially called early before all -numa CLI options are parsed, which would lead to cpus assigned only upto nb_numa_nodes at the time possible_cpu_arch_ids() is called. Issue was introduced by (7c88e65d numa: mirror cpu to node mapping in MachineState::possible_cpus) and for example CLI: -smp 4 -numa node,cpus=0 -numa node would set props.node-id in possible_cpus array for every non explicitly mapped CPU to the first node. Issue is not visible to guest nor to mgmt interface due to 1) implictly mapped cpus are forced to the first node in case of partial mapping 2) in case of default mapping possible_cpu_arch_ids() is called after all -numa options are parsed (resulting in correct mapping). However it's fragile to rely on late execution of possible_cpu_arch_ids(), therefore add machine specific callback that returns node-id for CPU and use it to calculate/ set defaults at machine_numa_finish_init() time when all -numa options are parsed. Reported-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Message-Id: <1496314408-163972-1-git-send-email-imammedo@redhat.com> Reviewed-by: NEduardo Habkost <ehabkost@redhat.com> Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
-
由 Peter Maydell 提交于
Assorted s390x patches: - introduce virtio-gpu-ccw, with virtio-gpu endian fixes - lots of cleanup in the s390x code - make device_add work for s390x cpus - enable seccomp on s390x - an ivshmem endian fix - set the reserved DHCP client architecture id for netboot - fixes in the css and pci support # gpg: Signature made Tue 19 Sep 2017 17:39:45 BST # gpg: using RSA key 0xDECF6B93C6F02FAF # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" # gpg: aka "Cornelia Huck <cohuck@kernel.org>" # gpg: aka "Cornelia Huck <cohuck@redhat.com>" # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20170919-v2: (38 commits) MAINTAINERS/s390x: add terminal3270.c virtio-ccw: Create a virtio gpu device for the ccw bus virtio-gpu: Handle endian conversion s390x/ccw: create s390 phb for compat reasons as well configure: Allow --enable-seccomp on s390x, too virtio-ccw: remove stale comments on endianness s390x: allow CPU hotplug in random core-id order s390x: generate sclp cpu information from possible_cpus s390x: get rid of cpu_s390x_create() s390x: get rid of cpu_states and use possible_cpus instead s390x: implement query-hotpluggable-cpus s390x: CPU hot unplug via device_del cannot work for now s390x: allow cpu hotplug via device_add s390x: print CPU definitions in sorted order target/s390x: rename next_cpu_id to next_core_id target/s390x: use "core-id" for cpu number/address/id handling target/s390x: set cpu->id for linux user when realizing s390x: allow only 1 CPU with TCG target/s390x: use program_interrupt() in per_check_exception() target/s390x: use trigger_pgm_exception() in s390_cpu_handle_mmu_fault() ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Christian Borntraeger 提交于
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170918130455.144262-1-borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Farhan Ali 提交于
Wire up the virtio-gpu device for the CCW bus. The virtio-gpu is a virtio-1 device, so disable revision 0. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-Id: <6c53f939cf2d64b66d2a6878b29c9bf3820f3d5b.1505485574.git.alifm@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Farhan Ali 提交于
Virtio GPU code currently only supports litte endian format, and so using the Virtio GPU device on a big endian machine does not work. Let's fix it by supporting the correct host cpu byte order. Signed-off-by: NFarhan Ali <alifm@linux.vnet.ibm.com> Message-Id: <dc748e15f36db808f90b4f2393bc29ba7556a9f6.1505485574.git.alifm@linux.vnet.ibm.com> Reviewed-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Cornelia Huck 提交于
d32bd032 ("s390x/ccw: create s390 phb conditionally") made registering the s390 pci host bridge conditional on presense of the zpci facility bit. Sadly, that breaks migration from machines that did not use the cpu model (2.7 and previous). Create the s390 phb for pre-cpu model machines as well: We can tweak s390_has_feat() to always indicate the zpci facility bit when no cpu model is available (on 2.7 and previous compat machines). Fixes: d32bd032 ("s390x/ccw: create s390 phb conditionally") Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Thomas Huth 提交于
libseccomp supports s390x since version 2.3.0, and I was able to start a VM with "-sandbox on" without any obvious problems by using this patch, so it should be safe to allow --enable-seccomp on s390x nowadays, too. Signed-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <1505385363-27717-1-git-send-email-thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Acked-by: NEduardo Otubo <otubo@redhat.com> Acked-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Halil Pasic 提交于
We have two stale comments suggesting one should think about virtio config space endianness a bit longer. We have just done that, and came to the conclusion we are fine as is: it's the responsibility of the virtio device and not of the transport (and that is how it works now). Putting the responsibility into the transport isn't even possible, because the transport would have to know about the config space layout of each device. Let us remove the stale comments. Signed-off-by: NHalil Pasic <pasic@linux.vnet.ibm.com> Suggested-by: NCornelia Huck <cohuck@redhat.com> Message-Id: <20170914105535.47941-1-pasic@linux.vnet.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
SCLP correctly indicates the core-id aka. CPU address for each available CPU. As the core-id corresponds to cpu_index, also a newly created kvm vcpu gets assigned this core-id as vcpu id. So SIGP in the kernel works correctly (it uses the vcpu id to lookup the correct CPU). So there should be nothing hindering us from hotplugging CPUs in random core-id order. This now makes sure that the output from "query-hotpluggable-cpus" is completely true. Until now, a specific order is implicit. Performance vice, hotplugging CPUs in non-sequential order might not be the best thing to do, as VCPU lookup inside KVM might be a little slower. But that doesn't hinder us from supporting it. next_core_id is now used by linux user only. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-23-david@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
This is the first step to allow hot plugging of CPUs in a non-sequential order. If a cpu is available ("plugged") can directly be decided by looking at the cpu state pointer. This makes sure, that really only cpus attached to the machine are reported. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-22-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Now that there is only one user of cpu_s390x_create() left, make cpu creation look like on x86. - Perform the model/properties split and checks in s390_init_cpus() - Parse features only once without having to remember if already parsed - Pass only the typename to s390x_new_cpu() - Use the typename of an existing CPU for hotplug via cpu-add Acked-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-21-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Now that we have possible_cpus, we can get rid of the global variable and rewrite s390_cpu_addr2state() to use it. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-20-david@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
CPU hotplug is only possible on a per core basis on s390x. So let's add possible_cpus and wire everything up properly. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-19-david@redhat.com> Acked-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
device_del on a CPU will currently do nothing. Let's emit an error telling that this is will currently not work (there is no architecture support on s390x). Error message copied from ppc. (qemu) device_del cpu1 device_del cpu1 CPU hot unplug not supported on this machine Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-18-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
E.g. the following now works: device_add host-s390-cpu,id=cpu1,core-id=1 The system will perform the same checks as when using cpu_add: - If the core_id is already in use - If the next sequential core_id isn't used - If core-id >= max_cpu is specified In addition, mixed CPU models are checked. E.g. if starting with -cpu host and trying to hotplug "qemu-s390-cpu": "Mixed CPU models are not supported on s390x." Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-17-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Other architectures provide nicely sorted lists, let's do it similarly on s390x. While at it, clean up the code we have to touch either way. Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-16-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Adapt to the new term "core_id". While at it, fix the type and drop the initialization to 0 (which is superfluous). Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-15-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Some time ago we discussed that using "id" as property name is not the right thing to do, as it is a reserved property for other devices and will not work with device_add. Switch to the term "core-id" instead, and use it as an equivalent to "CPU address" mentioned in the PoP. There is no such thing as cpu number, so rename env.cpu_num to env.core_id. We use "core-id" as this is the common term to use for device_add later on (x86 and ppc). We can get rid of cpu->id now. Keep cpu_index and env->core_id in sync. cpu_index was already implicitly used by e.g. cpu_exists(), so keeping both in sync seems to be the right thing to do. cpu_index will now no longer automatically get set via cpu_exec_realizefn(). For now, we were lucky that both implicitly stayed in sync. Our new cpu property "core-id" can be a static property. Range checks can be avoided by using the correct type and the "setting after realized" check is done implicitly. device_add will later need the reserved "id" property. Hotplugging a CPU on s390x will then be: "device_add host-s390-cpu,id=cpu2,core-id=2". Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-14-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
scc->next_cpu_id is updated when realizing. Setting it just before that point looks cleaner. Reviewed-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-13-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the guest tries to bring these CPUs up but fails), because we don't support multiple CPUs on s390x under TCG. Let's bail out if more than 1 is specified, so we don't raise people's hope. Tested-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-12-david@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Clean it up by reusing program_interrupt(). Add a concern regarding ilen. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-11-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
This looks cleaner. linux-user will not use the ilen field, so setting it doesn't do any harm. Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-10-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Implemented in sclp.c, so let's move it to the right include file. Also adjust some includes. Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-9-david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
This allows us to drop inclusion of cpu_models.h in cpu-qom.h, and prepares for using cpu-qom.h as a s390 specific version of typedefs.h Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-8-david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Implemented in s390-virtio-ccw.c, so move it to the right header. We can also drop the extern. Fix up one include. Reviewed-by: NThomas Huth <thuth@redhat.com> Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-7-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 David Hildenbrand 提交于
Implemented in hw/s390x/s390-virtio-hcall.c, so let's move it to the right header file. Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NDavid Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-6-david@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-