- 02 4月, 2019 1 次提交
-
-
由 Bandan Das 提交于
Spotted by Coverity: CID 1399414 mtp delete allows the return status of delete succeeded, partial_delete or readonly - when none of the objects could be deleted. Give more meaningful names to return values of the delete function. Some initiators recurse over the objects themselves. In that case, only READ_ONLY can be returned. Signed-off-by: NBandan Das <bsd@redhat.com> Message-Id: <20190401211712.19012-2-bsd@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 01 4月, 2019 2 次提交
-
-
由 Peter Maydell 提交于
In usb_mask_to_str() we convert a mask of USB speeds into a human-readable string (like "full+high") for use in tracing and error messages. However the conversion code doesn't do anything to the string buffer if the passed in speedmask doesn't match any of the recognized speeds, which means that the tracing and error messages will end up with random garbage in them. This can happen if we're doing USB device passthrough. Handle the "unrecognized speed" case by using the string "unknown". Fixes: https://bugs.launchpad.net/qemu/+bug/1603785Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20190328133503.6490-1-peter.maydell@linaro.org Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
This reverts commit bd56d378. Turned out it isn't that simple as the device needs the pit object link. So "-device isa-pcspk" isn't going wo work anyway. We are in freeze, so just reverting the thing is the best way to handle this for now, trying to come up with something better can be done in the 4.1 devel cycle. Also add a comment noting the object link. Reported-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Message-id: 20190328071121.21147-1-kraxel@redhat.com
-
- 30 3月, 2019 1 次提交
-
-
由 Peter Maydell 提交于
Update palcode for machine checks. # gpg: Signature made Mon 25 Mar 2019 23:09:24 GMT # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * remotes/rth/tags/pull-axp-20190325: pc-bios: Update palcode-clipper Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 29 3月, 2019 14 次提交
-
-
由 Peter Maydell 提交于
# gpg: Signature made Fri 29 Mar 2019 07:30:26 GMT # gpg: using RSA key EF04965B398D6211 # gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" [marginal] # 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: net: tap: use qemu_set_nonblock MAINTAINERS: Update the latest email address e1000: Delay flush queue when receive RCTL net/socket: learn to talk with a unix dgram socket Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
ppc patch queue 2019-03-29 Here's a set of bugfixes for ppc, aimed at qemu-4.0 during hard freeze. We have one cleanup that's not strictly a bugfix, but will avoid an ugly external interface making it to a released version. We have one change to generic code to tweak the semantics of qemu_getrampagesize() which fixes a bug for ppc. This does have a possible impact on s390x which uses this function for a different purpose. I've discussed with David Hildenbrand and Igor Mammedov, however and we think it won't immediately break anything due to some existing bugs in the s390 usage. David H will be following up with some s390 fixes in that area. # gpg: Signature made Fri 29 Mar 2019 03:27:49 GMT # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-4.0-20190329: exec: Only count mapped memory backends for qemu_getrampagesize() spapr/irq: Add XIVE sanity checks on non-P9 machines spapr: Simplify handling of host-serial and host-model values target/ppc: Fix QEMU crash with stxsdx target/ppc: Improve comment of bcctr used for spectre v2 mitigation target/ppc: Consolidate 64-bit server processor detection in a helper target/ppc: Enable "decrement and test CTR" version of bcctr target/ppc: Fix TCG temporary leaks in gen_bcond() Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Li Qiang 提交于
The fcntl will change the flags directly, use qemu_set_nonblock() instead. Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NLi Qiang <liq3ea@gmail.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 Zhang Chen 提交于
Signed-off-by: NZhang Chen <chen.zhang@intel.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 yuchenlin 提交于
Due to too early RCT0 interrput, win10x32 may hang on booting. This problem can be reproduced by doing power cycle on win10x32 guest. In our environment, we have 10 win10x32 and stress power cycle. The problem will happen about 20 rounds. Below shows some log with comment: The normal case: 22831@1551928392.984687:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928392.985655:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928392.985801:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.056710:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.077548:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 2, ICR 0, IMR 0 e1000: set_ics 2, ICR 2, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.102974:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928393.103267:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle RX now e1000: set_ics 0, ICR 2, IMR 9d <- unmask interrupt e1000: RCTL: 255, mac_reg[RCTL] = 0x48002 e1000: set_ics 80, ICR 2, IMR 9d <- interrupt and work! ... The bad case: 27744@1551930483.117766:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 27744@1551930483.118398:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.198063:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.218675:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 2, ICR 0, IMR 0 e1000: set_ics 2, ICR 2, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.241768:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 27744@1551930483.241979:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle RX now e1000: set_ics 80, ICR 2, IMR 0 <- flush queue (caused by setting RCTL) e1000: set_ics 0, ICR 82, IMR 9d <- unmask interrupt and because 0x82&0x9d != 0 generate interrupt, hang on here... To workaround this problem, simply delay flush queue. Also stop receiving when timer is going to run. Tested on CentOS, Win7SP1x64 and Win10x32. Signed-off-by: Nyuchenlin <yuchenlin@synology.com> Reviewed-by: NDmitry Fleytman <dmitry.fleytman@gmail.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 Marc-André Lureau 提交于
-net socket has a fd argument, and may be passed pre-opened sockets. TCP sockets use framing. UDP sockets have datagram boundaries. When given a unix dgram socket, it will be able to read from it, but will attempt to send on the dgram_dst, which is unset. The other end will not receive the data. Let's teach -net socket to recognize a UNIX DGRAM socket, and use the regular send() command (without dgram_dst). This makes running slirp out-of-process possible that way (python pseudo-code): a, b = socket.socketpair(socket.AF_UNIX, socket.SOCK_DGRAM) subprocess.Popen('qemu -net socket,fd=%d -net user' % a.fileno(), shell=True) subprocess.Popen('qemu ... -net nic -net socket,fd=%d' % b.fileno(), shell=True) Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
由 David Gibson 提交于
qemu_getrampagesize() works out the minimum host page size backing any of guest RAM. This is required in a few places, such as for POWER8 PAPR KVM guests, because limitations of the hardware virtualization mean the guest can't use pagesizes larger than the host pages backing its memory. However, it currently checks against *every* memory backend, whether or not it is actually mapped into guest memory at the moment. This is incorrect. This can cause a problem attempting to add memory to a POWER8 pseries KVM guest which is configured to allow hugepages in the guest (e.g. -machine cap-hpt-max-page-size=16m). If you attempt to add non-hugepage, you can (correctly) create a memory backend, however it (correctly) will throw an error when you attempt to map that memory into the guest by 'device_add'ing a pc-dimm. What's not correct is that if you then reset the guest a startup check against qemu_getrampagesize() will cause a fatal error because of the new memory object, even though it's not mapped into the guest. This patch corrects the problem by adjusting find_max_supported_pagesize() (called from qemu_getrampagesize() via object_child_foreach) to exclude non-mapped memory backends. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Acked-by: NDavid Hildenbrand <david@redhat.com>
-
由 Cédric Le Goater 提交于
On non-P9 machines, the XIVE interrupt mode is not advertised, see spapr_dt_ov5_platform_support(). Add a couple of checks on the machine configuration to filter bogus setups and prevent OS failures : Interrupt modes CPU/Compat XICS XIVE dual P8/P8 OK QEMU failure (1) OK (3) P9/P8 OK QEMU failure (2) OK (3) P9/P9 OK OK OK (1) CPU exception model is incompatible with XIVE and the presenters will fail to realize. (2) CPU exception model is compatible with XIVE, but the XIVE CAS advertisement is dropped when in POWER8 mode. So we could ended up booting with the XIVE DT properties but without the HCALLs. Avoid confusing Linux with such settings and fail under QEMU. (3) force XICS in machine init Remove the check on XIVE-only machines in spapr_machine_init(), which has now become redundant. Signed-off-by: NCédric Le Goater <clg@kaod.org> Message-Id: <20190328100044.11408-1-clg@kaod.org> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
27461d69 "ppc: add host-serial and host-model machine attributes (CVE-2019-8934)" introduced 'host-serial' and 'host-model' machine properties for spapr to explicitly control the values advertised to the guest in device tree properties with the same names. The previous behaviour on KVM was to unconditionally populate the device tree with the real host serial number and model, which leaks possibly sensitive information about the host to the guest. To maintain compatibility for old machine types, we allowed those props to be set to "passthrough" to take the value from the host as before. Or they could be set to "none" to explicitly omit the device tree items. Special casing specific values on what's otherwise a user supplied string is very ugly. So, this patch simplifies things by implementing the backwards compatibility in a different way: we have a machine class flag set for the older machines, and we only load the host values into the device tree if A) they're not set by the user and B) we have that flag set. This does mean that the "passthrough" functionality is no longer available with the current machine type. That's ok though: if a user or management layer really wants the information passed through they can read it themselves (OpenStack Nova already does something similar for x86). It also means the user can't explicitly ask for the values to be omitted on the old machine types. I think that's an acceptable trade-off: if you care enough about not leaking the host information you can either move to the new machine type, or use a dummy value for the properties. For the new machine type, this also removes an odd inconsistency between running on a POWER and non-POWER (or non-Linux) hosts: if the host information couldn't be read from where we expect (in the host's device tree as exposed by Linux), we'd fallback to omitting the guest device tree items. While we're there, improve some poorly worded comments, and the help text for the properties. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Tested-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
I've been hitting several QEMU crashes while running a fedora29 ppc64le guest under TCG. Each time, this would occur several minutes after the guest reached login: Fedora 29 (Twenty Nine) Kernel 4.20.6-200.fc29.ppc64le on an ppc64le (hvc0) Web console: https://localhost:9090/ localhost login: tcg/tcg.c:3211: tcg fatal error This happens because a bug crept up in the gen_stxsdx() helper when it was converted to use VSR register accessors by commit 8b3b2d75 "target/ppc: introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}() helpers for VSR register access". The code creates a temporary, passes it directly to gen_qemu_st64_i64() and then to set_cpu_vrsh()... which looks like this was mistakenly coded as a load instead of a store. Reverse the logic: read the VSR to the temporary first and then store it to memory. Fixes: 8b3b2d75Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155371035249.2038502.12364252604337688538.stgit@bahia.lan> Reviewed-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155359567174.1794128.3183997593369465355.stgit@bahia.lan> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
We use PPC_SEGMENT_64B in various places to guard code that is specific to 64-bit server processors compliant with arch 2.x. Consolidate the logic in a helper macro with an explicit name. Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155327783157.1283071.3747129891004927299.stgit@bahia.lan> Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Even if all ISAs up to v3 indeed mention: If the "decrement and test CTR" option is specified (BO2=0), the instruction form is invalid. The UMs of all existing 64-bit server class processors say: If BO[2] = 0, the contents of CTR (before any update) are used as the target address and for the test of the contents of CTR to resolve the branch. The contents of the CTR are then decremented and written back to the CTR. The linux kernel has spectre v2 mitigation code that relies on a BO[2] = 0 variant of bcctr, which is now activated by default on spapr, even with TCG. This causes linux guests to panic with the default machine type under TCG. Since any CPU model can provide its own behaviour for invalid forms, we could possibly introduce a new instruction flag to handle this. In practice, since the behaviour is shared by all 64-bit server processors starting with 970 up to POWER9, let's reuse the PPC_SEGMENT_64B flag. Caveat: this may have to be fixed later if POWER10 introduces a different behaviour. The existing behaviour of throwing a program interrupt is kept for all other CPU models. Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155327782604.1283071.10640596307206921951.stgit@bahia.lan> Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155327782047.1283071.10234727692461848972.stgit@bahia.lan> Tested-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 28 3月, 2019 5 次提交
-
-
由 Peter Maydell 提交于
Device Tree Pull Request for 4.0 A single patch updating the MAINTAINERS file for 4.0. # gpg: Signature made Wed 27 Mar 2019 17:02:00 GMT # gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full] # Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054 * remotes/alistair/tags/pull-device-tree-20190327: MAINTAINERS: Update the device tree maintainers Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
pull-seccomp-20190327 # gpg: Signature made Wed 27 Mar 2019 12:12:39 GMT # gpg: using RSA key DF32E7C0F0FFF9A2 # gpg: Good signature from "Eduardo Otubo (Senior Software Engineer) <otubo@redhat.com>" [full] # Primary key fingerprint: D67E 1B50 9374 86B4 0723 DBAB DF32 E7C0 F0FF F9A2 * remotes/otubo/tags/pull-seccomp-20190327: seccomp: report more useful errors from seccomp seccomp: don't kill process for resource control syscalls Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
* Kconfig improvements (msi_nonbroken, imply for default PCI devices) * intel-iommu: sharing passthrough FlatViews (Peter) * Fix for SEV with VFIO (Brijesh) * Allow compilation without CONFIG_PARALLEL (Thomas) # gpg: Signature made Thu 21 Mar 2019 16:42:24 GMT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # 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: (23 commits) virtio-vga: only enable for specific boards config-all-devices.mak: rebuild on reconfigure minikconf: fix parser typo intel-iommu: optimize nodmar memory regions test-announce-self: convert to qgraph hw/alpha/Kconfig: DP264 hardware requires e1000 network card hw/hppa/Kconfig: Dino board requires e1000 network card hw/sh4/Kconfig: r2d machine requires the rtl8139 network card hw/ppc/Kconfig: e500 based machines require virtio-net-pci device hw/ppc/Kconfig: Bamboo machine requires e1000 network card hw/mips/Kconfig: Fulong 2e board requires ati-vga/rtl8139 PCI devices hw/mips/Kconfig: Malta machine requires the pcnet network card hw/i386/Kconfig: enable devices that can be created by default hw/isa/Kconfig: PIIX4 southbridge requires USB UHCI hw/isa/Kconfig: i82378 SuperIO requires PC speaker device prep: do not select I82374 hw/i386/Kconfig: PC uses I8257, not I82374 hw/char/parallel: Make it possible to compile also without CONFIG_PARALLEL target/i386: sev: Do not pin the ram device memory region memory: Fix the memory region type assignment order ... Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> # Conflicts: # hw/rdma/Makefile.objs # hw/riscv/sifive_plic.c
-
由 Peter Maydell 提交于
target/xtensa fixes for v4.0: - fix translation of FLIX bundles with multiple references to the same register; - don't announce exit simcall; - clean up tests/tcg/xtensa. # gpg: Signature made Tue 26 Mar 2019 17:58:59 GMT # gpg: using RSA key 2B67854B98E5327DCDEB17D851F9CC91F83FA044 # gpg: issuer "jcmvbkbc@gmail.com" # gpg: Good signature from "Max Filippov <filippov@cadence.com>" [unknown] # gpg: aka "Max Filippov <max.filippov@cogentembedded.com>" [full] # gpg: aka "Max Filippov <jcmvbkbc@gmail.com>" [full] # Primary key fingerprint: 2B67 854B 98E5 327D CDEB 17D8 51F9 CC91 F83F A044 * remotes/xtensa/tags/20190326-xtensa: tests/tcg/xtensa: clean up test set target/xtensa: don't announce exit simcall target/xtensa: fix break_dependency for repeated resources Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Alistair Francis 提交于
Remove Alex as a Device Tree maintainer as requested by him. Add myself as a maintainer to avoid it being orphaned. Also add David as a Reviewer (R) as he is the libfdt and DTC maintainer. Signed-off-by: NAlistair Francis <alistair.francis@wdc.com> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlexander Graf <agraf@csgraf.de> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 27 3月, 2019 3 次提交
-
-
由 Daniel P. Berrangé 提交于
Most of the seccomp functions return errnos as a negative return value. The code is currently ignoring these and reporting a generic error message for all seccomp failure scenarios making debugging painful. Report a more precise error from each failed call and include errno if it is available. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NEduardo Otubo <otubo@redhat.com>
-
由 Daniel P. Berrangé 提交于
The Mesa library tries to set process affinity on some of its threads in order to optimize its performance. Currently this results in QEMU being immediately terminated when seccomp is enabled. Mesa doesn't consider failure of the process affinity settings to be fatal to its operation, but our seccomp policy gives it no choice in gracefully handling this denial. It is reasonable to consider that malicious code using the resource control syscalls to be a less serious attack than if they were trying to spawn processes or change UIDs and other such things. Generally speaking changing the resource control setting will "merely" affect quality of service of processes on the host. With this in mind, rather than kill the process, we can relax the policy for these syscalls to return the EPERM errno value. This allows callers to detect that QEMU does not want them to change resource allocations, and apply some reasonable fallback logic. The main downside to this is for code which uses these syscalls but does not check the return value, blindly assuming they will always succeeed. Returning an errno could result in sub-optimal behaviour. Arguably though such code is already broken & needs fixing regardless. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: NEduardo Otubo <otubo@redhat.com>
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 26 3月, 2019 14 次提交
-
-
由 Peter Maydell 提交于
Block layer patches: - Fix slow pre-zeroing in qemu-img convert - Test case for block job pausing on I/O errors # gpg: Signature made Tue 26 Mar 2019 15:28:00 GMT # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: qemu-io: Add write -n for BDRV_REQ_NO_FALLBACK qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing file-posix: Support BDRV_REQ_NO_FALLBACK for zero writes block: Advertise BDRV_REQ_NO_FALLBACK in filter drivers block: Add BDRV_REQ_NO_FALLBACK block: Remove error messages in bdrv_make_zero() iotests: add 248: test resume mirror after auto pause on ENOSPC Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
fixes for 4.0: ohci and ati-vga # gpg: Signature made Tue 26 Mar 2019 14:05:40 GMT # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/fixes-20190326-pull-request: ati-vga: Fix indexed access to video memory ohci: don't die on ED_LINK_LIMIT overflow Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
target-arm queue: * Set SIMDMISC and FPMISC for 32-bit -cpu max (fixes regression from 3.1) * fix vCont packet handling when no thread is specified # gpg: Signature made Tue 26 Mar 2019 13:09:48 GMT # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20190326: gdbstub: fix vCont packet handling when no thread is specified target/arm: Set SIMDMISC and FPMISC for 32-bit -cpu max Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Luc Michel 提交于
The vCont packet accepts a series of actions, each being applied on a given thread ID. Giving no thread ID for an action is valid and means "all threads". This commit fixes vCont packets being incorrectly rejected when no thread ID was given for an action. In multiprocess mode, the GDB Remote Protocol specification is unclear on what "all threads" means. We choose to apply the action on all threads of all attached processes. This commit is based on the initial fix by Lucien Murray-Pitts. Fixes: e40e5204Reported-by: NLucien Murray-Pitts <lucienmp_antispam@yahoo.com> Reported-by: NJan Kiszka <jan.kiszka@siemens.com> Signed-off-by: NLuc Michel <luc.michel@greensocs.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-id: 20190325110452.6756-1-luc.michel@greensocs.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Richard Henderson 提交于
Fixes: https://bugs.launchpad.net/bugs/1821430Signed-off-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: NAlex Bennée <alex.bennee@linaro.org> Message-id: 20190325161338.6536-1-richard.henderson@linaro.org Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 BALATON Zoltan 提交于
Coverity (CID 1399700) found that this was wrong so instead of trying to do it by hand use existing access functions that should work better. Signed-off-by: NBALATON Zoltan <balaton@eik.bme.hu> Message-id: 20190318223842.427CB7456B2@zero.eik.bme.hu Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Laurent Vivier 提交于
Stop processing the descriptor list instead. The next frame timer tick will resume the work Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705Suggested-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NLaurent Vivier <lvivier@redhat.com> Message-id: 20190321085212.10796-1-lvivier@redhat.com Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Kevin Wolf 提交于
This makes the new BDRV_REQ_NO_FALLBACK flag available in the qemu-io write command. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Acked-by: NEric Blake <eblake@redhat.com>
-
由 Kevin Wolf 提交于
If qemu-img convert sees that the target image isn't zero-initialised yet, it tries to do an efficient zero write for the whole image first to save the overhead of repeated explicit zero writes during the conversion. Obviously, this provides only an advantage if the pre-zeroing is actually efficient. Otherwise, we can end up writing zeroes slowly while zeroing out the whole image, and then overwrite the same blocks again with real data, potentially doubling the written data. Pass BDRV_REQ_NO_FALLBACK to blk_make_zero() to avoid this case. If we can't efficiently zero out, we'll instead write explicit zeroes only if there is no data to be written to a block. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Acked-by: NEric Blake <eblake@redhat.com>
-
由 Kevin Wolf 提交于
We know that the kernel implements a slow fallback code path for BLKZEROOUT, so if BDRV_REQ_NO_FALLBACK is given, we shouldn't call it. The other operations we call in the context of .bdrv_co_pwrite_zeroes should usually be quick, so no modification should be needed for them. If we ever notice that there are additional problematic cases, we can still make these conditional as well. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Acked-by: NEric Blake <eblake@redhat.com>
-
由 Kevin Wolf 提交于
Filter drivers that support .bdrv_co_pwrite_zeroes can safely advertise BDRV_REQ_NO_FALLBACK because they just forward the request flags to their child node. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Acked-by: NEric Blake <eblake@redhat.com>
-
由 Kevin Wolf 提交于
For qemu-img convert, we want an operation that zeroes out the whole image if this can be done efficiently, but that returns an error otherwise so we don't write explicit zeroes and immediately overwrite them with the real data, potentially doubling the amount of data to be written. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Acked-by: NEric Blake <eblake@redhat.com>
-
由 Kevin Wolf 提交于
There is only a single caller of bdrv_make_zero(), which is qemu-img convert. If the function fails, we just fall back to a different method of zeroing out blocks on the target image. There is no good reason to print error messages on stderr when the higher level operation will actually succeed. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Acked-by: NEric Blake <eblake@redhat.com>
-
Test that mirror job actually resume on resume command after being automatically paused on ENOSPC error. It's a follow-up test for 8d9648cb "blockjob: fix user pause in block_job_error_action" Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Tested-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NJohn Snow <jsnow@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-