Re: [Qemu-devel] [PULL 8/9] tests: add qmp/qom-set-without-value test
Hi
On Tue, Oct 9, 2018 at 8:41 PM Markus Armbruster wrote:
>
> Markus Armbruster writes:
>
> > Thomas Huth writes:
> >
> >> On 2018-08-31 15:24, Marc-André Lureau wrote:
> >>> Hi
> >>> On Fri, Aug 31, 2018 at 3:18 PM Thomas Huth wrote:
>
> On 2018-08-31 14:04, Markus Armbruster wrote:
> > Thomas Huth writes:
> >
> >> From: Marc-André Lureau
> >>
> >> test_qom_set_without_value() is about a bug in infrastructure used by
> >> the QMP core, fixed in commit c489780203. We covered the bug in
> >> infrastructure unit tests (commit bce3035a44). I wrote that test
> >> earlier, to cover QMP level as well, the test could go into qmp-test.
> >>
> >> Signed-off-by: Marc-André Lureau
> >> Reviewed-by: Thomas Huth
> >> Signed-off-by: Thomas Huth
> >> ---
> >> tests/qmp-test.c | 14 ++
> >> 1 file changed, 14 insertions(+)
> >>
> >> diff --git a/tests/qmp-test.c b/tests/qmp-test.c
> >> index b347228..2b923f0 100644
> >> --- a/tests/qmp-test.c
> >> +++ b/tests/qmp-test.c
> >> @@ -321,6 +321,19 @@ static void test_qmp_preconfig(void)
> >> qtest_quit(qs);
> >> }
> >>
> >> +static void test_qom_set_without_value(void)
> >> +{
> >> +QTestState *qts;
> >> +QDict *resp;
> >> +
> >> +qts = qtest_init(common_args);
> >> +resp = qtest_qmp(qts, "{'execute': 'qom-set', 'arguments':"
> >> + " { 'path': '/machine', 'property': 'rtc-time' }
> >> }");
> >> +g_assert_nonnull(resp);
> >> +qmp_assert_error_class(resp, "GenericError");
> >> +qtest_quit(qts);
> >> +}
> >> +
> >> int main(int argc, char *argv[])
> >> {
> >> g_test_init(&argc, &argv, NULL);
> >> @@ -328,6 +341,7 @@ int main(int argc, char *argv[])
> >> qtest_add_func("qmp/protocol", test_qmp_protocol);
> >> qtest_add_func("qmp/oob", test_qmp_oob);
> >> qtest_add_func("qmp/preconfig", test_qmp_preconfig);
> >> +qtest_add_func("qmp/qom-set-without-value",
> >> test_qom_set_without_value);
> >>
> >> return g_test_run();
> >> }
> >
> > I'm afraid you missed my objection to naming:
> > Message-ID: <8736uvujxx@dusky.pond.sub.org>
> > https://lists.nongnu.org/archive/html/qemu-devel/2018-08/msg06368.html
>
> Sorry about that, I was not on CC: for that series. I used the patches
> from v5 where Marc-André put me on CC:.
>
> > If you could work that into PULL v2, I'd be obliged. If not, I'll have
> > to address it in a follow-up patch.
>
> IMHO the naming is not that bad ... OTOH, I think Peter might already be
> away? ... so we've got plenty of time to sort this out anyway.
> Marc-André, could you send a new version of the patch?
> >>>
> >>> Tbh, I don't care so much about the naming of the test, but (for once)
> >>> I respectfully don't think Markus suggestion is better.
> >>>
> >>> The function checks "qom-set" without 'value' argument:
> >>> "qom-set-without-value", no brainer..
> >
> > Nope, that's not what it tests. It tests the visitor, the marshalling
> > code generator, and the QMP core handle a certain kind of invalid
> > arguments correctly. It does not test qom-set. I explained all that
> > already.
> >
> >>> Naming it "invalid-arg" is so generic that I wouldn't be able what it
> >>> does.
> >
> > I can accept "missing-any" or "missing-any-arg". I object to any name
> > involving qom-set, because the test is not about qom-set at all.
> >
> > If it was, then putting it in qmp-test.c would be wrong.
> >
> >> Ok, then let's keep it this way. As I said, IMHO the current naming is
> >> not really bad, and I also don't have any suggestions for a perfect name
> >> right now.
> >
> > We don't need a perfect name. We need one that's not actively
> > misleading.
>
> Marc-André, would "qmp/missing-any-arg" and test_missing_any_arg() work
> for you?
Yes, do you want me to update the patch?
--
Marc-André Lureau
Re: [Qemu-devel] vhost-user devices work with chardev from different threads
Hi On Mon, Oct 22, 2018 at 5:24 PM Yury Kotov wrote: > > Hi, > > I examined vhost-user devices and found some chardev using strangeness. > > Is it ok, that vhost-user's set_status do sync chardev io ops from KVM thread? > It seems that chardev doesn't support working with different threads. > > For example, I think such race is possible (two simultaneous events): > 1) Vhost-user server was killed (main thread will handle G_IO_HUP), > 2) Virtio-pci bus handles guest driver's set_status command. >Some io op from vhost-user backend will fail because of 1). > > So, it is possible to enter tcp_chr_disconnect twice from the main thread and > from KVM thread. > > Backtrace examples: > > KVM thread (handle set_status of guest): > tcp_chr_disconnect > tcp_chr_write (cc->chr_write) > qemu_chr_write_buffer > qemu_chr_write > qemu_chr_fe_write_all > vhost_user_write > vhost_user_set_mem_table (hdev->vhost_ops->vhost_set_mem_table) > vhost_dev_start > vhost_user_blk_start (or another vhost-user device) > vhost_user_blk_set_status (vdc->set_status) > > Main thread (handle vhost server disconnect): > tcp_chr_disconnect > tcp_chr_hup > g_main_context_dispatch > glib_pollfds_poll > os_host_main_loop_wait > main_loop_wait > main_loop > main > > Is it really a problem or do I misunderstand? I think you are correct, it's a problem. Are you working on a solution? (either using the chardev lock, or perhaps relying on main thread HUP handler only, or a combination of both approaches) thanks -- Marc-André Lureau
Re: [Qemu-devel] [PATCH 1/1] i386: Add PKU/OSPKE on Skylake-Server CPU model
On 10/26/18 4:22 PM, Eduardo Habkost wrote: On Fri, Oct 26, 2018 at 01:53:10PM +0800, Tao Xu wrote: On 10/25/18 9:28 PM, Eduardo Habkost wrote: Sorry for taking so long to reply. This can be safely done only if every host that is able to run Skylake-Server today is guaranteed to support PKU. Is that the case? Yes, as the release document ref below link (page 13): https://software.intel.com/sites/default/files/managed/c5/15/\ architecture-instruction-set-extensions-programming-reference.pdf PKU is supported in Skylake Server (Only Server) and later. So, every host that is able to run Skylake-Server today is to to support PKU. You'll also need Skylake-Server-*-cpu.pku=off entries on PC_COMPAT_3_0 to keep PKU disabled on pc-*-3.0 and older. Thank you Eduardo, But I can't find PC_COMPAT_3_0 in include/hw/i386/pc.h. Will it exist on QEMU 3.1 and will I add "pku=off" after QEMU 3.1 release? PC_COMPAT_3_0 was added to qemu.git master a few weeks ago, by commit 9b4cf107b09d18ac30f46fd1c4de8585ccba030c. Thank you. I'll add this on the next version of this patch.
[Qemu-devel] [PATCH 2/2] nvme: free cmbuf in nvme_exit
This avoid a memory leak in unhotplug nvme device.
Signed-off-by: Li Qiang
---
hw/block/nvme.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index 359a06d0ad..09d7c90259 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1332,6 +1332,9 @@ static void nvme_exit(PCIDevice *pci_dev)
g_free(n->cq);
g_free(n->sq);
+if (n->cmb_size_mb) {
+g_free(n->cmbuf);
+}
msix_uninit_exclusive_bar(pci_dev);
}
--
2.11.0
[Qemu-devel] [PATCH 0/2] nvme: fix two issues in nvme unhotplug
The first corrent the refcount and second fix a memory leak. Li Qiang (2): nvme: don't unref ctrl_mem when device unrealized nvme: free cmbuf in nvme_exit hw/block/nvme.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.11.0
[Qemu-devel] [PATCH 1/2] nvme: don't unref ctrl_mem when device unrealized
Currently, when hotplug/unhotplug nvme device, it will cause an
assert in object.c. Following is the backtrack:
ERROR:qom/object.c:981:object_unref: assertion failed: (obj->ref > 0)
Thread 2 "qemu-system-x86" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffcbd32700 (LWP 18844)]
0x7fffdb9e4fff in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
/lib/x86_64-linux-gnu/libglib-2.0.so.0
/lib/x86_64-linux-gnu/libglib-2.0.so.0
qom/object.c:981
/home/liqiang02/qemu-upstream/qemu/memory.c:1732
/home/liqiang02/qemu-upstream/qemu/memory.c:285
util/qemu-thread-posix.c:504
/lib/x86_64-linux-gnu/libpthread.so.0
This is caused by memory_region_unref in nvme_exit.
Remove it to make the PCIdevice refcount correct.
Signed-off-by: Li Qiang
---
hw/block/nvme.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/hw/block/nvme.c b/hw/block/nvme.c
index fc7dacb816..359a06d0ad 100644
--- a/hw/block/nvme.c
+++ b/hw/block/nvme.c
@@ -1331,9 +1331,6 @@ static void nvme_exit(PCIDevice *pci_dev)
g_free(n->namespaces);
g_free(n->cq);
g_free(n->sq);
-if (n->cmbsz) {
-memory_region_unref(&n->ctrl_mem);
-}
msix_uninit_exclusive_bar(pci_dev);
}
--
2.11.0
Re: [Qemu-devel] [PATCH 2/4] migration: introduce lockless multithreads model
On 10/28/2018 03:50 PM, Paolo Bonzini wrote: On 27/10/2018 01:33, Emilio G. Cota wrote: On Wed, Oct 17, 2018 at 12:10:15 +0200, Paolo Bonzini wrote: On 16/10/2018 13:10, guangrong.x...@gmail.com wrote: An idea: the total number of requests is going to be very small, and a PtrRing is not the nicest data structure for multiple producer/single consumer. So you could instead: (snip) - now that you have request indices, you can replace the completion ptr_ring with a bitmap, and set a bit in the bitmap with set_bit_atomic to report completion. On the writer side you use find_next_bit to find (snip) Emilio, can you review the above ideas? Sorry it took me a while to go through this. I like your suggestions. Just one nit; I'm not sure I understood the use case very well, but I think using a bitmap to signal completion might be suboptimal, since we'd have several thread spinning on the same cacheline yet caring about different bits. Requests are asynchronous, the bitmap is only used to find a free submission slot. You're right that the bitmap can bounce across processors, but I'm not sure how else you would do that because you don't know in advance how many submitting threads you have. It wouldn't be any worse if there was a spinlock. However, in the migration case there is only one submitting thread, so it's okay. :) Yup. The cache contention only exists in the work threads, the sumbiter thread is totally free who is the main migration thread. Making the main thread be faster is good. Paolo Xiao: a couple of suggestions - Since you'll be adding a generic module, make its commit and description self-contained. That is, mentioning in the log that this will be used for migration is fine, but please describe the module (and the assumptions it makes about its users) in general, so that someone that doesn't know anything about migration can still understand this module (and hopefully adopt it for other use cases). Good to me, i will add more detailed description for this module in the next version. - I'd like to see a simple test program (or rather, benchmark) that shows how this works. This benchmark would be completely unrelated to migration; it should just be a simple test of the performance/scalability of this module. Having this benchmark would help (1) discuss and quantitately evaluate modifications to the module, and (2) help others to quickly understand what the module does. See tests/qht-bench.c for an example. Can not agree with you more, will do. :) Thank you, Emilio and Paolo!
[Qemu-devel] [Bug 1800401] Re: efifb on Linux guest fails to load when using VGA passthrough
The OVMF BIOS used can be downloaded from https://dev.gentoo.org/~tamiko/distfiles/edk2-ovmf- 2017_p20180211-bin.tar.xz System information via 'emerge --info' is also provided below. Portage 2.3.51 (python 3.6.6-final-0, default/linux/amd64/17.1/desktop, gcc-8.2.0, glibc-2.27-r6, 4.19.0-gentoo x86_64) = System Settings = System uname: Linux-4.19.0-gentoo-x86_64-Intel-R-_Core-TM-_i7-4771_CPU_@_3.50GHz-with-gentoo-2.6 KiB Mem:32634140 total, 6226108 free KiB Swap:2097148 total, 2097148 free Timestamp of repository gentoo: Sun, 28 Oct 2018 09:44:31 + Head commit of repository gentoo: aea18fb934c3bf31707dd73cde11f46aca67da49 Timestamp of repository brother-overlay: Sat, 27 Oct 2018 19:24:00 + Head commit of repository brother-overlay: 6a39a7856547c13d12f40585721b65af7f1f6469 Head commit of repository nuntoo: b7b28a262ea47f1e8d92e36ed1a59bac2f338095 sh bash 4.4_p23 ld GNU ld (Gentoo 2.31.1 p3) 2.31.1 app-shells/bash: 4.4_p23::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl:5.26.2::gentoo dev-lang/python: 2.7.15::gentoo, 3.6.6::gentoo dev-util/cmake: 3.12.3::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.39.1::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.16.1-r1::gentoo sys-devel/binutils: 2.31.1-r1::gentoo sys-devel/gcc:8.2.0-r4::gentoo sys-devel/gcc-config: 2.0::gentoo sys-devel/libtool:2.4.6-r5::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers) sys-libs/glibc: 2.27-r6::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo.git priority: -1000 brother-overlay location: /var/db/repos/brother-overlay sync-type: git sync-uri: https://github.com/gentoo-mirror/brother-overlay.git masters: gentoo nuntoo location: /var/db/repos/nuntoo sync-type: git sync-uri: https://github.com/nvinson/nuntoo.git masters: gentoo private location: /var/db/repos/private masters: gentoo ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--jobs=8 --load-average=8" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org"; LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en_US en" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa amd64 berkdb branding bzip2 cairo cdda cdr cleartype cli consolekit corefonts crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam flac fortran gdbm gif glamor gpm gtk iconv ipv6 jpeg lcms ldap libnotify libtirpc mad mng mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds qt5 readline sdl seccomp spell ssl startup-notification svg tcpd theora tiff truetype udev udisks unicode upower usb vaapi vorbis vpx wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user
[Qemu-devel] [Bug 1800401] [NEW] efifb on Linux guest fails to load when using VGA passthrough
Public bug reported: The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. Steps to Reproduce: 1. Install qemu and ovmf 2. Download systemrescuecd-x86-5.3.1.iso 3. Run qemu using one of the configurations below 4. Select first boot option in GRUB menu 5. Wait 30 seconds 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 7. Wait 2 minutes 8. Observe fb console 9. Note lack of output until very late in boot process 10. Check dmesg 11. Note efifb failed to load (invalid address) 12. Note nouveaufb started late in boot process Expected Results: The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. Actual Results: The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. Additional information: Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "configuraton log for qemu build at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4" https://bugs.launchpad.net/bugs/1800401/+attachment/5206599/+files/config.log -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1800401 Title: efifb on Linux guest fails to load when using VGA passthrough Status in QEMU: New Bug description: The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. Steps to Reproduce: 1. Install qemu and ovmf 2. Download systemrescuecd-x86-5.3.1.iso 3. Run qemu using one of the configurations below 4. Select first boot option in GRUB menu 5. Wait 30 seconds 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 7. Wait 2 minutes 8. Observe fb console 9. Note lack of output until very late in boot process 10. Check dmesg 11. Note efifb failed to load (invalid address) 12. Note nouveaufb started late in boot process Expected Results: The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. Actual Results: The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. Additional information: Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1800401/+subscriptions
[Qemu-devel] [Bug 1800401] Re: efifb on Linux guest fails to load when using VGA passthrough
** Attachment added: "Gentoo_qxl.sh -- systemrescuecd-x86-5.3.1 -- dmesg.log" https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206601/+files/Gentoo_qxl.sh%20--%20systemrescuecd-x86-5.3.1%20--%20dmesg.log -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1800401 Title: efifb on Linux guest fails to load when using VGA passthrough Status in QEMU: New Bug description: The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. Steps to Reproduce: 1. Install qemu and ovmf 2. Download systemrescuecd-x86-5.3.1.iso 3. Run qemu using one of the configurations below 4. Select first boot option in GRUB menu 5. Wait 30 seconds 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 7. Wait 2 minutes 8. Observe fb console 9. Note lack of output until very late in boot process 10. Check dmesg 11. Note efifb failed to load (invalid address) 12. Note nouveaufb started late in boot process Expected Results: The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. Actual Results: The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. Additional information: Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1800401/+subscriptions
[Qemu-devel] [Bug 1800401] Re: efifb on Linux guest fails to load when using VGA passthrough
** Attachment added: "Gentoo.sh -- systemrescuecd-x86-5.3.1 -- dmesg.log" https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206600/+files/Gentoo.sh%20--%20systemrescuecd-x86-5.3.1%20--%20dmesg.log -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1800401 Title: efifb on Linux guest fails to load when using VGA passthrough Status in QEMU: New Bug description: The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. Steps to Reproduce: 1. Install qemu and ovmf 2. Download systemrescuecd-x86-5.3.1.iso 3. Run qemu using one of the configurations below 4. Select first boot option in GRUB menu 5. Wait 30 seconds 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 7. Wait 2 minutes 8. Observe fb console 9. Note lack of output until very late in boot process 10. Check dmesg 11. Note efifb failed to load (invalid address) 12. Note nouveaufb started late in boot process Expected Results: The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. Actual Results: The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. Additional information: Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1800401/+subscriptions
[Qemu-devel] [Bug 1800401] Re: efifb on Linux guest fails to load when using VGA passthrough
** Attachment added: "Shell script used to invoke qemu with vga-passthrough and qxl graphics emulation" https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206603/+files/Gentoo_qxl.sh -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1800401 Title: efifb on Linux guest fails to load when using VGA passthrough Status in QEMU: New Bug description: The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. Steps to Reproduce: 1. Install qemu and ovmf 2. Download systemrescuecd-x86-5.3.1.iso 3. Run qemu using one of the configurations below 4. Select first boot option in GRUB menu 5. Wait 30 seconds 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 7. Wait 2 minutes 8. Observe fb console 9. Note lack of output until very late in boot process 10. Check dmesg 11. Note efifb failed to load (invalid address) 12. Note nouveaufb started late in boot process Expected Results: The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. Actual Results: The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. Additional information: Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1800401/+subscriptions
[Qemu-devel] [Bug 1800401] Re: efifb on Linux guest fails to load when using VGA passthrough
** Attachment added: "Shell script used to invoke qemu with only vga-passthrough" https://bugs.launchpad.net/qemu/+bug/1800401/+attachment/5206602/+files/Gentoo.sh -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1800401 Title: efifb on Linux guest fails to load when using VGA passthrough Status in QEMU: New Bug description: The EFI framebuffer fails to load when booting a Gentoo guest using ovmf + vga_passthrough. I retested using they system rescue CD and saw the same issue, but also noticed that when a second framebuffer loads, nouveaufb in my case, the terminal appears. I have also verified that the Gentoo min CD is not hanging at boot as I can type 'poweroff' after waiting a few minutes and the system responds by powering off. I am unable to reproduce with seabios as I have been unable to get vga passthrough to work with that BIOS. Steps to Reproduce: 1. Install qemu and ovmf 2. Download systemrescuecd-x86-5.3.1.iso 3. Run qemu using one of the configurations below 4. Select first boot option in GRUB menu 5. Wait 30 seconds 6. Press enter # System rescue is prompting for the keymap between steps 5 and 6 7. Wait 2 minutes 8. Observe fb console 9. Note lack of output until very late in boot process 10. Check dmesg 11. Note efifb failed to load (invalid address) 12. Note nouveaufb started late in boot process Expected Results: The EFI FB to load and display output to monitor. This is the behavior I see when booting the host system via UEFI. Actual Results: The EFI FB fails to load and display output. System fails to display any output until nouveaufb loads. When booting using the Gentoo minCD, this makes the system largely unusable. Additional information: Tested using Gentoo's app-emulation/qemu-3.0.0 version. Bug report: https://bugs.gentoo.org/669880 I also tested qemu at git commit 179f9ac887973c818b2578bd79fa3ed2522657d4. Configuration log for the build will be attached. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1800401/+subscriptions
[Qemu-devel] Fwd: [retrocomputing devroom] FOSDEM 2019 - Retrocomputing DevRoom CfP
Hi,
anyone wants to talk about emulating oldies with QEMU?
François.
Message transféré
Sujet : [retrocomputing devroom] FOSDEM 2019 - Retrocomputing DevRoom CfP
Date : Sun, 28 Oct 2018 23:12:58 +0100
De : Pau Garcia Quiles
Pour : FOSDEM visitors
Copie à : retrocomputing-devr...@lists.fosdem.org
Hello,
FOSDEM 2019 - Retrocomputing DevRoom Call for Participation
FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renown for being
highly developer-oriented and brings together 8000+ participants from
all over the world. It is held in the city of Brussels (Belgium).
FOSDEM 2019 will take place during the weekend of February 2nd-3rd
2019. More details about the event can be found at
http://www.fosdem.org.
CALL FOR PARTICIPATION
After last year's success, the Retrocomputing DevRoom will be back in
2019, with talks about use of older computing hardware and software in
modern times.
Presentation topics could include but are not limited to:
- Emulation of old systems to run videogames, legacy software, etc
- New software, hardware or related to be used with classic systems
- Open source software emulation/simulation
- Open hardware
- Operating systems/executives for retrocomputers/retrosystems
- Uses of retrocomputing today
- Other retrosystems topics
- Opportunities in retrocomputing
You are not limited to slide presentations, of course. Be creative.
However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. We are not afraid of technical
stuff: devrooms are a place for development teams to meet, discuss,
hack and publicly present their project’s latest improvements and
future directions.
If you will have special needs for your talk (e. g. because you will
need to plug some sort of a system), please note that clearly in your
proposal so that we can provide it.
You can use the Wikipedia definition of retrocomputing as a reference
definition to see if you talk qualifies, although it is not exclusive:
https://en.wikipedia.org/wiki/Retrocomputing
IMPORTANT DATES
- 30 November 2018: submission deadline for talk proposals
- 16 December 2018: announcement of the final schedule
- 2 February 2019: Retrocomputing DevRoom
USEFUL INFORMATION
Use the FOSDEM Pentabarf tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM19
- If necessary, create a Pentabarf account and activate it. Please
reuse your account from previous years if you have already created it.
- In the "Person" section, provide First name, Last name (in the
"General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Retrocomputing DevRoom" track (on the
"General" tab). If you do not select a track, then nobody, from any
track, will look at your submission!
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the intended
audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
- Provide an expected length of your talk in the "Duration" field,
including discussion. The default duration is 30 minutes.
Please note neither FOSDEM nor the Retrocomputing DevRoom will
reimburse any expenses you incur
RECORDING OF TALKS
The FOSDEM organizers plan to have live streaming and recording fully
working, both for remote/later viewing of talks, and so that people
can watch streams in the hallways when rooms are full. This requires
speakers to consent to being recorded and streamed.
If you plan to be a speaker, please understand that by doing so you
implicitly give consent for your talk to be recorded and streamed. The
recordings will be published under the same license as all FOSDEM
content (CC-BY).
Hope to hear from you soon! And please forward this announcement.
CONTACT
The Retrocomputing DevRoom is managed by Pau Garcia Quiles
(retrocomputing-devroom-manager at fosdem.org).
A mailing list of speakers, audience and the curious is available,
please subscribe at:
https://lists.fosdem.org/listinfo/retrocomputing-devroom
--
Pau Garcia Quiles
http://www.elpauer.org
___
retrocomputing-devroom mailing list
retrocomputing-devr...@lists.fosdem.org
https://lists.fosdem.org/listinfo/retrocomputing-devroom
Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU
On Sun, 28 Oct 2018, Aleksandar Markovic wrote: > I truly need your help here. As you can conclude from the discussion, > R5900 folks (anybody correct me if I am wrong) have some problems using > any ABI other than O32. The maximum the R5900 can support is the n32 ABI, owing to 32-bit virtual addressing. And that ABI is even more troublesome due to this processor's peculiarities, requiring extra effort in addition to what has to be done to support o32 only. The lack of sign-extension of the link address that becomes visible with 64-bit register accesses is just one issue to name. Hence the staged approach chosen. We'll get n32 support eventually as well, once o32 has been sorted, but there'll be no n64 support ever. Maciej
Re: [Qemu-devel] [PATCH] target/mips: Support Toshiba specific three-operand MADD and MADDU
> From: Richard Henderson > Sent: Tuesday, October 16, 2018 8:37 PM > Subject: Re: [PATCH] target/mips: Support Toshiba specific three-operand MADD > and MADDU > > On 10/16/18 11:19 AM, Fredrik Noring wrote: > > /* global register indices */ > > static TCGv cpu_gpr[32], cpu_PC; > > static TCGv cpu_HI[MIPS_DSP_ACC], cpu_LO[MIPS_DSP_ACC]; > > > > One option is to create a new array such as > > > > static TCGv_i64 mmi_gpr[32]; > > > > that represents the upper 64 bits of each GPR. Then cpu_gpr must be of > > a 64-bit type too, even when QEMU runs in 32-bit user mode. The R5900 > > does not implement CP0.Status.UX in hardware, though, so system mode is > > 64 bits, regardless. > > I would not implement r5900 for mips32 in that case, > I would implement it only for TARGET_MIPS64. > > r~ Hello, Richard. I truly need your help here. As you can conclude from the discussion, R5900 folks (anybody correct me if I am wrong) have some problems using any ABI other than O32. (For example, the standard gcc switch are "-mabi=32 -march=r5900".) Other similar CPUs, for example R4000, are built with TARGET_MIPS64, both user and system mode. R5900 would not have TARGET_MIPS64 in such arrangement. This looks outlandish to me. Given that R5900 is a 64-bit MIPS III-like processor, is there any anomaly in this arrangement, or this should work and is OK? Thanks, Aleksandar
Re: [Qemu-devel] [PATCH v7 04/20] target/mips: Add and integrate MXU decoding engine placeholder
> Subject: Re: [PATCH v7 04/20] target/mips: Add and integrate MXU decoding > engine > placeholder > > > Is the best way to implement this to include processing of MUL, CLZ, > > CLO, SDBBP instructions into decode_opc_mxu as their encodings aren't > > overlaid by MXU instructions considering MIPS SPECIAL2 instruction > > pool and MXU Instruction Set? > > The problem is that we don't have the documentation for Ingenic's base > instruction set. My understanding is that Craig established necessity of > including non-MXU MUL into decode_opc_mxu() by experimentation, > or by looking at Ingenic's toolchain source code. > > Note that CLZ, CLO, SDBBP are moved from SPECIAL2 to another > place in opcode space in MIPS R6. > > Craig, can you offer any insight on CLZ, CLO, SDBBP in Ingenic's base > instruction set? They are in SPECIAL2 opcode space for MIPS pre-R6. > > Worse come to worst, I recommend adding "TODO" comment to an > appropriate place in decode_opc_mxu(), and go forward without handling > CLZ, CLO, SDBBP - given that all changes in this series are just the first > phase of implementing MXU support - they won't affect any production > code at this moment. > I think this comment should be added to the decode_opc_mxu(), within patch 11: /* * TODO: Investigate necessity of including handling of * CLZ, CLO, SDBB in this function, as they belong to * SPECIAL2 opcode space for regular pre-R6 MIPS ISAs. */ Thanks, Aleksandar
Re: [Qemu-devel] [PATCH v7 11/20] target/mips: Add emulation of non-MXU MULL within MXU decoding engine
> Subject: [PATCH v7 11/20] target/mips: Add emulation of non-MXU MULL within > MXU decoding engine > > From: Craig Janeczek > > Add emulation of non-MXU MULL within MXU decoding engine. > > Signed-off-by: Craig Janeczek > Signed-off-by: Aleksandar Markovic > --- Reviewed-by: Aleksandar Markovic
Re: [Qemu-devel] [PATCH v7 12/20] target/mips: Add emulation of MXU instructions S32I2M and S32M2I
> Subject: [PATCH v7 12/20] target/mips: Add emulation of MXU instructions > S32I2M and S32M2I > > From: Craig Janeczek > > Add support for emulating the S32I2M and S32M2I MXU instructions. > This commit also contains utility functions for reading/writing > to MXU registers. This is required for overall MXU instruction > support. > > Signed-off-by: Craig Janeczek > Signed-off-by: Aleksandar Markovic > --- Not all bits of MXU_CR are RW. RW-rules should be included in this patch. Or, at minimum, a "TODO" note should be inserted in the appropiriate handler. Other than this: Reviewed-by: Aleksandar Markovic Thanks, Aleksandar
Re: [Qemu-devel] [PATCH v7 02/20] target/mips: Define a bit for MXU in insn_flags
> Subject: [PATCH v7 02/20] target/mips: Define a bit for MXU in insn_flags > > From: Craig Janeczek > > Define a bit for MXU in insn_flags. This is the first non-MIPS > (third party) ASE supported in QEMU for MIPS, so it is placed in > the section "bits 56-63: vendor-specific ASEs". > > Signed-off-by: Craig Janeczek > Signed-off-by: Aleksandar Markovic > --- Reviewed-by: Aleksandar Markovic
Re: [Qemu-devel] [PATCH v7 04/20] target/mips: Add and integrate MXU decoding engine placeholder
> Is the best way to implement this to include processing of MUL, CLZ, > CLO, SDBBP instructions into decode_opc_mxu as their encodings aren't > overlaid by MXU instructions considering MIPS SPECIAL2 instruction > pool and MXU Instruction Set? The problem is that we don't have the documentation for Ingenic's base instruction set. My understanding is that Craig established necessity of including non-MXU MUL into decode_opc_mxu() by experimentation, or by looking at Ingenic's toolchain source code. Note that CLZ, CLO, SDBBP are moved from SPECIAL2 to another place in opcode space in MIPS R6. Craig, can you offer any insight on CLZ, CLO, SDBBP in Ingenic's base instruction set? They are in SPECIAL2 opcode space for MIPS pre-R6. Worse come to worst, I recommend adding "TODO" comment to an appropriate place in decode_opc_mxu(), and go forward without handling CLZ, CLO, SDBBP - given that all changes in this series are just the first phase of implementing MXU support - they won't affect any production code at this moment. I appreciate your review, Aleksandar
Re: [Qemu-devel] [PATCH v7 07/20] target/mips: Add bit encoding for MXU accumulate add/sub 2-bit pattern 'aptn2'
> Subject: [PATCH v7 07/20] target/mips: Add bit encoding for MXU accumulate > add/sub 2-bit pattern 'aptn2' > > From: Craig Janeczek > > Add bit encoding for MXU accumulate add/subtract 2-bit pattern > 'aptn2'. > > Signed-off-by: Craig Janeczek > Signed-off-by: Aleksandar Markovic > --- Reviewed-by: Aleksandar Markovic
Re: [Qemu-devel] [PATCH v7 10/20] target/mips: Add bit encoding for MXU operand getting pattern 'optn3'
> Subject: [PATCH v7 10/20] target/mips: Add bit encoding for MXU operand > getting pattern 'optn3' > > From: Craig Janeczek > > Add bit encoding for MXU operand getting pattern 'optn3'. > > Signed-off-by: Craig Janeczek > Signed-off-by: Aleksandar Markovic --- Reviewed-by: Aleksandar Markovic
Re: [Qemu-devel] [PATCH v7 09/20] target/mips: Add bit encoding for MXU operand getting pattern 'optn2'
> Subject: [PATCH v7 09/20] target/mips: Add bit encoding for MXU operand > getting pattern 'optn2' > > From: Craig Janeczek > > Add bit encoding for MXU operand getting pattern 'optn2'. > > Signed-off-by: Craig Janeczek > Signed-off-by: Aleksandar Markovic > --- Reviewed-by: Aleksandar Markovic
Re: [Qemu-devel] Minutes of KVM Forum BoF on deprecating stuff
On 28 October 2018 at 05:43, Markus Armbruster wrote: > Daniel P. Berrangé writes: >> Something I meant to bring up but forgot is about the classification >> of devices, especially with a view towards security. It is not directly >> about deprecation, but it is somewhat related as it is related to the >> state of maintainence and quality level >> >> We've got alot of devices, but only a subset are written and maintained >> to a level where we'd consider them robust wrt malcious guests. Other >> devices are only suitable for friendly guest environments. We should >> clearly document which are the devices that we consider to provide >> a secure boundary to guests, so users can make suitably informed choices. >> I'd guess this means all virtio devices, and then few of the emulated >> devices that are commonly used & maintained in a KVM environment. > > A machine whose mandatory devices don't all provide a security boundary > also doesn't provide one. Thus, classification of devices leads to a > classification of machines. We've generally done it the other way around -- we define the small set of machines whose security boundary we care about (ie the ones we can run with KVM), and then classify the devices accordingly (mandatory in a machine where we care about the security boundary => we need to care about the security of the device; pluggable in a machine we care about => care; mandatory or pluggable in a machine we don't care about the security of => don't care about the device either). I think doing it that way fits (a) the way we've defined the boundary of our security policy as "with KVM" (b) the way users probably care more about machines rather than the specifics of which devices they happen to include and (c) the way there are fewer machines than devices. thanks -- PMM
[Qemu-devel] bochs-display and the future of VGA support
Hi! I just happened to read Gerd Hoffmann's post on the bochs-display [1] driver and was wondering what the future plans for VGA support are. Phoronix makes it sound like [2] that VGA support for guests is supposed to be removed which I find hard to believe. Since once VGA support is gone, QEMU would no longer be able to run older operating systems which is one of the key features of an emulator in my opinion. Can anyone tell me what the plans are? PS: I'm subscribed to the list, but currently don't receive any mailing list mail due to the high volume. So please CC me in your reply. Thanks, Adrian > [1] https://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display/ > [2] > https://www.phoronix.com/scan.php?page=news_item&px=QEMU-Legacy-Free-Display -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Qemu-devel] [PATCH 2/2] tests: fw_cfg: add reboot_timeout test case
Signed-off-by: Li Qiang
---
tests/fw_cfg-test.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tests/fw_cfg-test.c b/tests/fw_cfg-test.c
index 1c5103fe1c..37765f15f8 100644
--- a/tests/fw_cfg-test.c
+++ b/tests/fw_cfg-test.c
@@ -99,6 +99,15 @@ static void test_fw_cfg_boot_menu(void)
g_assert_cmpint(qfw_cfg_get_u16(fw_cfg, FW_CFG_BOOT_MENU), ==, boot_menu);
}
+static void test_fw_cfg_reboot_timeout(void)
+{
+uint32_t reboot_timeout;
+
+qfw_cfg_get_file(fw_cfg, "etc/boot-fail-wait",
+ &reboot_timeout, sizeof(reboot_timeout));
+g_assert_cmpint(reboot_timeout, <=, 65535);
+}
+
int main(int argc, char **argv)
{
QTestState *s;
@@ -106,7 +115,8 @@ int main(int argc, char **argv)
g_test_init(&argc, &argv, NULL);
-s = qtest_init("-uuid 4600cb32-38ec-4b2f-8acb-81c6ea54f2d8");
+s = qtest_init("-uuid 4600cb32-38ec-4b2f-8acb-81c6ea54f2d8"
+ " -boot reboot-timeout=4294967295");
fw_cfg = pc_fw_cfg_init(s);
@@ -125,6 +135,7 @@ int main(int argc, char **argv)
qtest_add_func("fw_cfg/max_cpus", test_fw_cfg_max_cpus);
qtest_add_func("fw_cfg/numa", test_fw_cfg_numa);
qtest_add_func("fw_cfg/boot_menu", test_fw_cfg_boot_menu);
+qtest_add_func("fw_cfg/reboot_timeout", test_fw_cfg_reboot_timeout);
ret = g_test_run();
--
2.17.1
[Qemu-devel] [PATCH 0/2] test: fw_cfg: add reboot-timeout test case
This patchset is the test case for the following patch: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg05254.html Li Qiang (2): tests: fw_cfg: add a function to get the fw_cfg file entry tests: fw_cfg: add reboot_timeout test case tests/fw_cfg-test.c | 13 - tests/libqos/fw_cfg.c | 30 ++ tests/libqos/fw_cfg.h | 2 ++ 3 files changed, 44 insertions(+), 1 deletion(-) -- 2.17.1
[Qemu-devel] [PATCH 1/2] tests: fw_cfg: add a function to get the fw_cfg file entry
This is useful to write qtest abount fw_cfg file entry.
Signed-off-by: Li Qiang
---
tests/libqos/fw_cfg.c | 30 ++
tests/libqos/fw_cfg.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/tests/libqos/fw_cfg.c b/tests/libqos/fw_cfg.c
index d0889d1e22..2dd7a498ab 100644
--- a/tests/libqos/fw_cfg.c
+++ b/tests/libqos/fw_cfg.c
@@ -16,6 +16,7 @@
#include "libqos/fw_cfg.h"
#include "libqtest.h"
#include "qemu/bswap.h"
+#include "standard-headers/linux/qemu_fw_cfg.h"
void qfw_cfg_select(QFWCFG *fw_cfg, uint16_t key)
{
@@ -54,6 +55,35 @@ uint64_t qfw_cfg_get_u64(QFWCFG *fw_cfg, uint16_t key)
return le64_to_cpu(value);
}
+void qfw_cfg_get_file(QFWCFG *fw_cfg, const char *filename,
+ void *data, size_t buflen)
+{
+uint32_t count;
+uint32_t i;
+unsigned char *filesbuf = NULL;
+uint32_t dsize;
+struct fw_cfg_file *p;
+
+qfw_cfg_get(fw_cfg, FW_CFG_FILE_DIR, &count, sizeof(count));
+count = be32_to_cpu(count);
+dsize = sizeof(uint32_t) + count * sizeof(struct fw_cfg_file);
+filesbuf = g_malloc0(dsize);
+qfw_cfg_get(fw_cfg, FW_CFG_FILE_DIR, filesbuf, dsize);
+p = (struct fw_cfg_file *)(filesbuf + 4);
+for (i = 0; i < count; ++i, ++p) {
+if (!strcmp(p->name, filename)) {
+uint32_t len = be32_to_cpu(p->size);
+uint16_t sel = be16_to_cpu(p->select);
+void *buf = g_malloc0(len);
+qfw_cfg_get(fw_cfg, sel, buf, len);
+memcpy(data, buf, buflen);
+g_free(buf);
+break;
+}
+}
+g_free(filesbuf);
+}
+
static void mm_fw_cfg_select(QFWCFG *fw_cfg, uint16_t key)
{
qtest_writew(fw_cfg->qts, fw_cfg->base, key);
diff --git a/tests/libqos/fw_cfg.h b/tests/libqos/fw_cfg.h
index 0353416af0..50e4227638 100644
--- a/tests/libqos/fw_cfg.h
+++ b/tests/libqos/fw_cfg.h
@@ -31,6 +31,8 @@ void qfw_cfg_get(QFWCFG *fw_cfg, uint16_t key, void *data,
size_t len);
uint16_t qfw_cfg_get_u16(QFWCFG *fw_cfg, uint16_t key);
uint32_t qfw_cfg_get_u32(QFWCFG *fw_cfg, uint16_t key);
uint64_t qfw_cfg_get_u64(QFWCFG *fw_cfg, uint16_t key);
+void qfw_cfg_get_file(QFWCFG *fw_cfg, const char *filename,
+ void *data, size_t buflen);
QFWCFG *mm_fw_cfg_init(QTestState *qts, uint64_t base);
QFWCFG *io_fw_cfg_init(QTestState *qts, uint16_t base);
--
2.17.1
Re: [Qemu-devel] [PATCH 2/4] migration: introduce lockless multithreads model
On 27/10/2018 01:33, Emilio G. Cota wrote: > On Wed, Oct 17, 2018 at 12:10:15 +0200, Paolo Bonzini wrote: >> On 16/10/2018 13:10, guangrong.x...@gmail.com wrote: > >> An idea: the total number of requests is going to be very small, and a >> PtrRing is not the nicest data structure for multiple producer/single >> consumer. So you could instead: > (snip) >> - now that you have request indices, you can replace the completion >> ptr_ring with a bitmap, and set a bit in the bitmap with set_bit_atomic >> to report completion. On the writer side you use find_next_bit to find > (snip) >> Emilio, can you review the above ideas? > > Sorry it took me a while to go through this. > > I like your suggestions. Just one nit; I'm not sure I understood > the use case very well, but I think using a bitmap to signal > completion might be suboptimal, since we'd have several > thread spinning on the same cacheline yet caring about > different bits. Requests are asynchronous, the bitmap is only used to find a free submission slot. You're right that the bitmap can bounce across processors, but I'm not sure how else you would do that because you don't know in advance how many submitting threads you have. It wouldn't be any worse if there was a spinlock. However, in the migration case there is only one submitting thread, so it's okay. :) Paolo > Xiao: a couple of suggestions > > - Since you'll be adding a generic module, make its commit and > description self-contained. That is, mentioning in the > log that this will be used for migration is fine, but please > describe the module (and the assumptions it makes about its > users) in general, so that someone that doesn't know anything > about migration can still understand this module (and hopefully > adopt it for other use cases). > > - I'd like to see a simple test program (or rather, benchmark) > that shows how this works. This benchmark would be completely > unrelated to migration; it should just be a simple test of > the performance/scalability of this module. > Having this benchmark would help (1) discuss and quantitately > evaluate modifications to the module, and (2) help others to > quickly understand what the module does. > See tests/qht-bench.c for an example. > > Thanks, > > Emilio >
