aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-10-22roms: add microvm-bios (qboot) as binary and git submoduleSergio Lopez
qboot is a minimalist x86 firmware for booting Linux kernels. It does the mininum amount of work required for the task, and it's able to boot both PVH images and bzImages without relying on option roms. This characteristics make it an ideal companion for the microvm machine type. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22hw/intc/apic: reject pic ints if isa_pic == NULLSergio Lopez
In apic_accept_pic_intr(), reject PIC interruptions if a i8259 PIC has not been instantiated (isa_pic == NULL). Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22fw_cfg: add "modify" functions for all typesSergio Lopez
This allows to alter the contents of an already added item. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2019-10-22hw/i386: make x86.c independent from PCMachineStateSergio Lopez
As a last step into splitting PCMachineState and deriving X86MachineState from it, make the functions previously extracted from pc.c to x86.c independent from PCMachineState, using X86MachineState instead. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22hw/i386: split PCMachineState deriving X86MachineState from itPaolo Bonzini
Split up PCMachineState and PCMachineClass and derive X86MachineState and X86MachineClass from them. This allows sharing code with non-PC x86 machine types. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22hw/i386/pc: move shared x86 functions to x86.c and export themSergio Lopez
Move x86 functions that will be shared between PC and non-PC machine types to x86.c, along with their helpers. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22hw/i386/pc: remove commented out code from x86_load_linux()Sergio Lopez
Follow checkpatch.pl recommendation and remove commented out code from x86_load_linux(). Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-22hw/i386/pc: avoid an assignment in if condition in x86_load_linux()Sergio Lopez
Follow checkpatch.pl recommendation and avoid an assignment in if condition in x86_load_linux(). Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-10-22hw/i386/pc: replace use of strtol with qemu_strtoui in x86_load_linux()Sergio Lopez
Follow checkpatch.pl recommendation and replace the use of strtol with qemu_strtoui in x86_load_linux(). Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2019-10-22hw/i386/pc: fix code style issues on functions that will be moved outSergio Lopez
Fix code style issues detected by checkpatch.pl on functions that will be moved out to x86.c. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2019-10-22hw/i386/pc: rename functions shared with non-PC machinesSergio Lopez
The following functions are named *pc* but are not PC-machine specific but generic to the X86 architecture, rename them: load_linux -> x86_load_linux pc_new_cpu -> x86_new_cpu pc_cpus_init -> x86_cpus_init pc_cpu_index_to_props -> x86_cpu_index_to_props pc_get_default_cpu_node_id -> x86_get_default_cpu_node_id pc_possible_cpu_arch_ids -> x86_possible_cpu_arch_ids old_pc_system_rom_init -> x86_system_rom_init Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22hw/virtio: Factorize virtio-mmio headersSergio Lopez
Put QOM and main struct definition in a separate header file, so it can be accessed from other components. Signed-off-by: Sergio Lopez <slp@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
2019-10-22memory-device: simplify Makefile.objs conditionsPaolo Bonzini
hw/mem/ is only included if CONFIG_MEM_DEVICE is true, so we need not specify the condition again in hw/mem/Makefile.objs. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22Do not use %m in common code to print error messagesThomas Huth
The %m format specifier is an extension from glibc - and when compiling QEMU for NetBSD, the compiler correctly complains, e.g.: /home/qemu/qemu-test.ELjfrQ/src/util/main-loop.c: In function 'sigfd_handler': /home/qemu/qemu-test.ELjfrQ/src/util/main-loop.c:64:13: warning: %m is only allowed in syslog(3) like functions [-Wformat=] printf("read from sigfd returned %zd: %m\n", len); ^ Let's use g_strerror() here instead, which is an easy-to-use wrapper around the thread-safe strerror_r() function. While we're at it, also convert the "printf()" in main-loop.c into the preferred "error_report()". Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20191018130716.25438-1-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22i386/kvm: add NoNonArchitecturalCoreSharing Hyper-V enlightenmentVitaly Kuznetsov
Hyper-V TLFS specifies this enlightenment as: "NoNonArchitecturalCoreSharing - Indicates that a virtual processor will never share a physical core with another virtual processor, except for virtual processors that are reported as sibling SMT threads. This can be used as an optimization to avoid the performance overhead of STIBP". However, STIBP is not the only implication. It was found that Hyper-V on KVM doesn't pass MD_CLEAR bit to its guests if it doesn't see NoNonArchitecturalCoreSharing bit. KVM reports NoNonArchitecturalCoreSharing in KVM_GET_SUPPORTED_HV_CPUID to indicate that SMT on the host is impossible (not supported of forcefully disabled). Implement NoNonArchitecturalCoreSharing support in QEMU as tristate: 'off' - the feature is disabled (default) 'on' - the feature is enabled. This is only safe if vCPUS are properly pinned and correct topology is exposed. As CPU pinning is done outside of QEMU the enablement decision will be made on a higher level. 'auto' - copy KVM setting. As during live migration SMT settings on the source and destination host may differ this requires us to add a migration blocker. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Message-Id: <20191018163908.10246-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22Updated Bulgarian translation (19) - 4.1.0Alexander Shopov
Signed-off-by: Alexander Shopov <ash@kambanaria.org> Message-Id: <20191019120534.27479-2-ash@kambanaria.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22mc146818rtc: fix timer interrupt reinjectionMarcelo Tosatti
commit 369b41359af46bded5799c9ef8be2b641d92e043 broke timer interrupt reinjection when there is no period change by the guest. In that case, old_period is 0, which ends up zeroing irq_coalesced (counter of reinjected interrupts). The consequence is Windows 7 is unable to synchronize time via NTP. Easily reproducible by playing a fullscreen video with cirrus and VNC. Fix by not updating s->irq_coalesced when old_period is 0. V2: reorganize code (Paolo Bonzini) Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Message-Id: <20191010123008.GA19158@amt.cnet> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-22target/i386: log MCE guest and host addressesMario Smarduch
Patch logs MCE AO, AR messages injected to guest or taken by QEMU itself. We print the QEMU address for guest MCEs, helps on hypervisors that have another source of MCE logging like mce log, and when they go missing. For example we found these QEMU logs: September 26th 2019, 17:36:02.309 Droplet-153258224: Guest MCE Memory Error at qemu addr 0x7f8ce14f5000 and guest 3d6f5000 addr of type BUS_MCEERR_AR injected qemu-system-x86_64 amsN ams3nodeNNNN September 27th 2019, 06:25:03.234 Droplet-153258224: Guest MCE Memory Error at qemu addr 0x7f8ce14f5000 and guest 3d6f5000 addr of type BUS_MCEERR_AR injected qemu-system-x86_64 amsN ams3nodeNNNN The first log had a corresponding mce log entry, the second didnt (logging thresholds) we can infer from second entry same PA and mce type. Signed-off-by: Mario Smarduch <msmarduch@digitalocean.com> Message-Id: <20191009164459.8209-3-msmarduch@digitalocean.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-10-18Merge remote-tracking branch ↵Peter Maydell
'remotes/kraxel/tags/audio-20191018-pull-request' into staging audio: bugfixes, pa connection and stream naming. audio: 5.1/7.1 support for alsa, pa and usb-audio. # gpg: Signature made Fri 18 Oct 2019 08:41:26 BST # 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/audio-20191018-pull-request: paaudio: fix channel order for usb-audio 5.1 and 7.1 streams usbaudio: change playback counters to 64 bit usb-audio: support more than two channels of audio usb-audio: do not count on avail bytes actually available audio: basic support for multichannel audio audio: replace shift in audio_pcm_info with bytes_per_frame audio: support more than two channels in volume setting paaudio: get/put_buffer functions audio: make mixeng optional audio: add mixing-engine option (documentation) audio: paaudio: ability to specify stream name audio: paaudio: fix connection and stream name audio: fix parameter dereference before NULL check Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-18Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into ↵Peter Maydell
staging pull request # gpg: Signature made Thu 17 Oct 2019 22:54:14 BST # gpg: using RSA key F9B7ABDBBCACDF95BE76CBD07DEF8106AAFC390E # gpg: Good signature from "John Snow (John Huston) <jsnow@redhat.com>" [full] # Primary key fingerprint: FAEB 9711 A12C F475 812F 18F2 88A9 064D 1835 61EB # Subkey fingerprint: F9B7 ABDB BCAC DF95 BE76 CBD0 7DEF 8106 AAFC 390E * remotes/jnsnow/tags/bitmaps-pull-request: dirty-bitmaps: remove deprecated autoload parameter MAINTAINERS: Add Vladimir as a reviewer for bitmaps qcow2-bitmap: move bitmap reopen-rw code to qcow2_reopen_commit block/qcow2-bitmap: fix and improve qcow2_reopen_bitmaps_rw iotests: add test 260 to check bitmap life after snapshot + commit block/qcow2-bitmap: do not remove bitmaps on reopen-ro block/qcow2-bitmap: drop qcow2_reopen_bitmaps_rw_hint() block/qcow2-bitmap: get rid of bdrv_has_changed_persistent_bitmaps iotests: add test-case to 165 to test reopening qcow2 bitmaps to RW block: reverse order for reopen commits block: switch reopen queue from QSIMPLEQ to QTAILQ block/dirty-bitmap: refactor bdrv_dirty_bitmap_next block/dirty-bitmap: drop BdrvDirtyBitmap.mutex block/dirty-bitmap: add bs link block/dirty-bitmap: drop meta block/qcow2: proper locking on bitmap add/remove paths block/dirty-bitmap: return int from bdrv_remove_persistent_dirty_bitmap block: move bdrv_can_store_new_dirty_bitmap to block/dirty-bitmap.c util/hbitmap: strict hbitmap_reset Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-18Merge remote-tracking branch 'remotes/kraxel/tags/ui-20191018-pull-request' ↵Peter Maydell
into staging ui: bugfixes for cocoa, curses and input-barrier. # gpg: Signature made Fri 18 Oct 2019 11:16:53 BST # 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/ui-20191018-pull-request: ui: fix keymap file search in input-barrier object curses: correctly pass the color pair to setcchar() curses: use the bit mask constants provided by curses ui: Fix hanging up Cocoa display on macOS 10.15 (Catalina) Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-10-18ui: fix keymap file search in input-barrier objectLaurent Vivier
If we try to start QEMU with "-k en-us", qemu prints a message and exits with: qemu-system-i386: could not read keymap file: 'en-us' It's because this function is called way too early, before qemu_add_data_dir() is called, and so qemu_find_file() fails. To fix that, move init_keyboard_layout() from the class init function to the instance init function. Reported-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-id: 20190923220658.27007-1-laurent@vivier.eu Fixes: 6105683da35b ("ui: add an embedded Barrier client") Signed-off-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18curses: correctly pass the color pair to setcchar()Matthew Kilgore
The current code does not correctly pass the color pair information to setcchar(), it instead always passes zero. This results in the curses output always being in white on black. This patch fixes this by using PAIR_NUMBER() to retrieve the color pair number from the chtype value, and then passes that value as an argument to setcchar(). Signed-off-by: Matthew Kilgore <mattkilgore12@gmail.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Message-id: 20191004035338.25601-3-mattkilgore12@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18curses: use the bit mask constants provided by cursesMatthew Kilgore
The curses API provides the A_ATTRIBUTES and A_CHARTEXT bit masks for getting the attributes and character parts of a chtype, respectively. We should use provided constants instead of using 0xff. Signed-off-by: Matthew Kilgore <mattkilgore12@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Message-id: 20191004035338.25601-2-mattkilgore12@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18ui: Fix hanging up Cocoa display on macOS 10.15 (Catalina)Hikaru Nishida
macOS API documentation says that before applicationDidFinishLaunching is called, any events will not be processed. However, some events are fired before it is called in macOS Catalina. This causes deadlock of iothread_lock in handleEvent while it will be released after the app_started_sem is posted. This patch avoids processing events before the app_started_sem is posted to prevent this deadlock. Buglink: https://bugs.launchpad.net/qemu/+bug/1847906 Signed-off-by: Hikaru Nishida <hikarupsp@gmail.com> Message-id: 20191015010734.85229-1-hikarupsp@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18paaudio: fix channel order for usb-audio 5.1 and 7.1 streamsKővágó, Zoltán
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 2900e462d27bd73277ae083d037c32b1b4451ee2.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18usbaudio: change playback counters to 64 bitKővágó, Zoltán
With stereo playback, they need about 375 minutes of continuous audio playback to overflow, which is usually not a problem (as stopping and later resuming playback resets the counters). But with 7.1 audio, they only need about 95 minutes to overflow. After the overflow, the buf->prod % USBAUDIO_PACKET_SIZE(channels) assertion no longer holds true, which will result in overflowing the buffer. With 64 bit variables, it would take about 762000 years to overflow. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: ff866985ed369f1e18ea7c70da6a7fce8e241deb.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18usb-audio: support more than two channels of audioKővágó, Zoltán
This commit adds support for 5.1 and 7.1 audio playback. This commit adds a new property to usb-audio: * multi=on|off Whether to enable the 5.1 and 7.1 audio support. When off (default) it continues to emulate the old stereo-only device. When on, it emulates a slightly different audio device that supports 5.1 and 7.1 audio. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 98e96606228afa907fa238eac26573d5af63434a.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18usb-audio: do not count on avail bytes actually availableKővágó, Zoltán
This assumption is no longer true when mixeng is turned off. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: d63f4d39a0ee7a2e4e7e4a2eb005ba79120eaf1d.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: basic support for multichannel audioKővágó, Zoltán
Which currently only means removing some checks. Old code won't require more than two channels, but new code will need it. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 7e53be1f97e939ed3bb729ef39e76b775643118a.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: replace shift in audio_pcm_info with bytes_per_frameKővágó, Zoltán
The bit shifting trick worked because the number of bytes per frame was always a power-of-two (since QEMU only supports mono, stereo and 8, 16 and 32 bit samples). But if we want to add support for surround sound, this no longer holds true. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 1351fd9bcce0ff20d81850c5292722194329de02.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: support more than two channels in volume settingKővágó, Zoltán
Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 5d3dd2ee3baaa62805e79c3901abb7415ae32461.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18paaudio: get/put_buffer functionsKővágó, Zoltán
This lets us avoid some buffer copying when using mixeng. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: d03d30138b9b5a9681cc90cbfbfec0a197cac88c.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: make mixeng optionalKővágó, Zoltán
Implementation of the previously added mixing-engine option. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: c05bc258889ed289e8ee1bdbcc5e84174ec221e7.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: add mixing-engine option (documentation)Kővágó, Zoltán
This will allow us to disable mixeng when we use a decent backend. Disabling mixeng have a few advantages: * we no longer convert the audio output from one format to another, when the underlying audio system would just convert it to a third format. We no longer convert, only the underlying system, when needed. * the underlying system probably has better resampling and sample format converting methods anyway... * we may support formats that the mixeng currently does not support (S24 or float samples, more than two channels) * when using an audio server (like pulseaudio) different sound card outputs will show up as separate streams, even if we use only one backend Disadvantages: * audio capturing no longer works (wavcapture, and vnc audio extension) * some backends only support a single playback stream or very picky about the audio format. In this case we can't disable mixeng. Originally thw two main use cases of the disabled option was: using unsupported audio formats (5.1 and 7.1 audio) and having different pulseaudio streams per audio frontend. Since we can have multiple -audiodevs, the latter is not that important, so currently you only need this option if you want to use 5.1 or 7.1 audio (implemented in a later patch), otherwise it's probably better to stick to the old and tried mixeng, since it's less picky about the backends. The ideal solution would be to port as much as possible to gstreamer, but this is currently out of scope: https://wiki.qemu.org/Internships/ProjectIdeas/AudioGStreamer Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 5765186a7aadd51a72bc7d3e804307f0ee8a34ce.1570996490.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: paaudio: ability to specify stream nameKővágó, Zoltán
This can be used to identify stream in tools like pavucontrol when one creates multiple -audiodevs or runs multiple qemu instances. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Acked-by: Markus Armbruster <armbru@redhat.com> Message-id: 2d6e337c474ac84172d0809e6959c26b21d48120.1568157545.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: paaudio: fix connection and stream nameKővágó, Zoltán
Connection name was previously erroneously set to the server socket path, while connection names were simply "qemu". After this patch, the connection name will be the vm name (falling back to "qemu" if not specified), while stream names will be the audiodev's id. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 3d139426031a400a68d440608ba5e43f0e116cd8.1568157545.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-18audio: fix parameter dereference before NULL checkKővágó, Zoltán
This should fix Coverity issues CID 1405305 and 1405301. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu@gmail.com> Message-id: 0eadcc88b8421bb86ce2d68ac70517f920c3ad6c.1568157545.git.DirtY.iCE.hu@gmail.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2019-10-17dirty-bitmaps: remove deprecated autoload parameterJohn Snow
This parameter has been deprecated since 2.12.0 and is eligible for removal. Remove this parameter as it is actually completely ignored; let's not give false hope. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20191002232411.29968-1-jsnow@redhat.com
2019-10-17MAINTAINERS: Add Vladimir as a reviewer for bitmapsJohn Snow
I already try to make sure all bitmaps patches have been reviewed by both Red Hat and Virtuozzo anyway, so this formalizes the arrangement. Fam meanwhile is no longer as active, so I am removing him as a co-maintainer simply to reflect the current practice. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20191005194448.16629-2-jsnow@redhat.com
2019-10-17qcow2-bitmap: move bitmap reopen-rw code to qcow2_reopen_commitVladimir Sementsov-Ogievskiy
The only reason I can imagine for this strange code at the very-end of bdrv_reopen_commit is the fact that bs->read_only updated after calling drv->bdrv_reopen_commit in bdrv_reopen_commit. And in the same time, prior to previous commit, qcow2_reopen_bitmaps_rw did a wrong check for being writable, when actually it only need writable file child not self. So, as it's fixed, let's move things to correct place. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Acked-by: Max Reitz <mreitz@redhat.com> Message-id: 20190927122355.7344-10-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17block/qcow2-bitmap: fix and improve qcow2_reopen_bitmaps_rwVladimir Sementsov-Ogievskiy
- Correct check for write access to file child, and in correct place (only if we want to write). - Support reopen rw -> rw (which will be used in following commit), for example, !bdrv_dirty_bitmap_readonly() is not a corruption if bitmap is marked IN_USE in the image. - Consider unexpected bitmap as a corruption and check other combinations of in-image and in-RAM bitmaps. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190927122355.7344-9-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17iotests: add test 260 to check bitmap life after snapshot + commitVladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190927122355.7344-8-vsementsov@virtuozzo.com [Maintainer edit: removed 260 from auto group per Peter Maydell. --js] Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17block/qcow2-bitmap: do not remove bitmaps on reopen-roVladimir Sementsov-Ogievskiy
qcow2_reopen_bitmaps_ro wants to store bitmaps and then mark them all readonly. But the latter don't work, as qcow2_store_persistent_dirty_bitmaps removes bitmaps after storing. It's OK for inactivation but bad idea for reopen-ro. And this leads to the following bug: Assume we have persistent bitmap 'bitmap0'. Create external snapshot bitmap0 is stored and therefore removed Commit snapshot now we have no bitmaps Do some writes from guest (*) they are not marked in bitmap Shutdown Start bitmap0 is loaded as valid, but it is actually broken! It misses writes (*) Incremental backup it will be inconsistent So, let's stop removing bitmaps on reopen-ro. But don't rejoice: reopening bitmaps to rw is broken too, so the whole scenario will not work after this patch and we can't enable corresponding test cases in 260 iotests still. Reopening bitmaps rw will be fixed in the following patches. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20190927122355.7344-7-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17block/qcow2-bitmap: drop qcow2_reopen_bitmaps_rw_hint()Vladimir Sementsov-Ogievskiy
The function is unused, drop it. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20190927122355.7344-6-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17block/qcow2-bitmap: get rid of bdrv_has_changed_persistent_bitmapsVladimir Sementsov-Ogievskiy
Firstly, no reason to optimize failure path. Then, function name is ambiguous: it checks for readonly and similar things, but someone may think that it will ignore normal bitmaps which was just unchanged, and this is in bad relation with the fact that we should drop IN_USE flag for unchanged bitmaps in the image. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20190927122355.7344-5-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17iotests: add test-case to 165 to test reopening qcow2 bitmaps to RWVladimir Sementsov-Ogievskiy
Reopening bitmaps to RW was broken prior to previous commit. Check that it works now. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190927122355.7344-4-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17block: reverse order for reopen commitsVladimir Sementsov-Ogievskiy
It's needed to fix reopening qcow2 with bitmaps to RW. Currently it can't work, as qcow2 needs write access to file child, to mark bitmaps in-image with IN_USE flag. But usually children goes after parents in reopen queue and file child is still RO on qcow2 reopen commit. Reverse reopen order to fix it. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Acked-by: Max Reitz <mreitz@redhat.com> Acked-by: John Snow <jsnow@redhat.com> Message-id: 20190927122355.7344-3-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17block: switch reopen queue from QSIMPLEQ to QTAILQVladimir Sementsov-Ogievskiy
We'll need reverse-foreach in the following commit, QTAILQ support it, so move to QTAILQ. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-id: 20190927122355.7344-2-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
2019-10-17block/dirty-bitmap: refactor bdrv_dirty_bitmap_nextVladimir Sementsov-Ogievskiy
bdrv_dirty_bitmap_next is always used in same pattern. So, split it into _next and _first, instead of combining two functions into one and add FOR_EACH_DIRTY_BITMAP macro. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: John Snow <jsnow@redhat.com> Message-id: 20190916141911.5255-5-vsementsov@virtuozzo.com Signed-off-by: John Snow <jsnow@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-02-17 03:33:07 +0000