aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-03-22slirp: relicense GPL files to BSD-3Marc-André Lureau
In order to make slirp a standalone project, the project must have a clear license, and be compatible with the GPL or LGPL. Since commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec ("Remove the advertising clause from the slirp license"), slirp is BSD-3. But new files have been added under slirp/ with QEMU GPL license since then. The copyright holders have been asked to relicense files to BSD-3 and gave their permission: - slirp/dhcpv6.{c,h} Subject: Re: Clearing slirp/ license To: "Marc-André Lureau" <marcandre.lureau@gmail.com>, QEMU <qemu-devel@nongnu.org>, Thomas Huth <thuth@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org>, Samuel Thibault <samuel.thibault@ens-lyon.org> References: <CAJ+F1CKBRNdLPb_wOLhURdUJd-j1RHY2toKSTEhCBt_zs4Xk1w@mail.gmail.com> From: "Cédric Le Goater" <clg@kaod.org> Message-ID: <e942cdab-fe1b-fdf4-3b9f-da16a4afa953@kaod.org> Date: Mon, 11 Mar 2019 16:23:25 +0100 > Could you reply that you have no objection in relicensing those files > are 3-Clause BSD? Fine for me. You can change the license of slirp/ncsi.c and slirp/ncsi-pkt.hto a 3-Clause BSD. Thanks, C. Subject: Re: [Qemu-devel] Clearing slirp/ license To: Peter Maydell <peter.maydell@linaro.org>, Shan Gavin <shan.gavin@gmail.com> Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, "Marc-André Lureau" <marcandre.lureau@gmail.com>, Gavin Shan <gwshan@linux.vnet.ibm.com>, Thomas Huth <thuth@redhat.com>, QEMU <qemu-devel@nongnu.org>, Samuel Thibault <samuel.thibault@ens-lyon.org> References: <CAJ+F1CKBRNdLPb_wOLhURdUJd-j1RHY2toKSTEhCBt_zs4Xk1w@mail.gmail.com> <e942cdab-fe1b-fdf4-3b9f-da16a4afa953@kaod.org> <CAJ+F1C+hFfsa5gcSdttTP5J+uyDvNdYJWrm9OJM26+Zc1ZQkew@mail.gmail.com> <cc62e1fd-c564-e1b7-d10c-30665b481352@ozlabs.ru> <CAOL5TwkQXhPjdPP9v7n7mxAVxbDCSo6MEaG+E-Xys=MoD_pg2g@mail.gmail.com> <CAFEAcA_g=L2LSo=B_5dpJhJJrqFiOb6sswMVohQwpVGiKi_A7w@mail.gmail.com> From: "Cédric Le Goater" <clg@kaod.org> Message-ID: <4ddf6031-0df1-b3b5-965e-a181266e42b0@kaod.org> Date: Tue, 12 Mar 2019 11:49:21 +0100 > Is the code in question copyright you personally, or copyright > IBM as your employer at the time ? If the latter, it is IBM that > would need to approve the relicensing. That was done. I had our legal team approve the change of license. Thanks, C. From: Shan Gavin <shan.gavin@gmail.com> Date: Tue, 12 Mar 2019 15:04:54 +0800 Message-ID: <CAOL5TwkQXhPjdPP9v7n7mxAVxbDCSo6MEaG+E-Xys=MoD_pg2g@mail.gmail.com> Subject: Re: [Qemu-devel] Clearing slirp/ license To: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>, "Cédric Le Goater" <clg@kaod.org>, gwshan@linux.vnet.ibm.com, Peter Maydell <peter.maydell@linaro.org>, Thomas Huth <thuth@redhat.com>, QEMU <qemu-devel@nongnu.org>, Samuel Thibault <samuel.thibault@ens-lyon.org> > Gavin, could you reply that you have no objection in relicensing > ncsi-pkt.h as 3-Clause BSD? No objection. Please go ahead with the relicensing. Cheers, Gavin - ncsi.c, ncsi-pkt.h Subject: Re: Clearing slirp/ license To: "Marc-André Lureau" <marcandre.lureau@gmail.com>, QEMU <qemu-devel@nongnu.org>, "Cédric Le Goater" <clg@kaod.org> Cc: Peter Maydell <peter.maydell@linaro.org>, Samuel Thibault <samuel.thibault@ens-lyon.org> References: <CAJ+F1CKBRNdLPb_wOLhURdUJd-j1RHY2toKSTEhCBt_zs4Xk1w@mail.gmail.com> From: Thomas Huth <thuth@redhat.com> Message-ID: <ed5a9f55-f2e5-298d-58ac-414759e9b491@redhat.com> Date: Wed, 13 Feb 2019 12:30:32 +0100 > Could you reply that you have no objection in relicensing those files > are 3-Clause BSD? Ok, for the records: I'm fine if you change the license of dhcpv6.[ch] to either 3-Clause BSD or 2-Clause BSD. Thomas - vmstate.{c,h} From: Juan Quintela <quintela@redhat.com> To: "Marc-André Lureau" <marcandre.lureau@gmail.com> Cc: QEMU <qemu-devel@nongnu.org>, Peter Maydell <peter.maydell@linaro.org>, Samuel Thibault <samuel.thibault@ens-lyon.org> Subject: Re: Clearing slirp/ license Date: Tue, 12 Mar 2019 12:43:17 +0100 Message-ID: <87k1h4qpwq.fsf@trasno.org> > Juan, Could you reply that you have no objection in relicensing the > vmstate files as 3-Clause BSD? No problem at all on my side. Later, Juan. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> [ for the NC-SI files ] Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Thomas Huth <thuth@redhat.com>
2019-03-22slirp: update COPYRIGHT to use full 3-Clause BSD LicenseMarc-André Lureau
According to commit 2f5f89963186d42a7ded253bc6cf5b32abb45cec ("Remove the advertising clause from the slirp license"), Danny Gasparovski gave permission to license slirp code under 3-clause BSD license: Subject: RE: Slirp license Date: Thu, 8 Jan 2009 10:51:00 +1100 From: "Gasparovski, Daniel" <Daniel.Gasparovski@ato.gov.au> To: "Richard Fontana" <rfontana@redhat.com> I have no objection to having Slirp code in QEMU be licensed under the 3-clause BSD license. slirp/COPYRIGHT's initial version in 2004 (commit 5fafdf24) listed only 3 clauses BUT used the poisonous advertising clause for clause 3 which is the controversial clause of non-free 4-clause (that is, it appears that the BSD-4 license was copied, and then the WRONG clause was deleted, when creating COPYRIGHT. Perhaps explained as an easy mistake to make since 3-clause was created by removing clause 3 of the 4-clause, where you sometimes see the three-clause version with clauses 1, 2, 4; but more commonly see a renumbered version with clauses 1, 2, 3 to close the gap. If you pay attention only to clause numbers instead of content, it can be easy to confuse which clause to delete to go from 4-clause to 3-clause). Commit 2f5f89963 removed the poisonous wrong clause on the grounds of moving from 4-clause to 3-clause; but did not add the missing clause, which makes it LOOK like the 2-clause version. But I think we have a decent enough trail showing the intent for 3-clause. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2019-03-22trace-events: Fix attribution of trace points to sourceMarkus Armbruster
Some trace points are attributed to the wrong source file. Happens when we neglect to update trace-events for code motion, or add events in the wrong place, or misspell the file name. Clean up with help of cleanup-trace-events.pl. Same funnies as in the previous commit, of course. Manually shorten its change to linux-user/trace-events to */signal.c. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-id: 20190314180929.27722-6-armbru@redhat.com Message-Id: <20190314180929.27722-6-armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22trace-events: Delete unused trace pointsMarkus Armbruster
Tracked down with cleanup-trace-events.pl. Funnies requiring manual post-processing: * block.c and blockdev.c trace points are in block/trace-events. * hw/block/nvme.c uses the preprocessor to hide its trace point use from cleanup-trace-events.pl. * include/hw/xen/xen_common.h trace points are in hw/xen/trace-events. * net/colo-compare and net/filter-rewriter.c use pseudo trace points colo_compare_udp_miscompare and colo_filter_rewriter_debug to guard debug code. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-id: 20190314180929.27722-5-armbru@redhat.com Message-Id: <20190314180929.27722-5-armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22scripts/cleanup-trace-events: Update for current practiceMarkus Armbruster
Emit comments with shortened file names (previous commit). Limit search to the input file's directory. Cope with properties tcg (commit b2b36c22bd8) and vcpu (commit 3d211d9f4db). Cope with capital letters in function names. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-id: 20190314180929.27722-4-armbru@redhat.com Message-Id: <20190314180929.27722-4-armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22trace-events: Shorten file names in commentsMarkus Armbruster
We spell out sub/dir/ in sub/dir/trace-events' comments pointing to source files. That's because when trace-events got split up, the comments were moved verbatim. Delete the sub/dir/ part from these comments. Gets rid of several misspellings. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190314180929.27722-3-armbru@redhat.com Message-Id: <20190314180929.27722-3-armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22trace-events: Consistently point to docs/devel/tracing.txtMarkus Armbruster
Almost all trace-events point to docs/devel/tracing.txt in a comment right at the beginning. Touch up the ones that don't. [Updated with Markus' new commit description wording. --Stefan] Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190314180929.27722-2-armbru@redhat.com Message-Id: <20190314180929.27722-2-armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22trace: avoid SystemTap dtrace(1) warnings on empty filesStefan Hajnoczi
target/hppa/trace-events only contains disabled events, resulting in a trace-dtrace.dtrace file that says "provider qemu {}". SystemTap's dtrace(1) tool prints a warning when processing this input file. This patch avoids the error by emitting an empty file instead of "provider qemu {}" when there are no enabled trace events. Fixes: 23c3d569f44284066714ff7c46bc4f19e630583f ("target/hppa: add TLB trace events") Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 20190321170831.6539-3-stefanha@redhat.com Message-Id: <20190321170831.6539-3-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22trace: handle tracefs path truncationStefan Hajnoczi
If the tracefs mountpoint has a very long path we may exceed PATH_MAX. This is a system misconfiguration and the user must resolve it so that applications can perform path-based system calls successfully. This issue does not occur on real-world systems since tracefs is mounted on /sys/kernel/debug/tracing/, but the compiler is smart enough to foresee the possibility and warn about the unchecked snprintf(3) return value. This patch fixes the compiler warning. Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Message-id: 20190321170831.6539-2-stefanha@redhat.com Message-Id: <20190321170831.6539-2-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2019-03-22Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' ↵Peter Maydell
into staging x86 queue for -rc1 A few fixes that missed -rc0: * CPU model documentation updates (Daniel P. Berrangé) * Fix bogus OSPKE warnings (Eduardo Habkost) * Work around KVM bugs when handing arch_capabilities (Eduardo Habkost) # gpg: Signature made Thu 21 Mar 2019 19:32:02 GMT # gpg: using RSA key 2807936F984DC5A6 # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-next-pull-request: docs: add note about stibp CPU feature for spectre v2 docs: clarify that spec-ctrl is only needed for Spectre v2 i386: Disable OSPKE on CPU model definitions i386: Make arch_capabilities migratable i386: kvm: Disable arch_capabilities if MSR can't be set Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-22target/riscv: Zero extend the inputs of divuw and remuwPalmer Dabbelt
While running the GCC test suite against 4.0.0-rc0, Kito found a regression introduced by the decodetree conversion that caused divuw and remuw to sign-extend their inputs. The ISA manual says they are supposed to be zero extended: DIVW and DIVUW instructions are only valid for RV64, and divide the lower 32 bits of rs1 by the lower 32 bits of rs2, treating them as signed and unsigned integers respectively, placing the 32-bit quotient in rd, sign-extended to 64 bits. REMW and REMUW instructions are only valid for RV64, and provide the corresponding signed and unsigned remainder operations respectively. Both REMW and REMUW always sign-extend the 32-bit result to 64 bits, including on a divide by zero. Here's Kito's reduced test case from the GCC test suite unsigned calc_mp(unsigned mod) { unsigned a,b,c; c=-1; a=c/mod; b=0-a*mod; if (b > mod) { a += 1; b-=mod; } return b; } int main(int argc, char *argv[]) { unsigned x = 1234; unsigned y = calc_mp(x); if ((sizeof (y) == 4 && y != 680) || (sizeof (y) == 2 && y != 134)) abort (); exit (0); } I haven't done any other testing on this, but it does fix the test case. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-21target/xtensa: fix break_dependency for repeated resourcesMax Filippov
break_dependency incorrectly handles the case of dependency on an opcode that references the same register multiple times. E.g. the following instruction is translated incorrectly: { or a2, a3, a3 ; or a3, a2, a2 } This happens because resource indices of both dependency graph nodes are incremented, and a copy for the second instance of the same register in the ending node is not done. Only increment resource index of the ending node of the dependency. Add test. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2019-03-21virtio-vga: only enable for specific boardsPaolo Bonzini
When virtio-vga was added, the intention was to only support it for those machines where the firmware does not know about virtio-gpu, and supported VGA legacy hardware before virtio-{gpu,vga} were introduced. The Kconfig switch however enabled virtio-vga for all machines with a PCI bus, and libvirt then prefers it even on hardware where virtio-gpu would be preferrable. At least for now, only enable virtio-vga for PC, hppa and pSeries machines, as was the case before Kconfig dependencies were introduced. Reported-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-21Merge remote-tracking branch 'remotes/berrange/tags/authz-next-pull-request' ↵Peter Maydell
into staging Fix object interface check macro usage # gpg: Signature made Thu 21 Mar 2019 11:53:15 GMT # gpg: using RSA key BE86EBB415104FDF # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full] # gpg: aka "Daniel P. Berrange <berrange@redhat.com>" [full] # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF * remotes/berrange/tags/authz-next-pull-request: authz: Use OBJECT_CHECK() on objects Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-21Merge remote-tracking branch ↵Peter Maydell
'remotes/berrange/tags/qcrypto-next-pull-request' into staging Avoid struct packing warnings with gcc9 # gpg: Signature made Thu 21 Mar 2019 11:55:03 GMT # gpg: using RSA key BE86EBB415104FDF # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full] # gpg: aka "Daniel P. Berrange <berrange@redhat.com>" [full] # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF * remotes/berrange/tags/qcrypto-next-pull-request: crypto/block: remove redundant struct packing to fix build with gcc 9 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-21crypto/block: remove redundant struct packing to fix build with gcc 9Greg Kurz
Build fails with gcc 9: crypto/block-luks.c:689:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 689 | be32_to_cpus(&luks->header.payload_offset); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ crypto/block-luks.c:690:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 690 | be32_to_cpus(&luks->header.key_bytes); | ^~~~~~~~~~~~~~~~~~~~~~~ crypto/block-luks.c:691:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 691 | be32_to_cpus(&luks->header.master_key_iterations); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... a bunch of similar errors... crypto/block-luks.c:1288:22: error: taking address of packed member of ‘struct QCryptoBlockLUKSKeySlot’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 1288 | be32_to_cpus(&luks->header.key_slots[i].stripes); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors All members of the QCryptoBlockLUKSKeySlot and QCryptoBlockLUKSHeader are naturally aligned and we already check at build time there isn't any unwanted padding. Drop the QEMU_PACKED attribute. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-21authz: Use OBJECT_CHECK() on objectsPhilippe Mathieu-Daudé
TYPE_QAUTHZ is an abstract object of type TYPE_OBJECT. All other are children of TYPE_QAUTHZ, thus also objects. Keep INTERFACE_CHECK() for interfaces, and use OBJECT_CHECK() on objects. Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-21Merge remote-tracking branch 'remotes/berrange/tags/qio-next-pull-request' ↵Peter Maydell
into staging Merge I/O patch queue Fix problem with end of file handling with websock channels # gpg: Signature made Wed 20 Mar 2019 16:57:15 GMT # gpg: using RSA key BE86EBB415104FDF # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full] # gpg: aka "Daniel P. Berrange <berrange@redhat.com>" [full] # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF * remotes/berrange/tags/qio-next-pull-request: io: fix handling of EOF / error conditions in websock GSource Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-20io: fix handling of EOF / error conditions in websock GSourceDaniel P. Berrangé
We were never reporting the G_IO_HUP event when an end of file was hit on the websocket channel. We also didn't report G_IO_ERR when we hit a fatal error processing the websocket protocol. The latter in particular meant that the chardev code would not notice when an eof/error was encountered on the websocket channel, unless the guest OS happened to trigger a write operation. This meant that once the first client had quit, the chardev would never listen to accept a new client. Fixes launchpad bug 1816819 Acked-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-20docs: add note about stibp CPU feature for spectre v2Daniel P. Berrangé
While the stibp CPU feature is not commonly used by guest OS for spectre mitigation due to its performance impact, it is none the less best practice to expose it to all guest OS. This allows the guest OS to decide whether to make use or it. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20190307121838.6345-3-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-20docs: clarify that spec-ctrl is only needed for Spectre v2Daniel P. Berrangé
The docs currently say that the spec-ctrl feature is needed for both Spectre variants, but it is only used to address Spectre v2. Also remove the note about retpolines. The guest OS is usually treated as a blackbox from host mgmt pov, so it won't have knowledge about use of retpolines and thus should unconditionally expose spec-ctrl, allowing the guest to decide whether to use it or not. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20190307121838.6345-2-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-20i386: Disable OSPKE on CPU model definitionsEduardo Habkost
Currently, the Cascadelake-Server, Icelake-Client, and Icelake-Server are always generating the following warning: qemu-system-x86_64: warning: \ host doesn't support requested feature: CPUID.07H:ECX [bit 4] This happens because OSPKE was never returned by GET_SUPPORTED_CPUID or x86_cpu_get_supported_feature_word(). OSPKE is a runtime flag automatically set by the KVM module or by TCG code, was always cleared by x86_cpu_filter_features(), and was not supposed to appear on the CPU model table. Remove the OSPKE flag from the CPU model table entries, to avoid the bogus warning and avoid returning invalid feature data on query-cpu-* QMP commands. As OSPKE was always cleared by x86_cpu_filter_features(), this won't have any guest-visible impact. Include a test case that should detect the problem if we introduce a similar bug again. Fixes: c7a88b52f62b ("i386: Add new model of Cascadelake-Server") Fixes: 8a11c62da914 ("i386: Add new CPU model Icelake-{Server,Client}") Cc: Tao Xu <tao3.xu@intel.com> Cc: Robert Hoo <robert.hu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190319200515.14999-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-20i386: Make arch_capabilities migratableEduardo Habkost
Now that kvm_arch_get_supported_cpuid() will only return arch_capabilities if QEMU is able to initialize the MSR properly, we know that the feature is safely migratable. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190125220606.4864-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-20i386: kvm: Disable arch_capabilities if MSR can't be setEduardo Habkost
KVM has two bugs in the handling of MSR_IA32_ARCH_CAPABILITIES: 1) Linux commit commit 1eaafe91a0df ("kvm: x86: IA32_ARCH_CAPABILITIES is always supported") makes GET_SUPPORTED_CPUID return arch_capabilities even if running on SVM. This makes "-cpu host,migratable=off" incorrectly expose arch_capabilities on CPUID on AMD hosts (where the MSR is not emulated by KVM). 2) KVM_GET_MSR_INDEX_LIST does not return MSR_IA32_ARCH_CAPABILITIES if the MSR is not supported by the host CPU. This makes QEMU not initialize the MSR properly at kvm_put_msrs() on those hosts. Work around both bugs on the QEMU side, by checking if the MSR was returned by KVM_GET_MSR_INDEX_LIST before returning the feature flag on kvm_arch_get_supported_cpuid(). This has the unfortunate side effect of making arch_capabilities unavailable on hosts without hardware support for the MSR until bug #2 is fixed on KVM, but I can't see another way to work around bug #1 without that side effect. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20190125220606.4864-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-03-20config-all-devices.mak: rebuild on reconfigurePaolo Bonzini
This ensures that softmmu directories are culled after a "./configure --target-list=x86_64-linux-user". Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20minikconf: fix parser typoPaolo Bonzini
The result of this typo would be that "select_foo" would be treated as a "select" keyword followed by "_foo". Nothing too bad, but easy to fix so let's be clean. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20intel-iommu: optimize nodmar memory regionsPeter Xu
Previously we have per-device system memory aliases when DMAR is disabled by the system. It will slow the system down if there are lots of devices especially when DMAR is disabled, because each of the aliased system address space will contain O(N) slots, and rendering such N address spaces will be O(N^2) complexity. This patch introduces a shared nodmar memory region and for each device we only create an alias to the shared memory region. With the aliasing, QEMU memory core API will be able to detect when devices are sharing the same address space (which is the nodmar address space) when rendering the FlatViews and the total number of FlatViews can be dramatically reduced when there are a lot of devices. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20190313094323.18263-1-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20test-announce-self: convert to qgraphPaolo Bonzini
This removes the duplicated initialization code. Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/alpha/Kconfig: DP264 hardware requires e1000 network cardPhilippe Mathieu-Daudé
This fixes when configuring with CONFIG_PCI_DEVICES=n: $ qemu-system-alpha qemu-system-alpha: Unsupported NIC model: e1000 Fixes: d1a95ef4ac Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-15-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/hppa/Kconfig: Dino board requires e1000 network cardPhilippe Mathieu-Daudé
This fixes when configuring with CONFIG_PCI_DEVICES=n: $ qemu-system-hppa qemu-system-hppa: Unsupported NIC model: e1000 Fixes: 9483cf27dd Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-14-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/sh4/Kconfig: r2d machine requires the rtl8139 network cardPhilippe Mathieu-Daudé
This fixes when configuring with CONFIG_PCI_DEVICES=n: $ qemu-system-sh4 -M r2d qemu-system-sh4: Unsupported NIC model: rtl8139 Fixes: 7ab58d4c84 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-13-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/ppc/Kconfig: e500 based machines require virtio-net-pci devicePhilippe Mathieu-Daudé
This fixes when configuring with CONFIG_PCI_DEVICES=n: $ qemu-system-ppc64 -bios /dev/null -M ppce500 qemu-system-ppc64: Unsupported NIC model: virtio-net-pci And: $ qemu-system-ppc64 -bios /dev/null -M mpc8544ds qemu-system-ppc64: Unsupported NIC model: virtio-net-pci Fixes: 98bd1db99f Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190316200818.8265-10-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/ppc/Kconfig: Bamboo machine requires e1000 network cardPhilippe Mathieu-Daudé
This fixes when configuring with CONFIG_PCI_DEVICES=n: $ qemu-system-ppc64 -bios /dev/null -M bamboo qemu-system-ppc64: Unsupported NIC model: e1000 Fixes: 7c28b925b7e Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20190316200818.8265-9-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/mips/Kconfig: Fulong 2e board requires ati-vga/rtl8139 PCI devicesPhilippe Mathieu-Daudé
This fixes when configuring with --without-default-devices: $ qemu-system-mips64el -bios /dev/null -M fulong2e qemu-system-mips64el: Unknown device 'ati-vga' for bus 'PCI' Aborted (core dumped) (gdb) bt #0 0x00007ffff5a2753f in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff5a11895 in __GI_abort () at abort.c:79 #2 0x00005555558768d3 in qdev_create (bus=bus@entry=0x5555562664b0, name=name@entry=0x555555b24efb "ati-vga") at hw/core/qdev.c:131 #3 0x00005555558d15e1 in pci_create_multifunction (bus=bus@entry=0x5555562664b0, devfn=devfn@entry=-1, multifunction=multifunction@entry=false, name=name@entry=0x555555b24efb "ati-vga") at hw/pci/pci.c:2104 #4 0x00005555558d1a7a in pci_create (bus=bus@entry=0x5555562664b0, devfn=devfn@entry=-1, name=name@entry=0x555555b24efb "ati-vga") at hw/pci/pci.c:2121 #5 0x0000555555763081 in mips_fulong2e_init (machine=<optimized out>) at hw/mips/mips_fulong2e.c:352 #6 0x000055555587e23b in machine_run_board_init (machine=0x5555560b2000) at hw/core/machine.c:1030 #7 0x00005555556cbea2 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4463 And then: $ qemu-system-mips64el -bios /dev/null -M fulong2e qemu-system-mips64el: Unsupported NIC model: rtl8139 Fixes: 862b4a291dc and 7c28b925b7e Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-8-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/mips/Kconfig: Malta machine requires the pcnet network cardPhilippe Mathieu-Daudé
This fixes when configuring with --without-default-devices: $ qemu-system-mips64 -bios /dev/null -M malta qemu-system-mips64: Unsupported NIC model: pcnet Fixes: 7c28b925b7e Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-7-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/i386/Kconfig: enable devices that can be created by defaultPhilippe Mathieu-Daudé
This fixes when configuring with CONFIG_PCI_DEVICES=n: $ qemu-system-x86_64 -M q35 qemu-system-x86_64: Unsupported NIC model: e1000e $ qemu-system-x86_64 -M pc qemu-system-x86_64: Unsupported NIC model: e1000 Fixes: 7c28b925b7e Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-4-philmd@redhat.com>
2019-03-20hw/isa/Kconfig: PIIX4 southbridge requires USB UHCIPhilippe Mathieu-Daudé
This fixes when configuring with --without-default-devices: $ qemu-system-mips64 -bios /dev/null -M malta qemu-system-mips64: Unknown device 'piix4-usb-uhci' for bus 'PCI' Fixes: 7c28b925b7e Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-2-philmd@redhat.com>
2019-03-20hw/isa/Kconfig: i82378 SuperIO requires PC speaker devicePhilippe Mathieu-Daudé
This fixes when configuring with --without-default-devices: $ qemu-system-ppc -M prep qemu-system-ppc: Machine type 'prep' is deprecated: use 40p machine type instead qemu-system-ppc: Unknown device 'isa-pcspk' for bus 'ISA' Fixes: dd0ff8191ab Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190316200818.8265-3-philmd@redhat.com>
2019-03-20prep: do not select I82374Paolo Bonzini
It is only needed through I82378, which also selects it. Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-20hw/i386/Kconfig: PC uses I8257, not I82374Paolo Bonzini
CONFIG_I82374 is not needed for PC machines, since they create i8257 directly instead. Reported-by: Miroslav Rezanina <mrezanin@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-03-19Update version for v4.0.0-rc0 releasev4.0.0-rc0Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-19Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - mirror: Fix early return from drain (could cause deadlocks) - vmdk: Fixed probing for version 3 images - vl: Fix to create migration object before block backends again (fixes segfault for block drivers that set migration blockers) - Several minor fixes, documentation and test case improvements # gpg: Signature made Tue 19 Mar 2019 14:59:17 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-iotests: Treat custom TEST_DIR in 051 blockdev: Check @replaces in blockdev_mirror_common block: Make bdrv_{copy_on_read,crypto_luks,replication} static blockjob: fix user pause in block_job_error_action qemu-iotests: Fix 232 for non-qcow2 vl: Fix to create migration object before block backends again iotests: 153: Wait for an answer to QMP commands block: Silence Coverity in bdrv_drop_intermediate() vmdk: Support version=3 in VMDK descriptor files qapi: fix block-latency-histogram-set description and examples qcow2: Fix data file error condition in qcow2_co_create() mirror: Confirm we're quiesced only if the job is paused or cancelled Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-19Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190319' into ↵Peter Maydell
staging Xen queue Fix a bug on FreeBSD when doing a migration. # gpg: Signature made Tue 19 Mar 2019 15:40:55 GMT # gpg: using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF # gpg: issuer "anthony.perard@citrix.com" # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>" [marginal] # gpg: aka "Anthony PERARD <anthony.perard@citrix.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: 5379 2F71 024C 600F 778A 7161 D8D5 7199 DF83 42C8 # Subkey fingerprint: F80C 0063 08E2 2CFD 8A92 E798 0CF5 572F D7FB 55AF * remotes/aperard/tags/pull-xen-20190319: xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-19xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honoredRoger Pau Monne
Or if it's not possible to honor the hinted address an error is returned instead. This makes it easier to spot the actual failure, instead of failing later on when the caller of xen_remap_bucket realizes the mapping has not been created at the requested address. Also note that at least on FreeBSD using MAP_FIXED will cause mmap to try harder to honor the passed address. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Igor Druzhinin <igor.druzhinin@cirtix.com> Message-Id: <20190318173731.14494-1-roger.pau@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-03-19qemu-iotests: Treat custom TEST_DIR in 051Lukáš Doktor
When custom TEST_DIR is specified the output includes it without leading '/': $ TEST_DIR=/var/tmp ./check -file -qcow2 051 .... -drive0 (NODE_NAME): json:{"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "TEST_DIR/t.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": SNAPSHOT_PATH}} (qcow2, read-only) +drive0 (NODE_NAME): json:{"backing": {"driver": "qcow2", "file": {"driver": "file", "filename": "TEST_DIR/t.qcow2"}}, "driver": "qcow2", "file": {"driver": "file", "filename": "TEST_DIR/vl.ziHfeP"}} (qcow2, read-only) Let's remove it from the sed regexp. Signed-off-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-19blockdev: Check @replaces in blockdev_mirror_commonMax Reitz
There is no reason why the constraints we put on @replaces should be limited to drive-mirror. Therefore, move the sanity checks from qmp_drive_mirror() to blockdev_mirror_common() so they apply to blockdev-mirror as well. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-19block: Make bdrv_{copy_on_read,crypto_luks,replication} staticAlberto Garcia
Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-19blockjob: fix user pause in block_job_error_actionVladimir Sementsov-Ogievskiy
Job (especially mirror) may call block_job_error_action several times before actual pause if it has several in-flight requests. block_job_error_action will call job_pause more than once in this case, which lead to following block-job-resume qmp command can't actually resume the job. Fix it by do not increase pause level in block_job_error_action if user_paused already set. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-19qemu-iotests: Fix 232 for non-qcow2Kevin Wolf
232 is marked as generic, but commit 12efe428c9e added code that assumes qcow2. What the new test really needs is backing files and support for updating the backing file link (.bdrv_change_backing_file). Split the non-generic code into a new test case 247 and make it work with qed, too. Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-19vl: Fix to create migration object before block backends againMarkus Armbruster
Recent commit cda4aa9a5a0 moved block backend creation before machine property evaluation. This broke qemu-iotests 055. Turns out we need to create the migration object before block backends, so block backends can add migration blockers. Fix by calling migration_object_init() earlier, right before configure_blockdev(). Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce Reported-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 04:12:54 +0000