- Sep 20, 2017
-
-
Jan Dakinevich authored
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:
Jan Dakinevich <jan.dakinevich@gmail.com> (groug, renamed old name argument to path and updated changelog) Signed-off-by:
Greg Kurz <groug@kaod.org>
-
- Sep 19, 2017
-
-
Peter Maydell authored
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:
Peter Maydell <peter.maydell@linaro.org>
-
Christian Borntraeger authored
Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170918130455.144262-1-borntraeger@de.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Farhan Ali authored
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:
Farhan Ali <alifm@linux.vnet.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Message-Id: <6c53f939cf2d64b66d2a6878b29c9bf3820f3d5b.1505485574.git.alifm@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Farhan Ali authored
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:
Farhan Ali <alifm@linux.vnet.ibm.com> Message-Id: <dc748e15f36db808f90b4f2393bc29ba7556a9f6.1505485574.git.alifm@linux.vnet.ibm.com> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Cornelia Huck authored
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:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Thomas Huth authored
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:
Thomas Huth <thuth@redhat.com> Message-Id: <1505385363-27717-1-git-send-email-thuth@redhat.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Acked-by:
Eduardo Otubo <otubo@redhat.com> Acked-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Halil Pasic authored
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:
Halil Pasic <pasic@linux.vnet.ibm.com> Suggested-by:
Cornelia Huck <cohuck@redhat.com> Message-Id: <20170914105535.47941-1-pasic@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-23-david@redhat.com> Reviewed-by:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-22-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-21-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-20-david@redhat.com> Reviewed-by:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-19-david@redhat.com> Acked-by:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
Matthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-18-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
Matthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-17-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-16-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
Adapt to the new term "core_id". While at it, fix the type and drop the initialization to 0 (which is superfluous). Reviewed-by:
Matthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-15-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
Matthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-14-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
scc->next_cpu_id is updated when realizing. Setting it just before that point looks cleaner. Reviewed-by:
Matthew Rosato <mjrosato@linux.vnet.ibm.com> Reviewed-by:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-13-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
Matthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-12-david@redhat.com> Reviewed-by:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
Clean it up by reusing program_interrupt(). Add a concern regarding ilen. Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-11-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
This looks cleaner. linux-user will not use the ilen field, so setting it doesn't do any harm. Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-10-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
Implemented in sclp.c, so let's move it to the right include file. Also adjust some includes. Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-9-david@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-8-david@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
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:
Thomas Huth <thuth@redhat.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-7-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
Implemented in hw/s390x/s390-virtio-hcall.c, so let's move it to the right header file. Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-6-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
The only interface left, so let's properly rename it. Reviewed-by:
Thomas Huth <thuth@redhat.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-5-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
It is a leftover from the days where we had still the !ccw virtio machine. As this one is long gone, let's move everything to s390-virtio-ccw.c. Suggested-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-4-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
These comments are obviously stale. Acked-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-3-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
David Hildenbrand authored
All but a handful of files include exec/cpu-all.h via cpu.h only. As these files already include cpu.h, let's just drop the additional include. Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Message-Id: <20170913132417.24384-2-david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Viktor Mihajlovski authored
Setting the client architecture DHCP option to 0x001f (s390 Basic) [1] allows the DHCP server to return a s390-specific bootfile if wanted. DHCP servers not configured for the option (or not yet recognizing the option value) will continue to work as they have done before. [1] https://www.iana.org/assignments/dhcpv6-parameters Signed-off-by:
Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> Message-Id: <1505126027-1704-1-git-send-email-mihajlov@linux.vnet.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Halil Pasic authored
The case in question actually never happens. Let us get rid of the dead code. Signed-off-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170908152446.14606-4-pasic@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Halil Pasic authored
Back then in the time of df1fe5bb ("s390: Virtual channel subsystem support.", 2013-01-24) -EIO used to map to a channel-program check (via the default label of the switch statement). Then 2dc95b4c ("s390x/3270: 3270 data stream handling", 2016-04-01) came along and that changed dramatically. Let us roll back this undesired side effect, and go back to channel-program check. Signed-off-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Fixes: 2dc95b4c "s390x/3270: 3270 data stream handling" Message-Id: <20170908152446.14606-3-pasic@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Halil Pasic authored
The architecture says that channel-data check is indicating that an uncorrected storage (memory) error has been detected in regard to the data residing in main storage (memory) that is currently used for an I/O operation. The described detection is done using the CBC technology. The ccw interpretation code is however generating a channel-data check effectively when the (device specific) ccw_cb returns -EFAULT. In case of virtio-ccw devices this happens when mapping memory fails, or when a NULL pointer is encountered. So this behavior is not architecture conform. Furthermore the best fit for these situations (null pointer, mapping a piece of guest memory fails) from architectural perspective the condition described as the channel subsystem refers to a location that is not available, which when encountered shall result in a channel-program check. To fix this, all we have to do is to get rid of the switch case matching -EFAULT: the default is generating a channel-program check. Signed-off-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Message-Id: <20170908152446.14606-2-pasic@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Thomas Huth authored
The "slow" ivshmem-tests currently fail when they are running on a big endian host: $ uname -m ppc64 $ V=1 QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/ivshmem-test -m slow /x86_64/ivshmem/single: OK /x86_64/ivshmem/hotplug: OK /x86_64/ivshmem/memdev: OK /x86_64/ivshmem/pair: OK /x86_64/ivshmem/server-msi: qemu-system-x86_64: -device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message Broken pipe The problem is that the server side code in ivshmem_server_send_one_msg() correctly translates all messages IDs into little endian 64-bit values, but the client side code in the ivshmem_recv_msg() function does not swap the byte order back. Fix it by passing the value through le64_to_cpu(). Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <1504100343-26607-1-git-send-email-thuth@redhat.com> Tested-by:
Cornelia Huck <cohuck@redhat.com> Reviewed-by:
Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Yi Min Zhao authored
Let's introduce iommu replay callback for s390 pci iommu memory region. Currently we don't need any dma mapping replay. So let it return directly. This implementation will avoid meaningless loops calling translation callback. Reviewed-by:
Pierre Morel <pmorel@linux.vnet.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Signed-off-by:
Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1504606380-49341-4-git-send-email-zyimin@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Yi Min Zhao authored
The guest uses the mpcifc instruction to register the aibvo of a zpci device, which is the starting offset of indicators in the indicator area and thus remains constant. Each msix vector is an offset from the aibvo. When we map a msix route to an adapter route, we should not modify the starting offset, but instead add the vector to the starting offset to get the absolute offset in the specific route. Signed-off-by:
Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1504606380-49341-3-git-send-email-zyimin@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Yi Min Zhao authored
PCIDevice pointer has been a parameter of kvm_arch_fixup_msi_route(). So we don't need to store zpci idx in msix message data to find out the specific zpci device. Instead, we could use pci device id to find its corresponding zpci device. Signed-off-by:
Yi Min Zhao <zyimin@linux.vnet.ibm.com> Message-Id: <1504606380-49341-2-git-send-email-zyimin@linux.vnet.ibm.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Thomas Huth authored
We can use the drive_del test on s390x, too, to check that adding and deleting also works fine with the virtio-ccw bus. But we have to make sure that we use the devices with the "-ccw" suffix instead of the "-pci" suffix for the virtio-ccw transport on s390x. Introduce a helper function called qvirtio_get_dev_type() that returns the correct string for the current architecture. Signed-off-by:
Thomas Huth <thuth@redhat.com> Message-Id: <1504190408-11143-1-git-send-email-thuth@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-
Halil Pasic authored
The function ioinst_handle_xsch is presenting cc 2 when it's supposed to present cc 1 and the other way around, because css_do_xsch has the error codes mixed up. Because cc 1 has precedence over cc 2 we also have to swap the two checks. Let us fix this. Signed-off-by:
Halil Pasic <pasic@linux.vnet.ibm.com> Reported-by:
Pierre Morel <pmorel@linux.vnet.ibm.com> Message-Id: <20170831121828.85885-1-pasic@linux.vnet.ibm.com> Reviewed-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Cornelia Huck <cohuck@redhat.com>
-