[PATCH 0/1] i386/tcg fix for IRET as used in dotnet runtime

/arch/amd64/context2.S#L241 shows how the dotnet runtime uses iret. I have booted BSD, solaris and macosX with this change, and await results for booting Windows from the Windows kernel team. I have not tested this with other modern JITers, such as Java, v8, or HHVM. Robert R. Henry (1): i386

[PATCH 1/1] i386/tcg: Allow IRET from user mode to user mode for dotnet runtime

. There, IRET returns from user mode to user mode. This bug manifested itself as a page fault in the guest Linux kernel. This bug appears to have been in QEMU since the beginning. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/249 Signed-off-by: Robert R. Henry --- target/i386/tcg/seg_helper.c

Help with QEMU DBUS display

s and never returns. node, err := introspect.Call(session.Object("org.qemu.Display1.VM", "/org/qemu/Display1/VM")) I'm not sure what's going wrong here, but I suspect I'm obtaining the file descriptor wrong (am I supposed to dial the socket?) or I'm doing things in the wr

MacOS cocoa/OpenGL

Hello Guys, Looks like we haven't yet official support for OpenGL on MacOS? I need to apply third-party patches to make it work. It would be great if these parts are imported to qemu and be official. Nowaways, it's really needed Acceleration on VMs for who uses Graphical interfaces browsing,

[PATCH v3 1/2] modules: introduces module_kconfig directive

to use module_kconfig is by passing the Kconfig option to module_kconfig (or the *config-devices.mak without CONFIG_). Signed-off-by: Jose R. Ziviani --- hw/display/qxl.c| 1 + hw/display/vhost-user-gpu-pci.c | 1 + hw/display/vhost-user-gpu.c | 1 + hw/display/vhost-user

[PATCH v3 2/2] modules: generates per-target modinfo

This patch changes the way modinfo is generated and built. Instead of one modinfo.c it generates one modinfo--softmmu.c per target. It aims a fine-tune control of modules by configuring Kconfig. Signed-off-by: Jose R. Ziviani --- meson.build | 25 +++--- scripts

[PATCH v3 0/2] modules: Improve modinfo.c support

odule_kconfig [Gerd] - Reworded the commit message a bit to improve a better understanding [myself] v1 -> v2: - Changed the approach to this problem after suggestions made by Paolo and Gerd. Thank you! Jose R. Ziviani (2): modules: introduces module_kconfig directive modules: generates per

Re: [PATCH v2 0/2] modules: Improve modinfo.c support

Hello, Gerd! On Tue, Sep 28, 2021 at 07:06:28AM +0200, Gerd Hoffmann wrote: > On Mon, Sep 27, 2021 at 11:11:58AM -0300, Jose R. Ziviani wrote: > > This patchset introduces the modinfo_need and changes > > modinfo-generate.py/meson.build to generate/link one modinfo per target. &

[PATCH v2 0/2] modules: Improve modinfo.c support

cho "Error: $qemu" done popd Also run make check and check-acceptance without any failures. Todo: - accelerators can be filtered as well (this only covers the device part), then the field QemuModinfo.arch can be removed. v1 -> v2: - Changed the approach to this pro

[PATCH v2 1/2] modules: introduces module_needs directive

problem. The correct way to use module_needs is by passing the Kconfig option (or the *config-devices.mak without CONFIG_). Signed-off-by: Jose R. Ziviani --- hw/display/qxl.c| 1 + hw/display/vhost-user-gpu-pci.c | 1 + hw/display/vhost-user-gpu.c | 1 + hw/display/vhost

[PATCH v2 2/2] modules: generates per-target modinfo

-by: Jose R. Ziviani --- meson.build | 25 +++ scripts/modinfo-generate.py | 40 + 2 files changed, 40 insertions(+), 25 deletions(-) diff --git a/meson.build b/meson.build index 2711cbb789..9d25ebb2f9 100644 --- a/meson.build +++ b

[PATCH v2 0/2] modules: Improve modinfo.c support

cho "Error: $qemu" done popd Also run make check and check-acceptance without any failures. Todo: - accelerators can be filtered as well (this only covers the device part), then the field QemuModinfo.arch can be removed. v1 -> v2: - Changed the approach to this pro

Re: [PATCH 1/2] meson: introduce modules_arch

Hello!! On Mon, Sep 20, 2021 at 09:03:28PM +0200, Paolo Bonzini wrote: > On 20/09/21 15:02, Jose R. Ziviani wrote: > > But, in anyway, I'll still need to store the target architecture that > > can use such core module, like I did here in this patch. Otherwise, > > if I comp

Re: [PATCH 1/2] meson: introduce modules_arch

Hello!! On Tue, Sep 21, 2021 at 07:25:42AM +0200, Gerd Hoffmann wrote: > Hi, > > > But, in anyway, I'll still need to store the target architecture that > > can use such core module, like I did here in this patch. Otherwise, > > if I compile different targets at the same time, I'll end up with

Re: [PATCH 1/2] meson: introduce modules_arch

. What do you think if I simply create one modinfo.c per target, like modinfo-s390x.c, modinfo-avr.c, etc? Each will only have the data structure filled with the right modules and linked only to its own qemu-system-arch. Best regards, Jose R Ziviani > > take care, > Gerd > signature.asc Description: Digital signature

Re: [PATCH 1/2] meson: introduce modules_arch

Hello! On Fri, Sep 17, 2021 at 09:14:04AM +0200, Gerd Hoffmann wrote: > Hi, > > > This variable keeps track of all modules enabled for a target > > architecture. This will be used in modinfo to refine the > > architectures that can really load the .so to avoid errors. > > I think this is the

[PATCH 2/2] modules: use a list of supported arch for each module

of architectures, obtained during the build time, to specify what targets can load each module. Signed-off-by: Jose R. Ziviani --- include/qemu/module.h | 2 +- meson.build | 18 +- scripts/modinfo-collect.py | 10 ++ scripts/modinfo-generate.py | 7

[PATCH 1/2] meson: introduce modules_arch

This variable keeps track of all modules enabled for a target architecture. This will be used in modinfo to refine the architectures that can really load the .so to avoid errors. Signed-off-by: Jose R. Ziviani --- hw/display/meson.build | 48 ++ hw/usb

[PATCH 0/2] modules: Improve modinfo.c architecture support

I Bridge (multiseat)" ... $ ./qemu-system-avr -nodefaults -display none -accel tcg -M none -device help | head ... Misc devices: name "guest-loader", desc "Guest Loader" name "loader", desc "Generic Loader" Jose R. Ziviani (2): meson: introduce m

[PATCH] tcg/arm: Fix tcg_out_vec_op function signature

*args, const int *const_args) ~~^~~~ ../tcg/tcg.c:120:41: note: previously declared as an array 'const TCGArg[16]' {aka 'const unsigned int[16]'} const TCGArg args[TCG_MAX_OP_ARGS], ~~^~~~ Signed-off-by: Jose R. Ziviani --- tcg/arm/tcg-target.c.inc | 3 ++- 1 file

Re: [PATCH] qemu-img: Allow target be aligned to sector size

On Thu, Aug 19, 2021 at 05:14:30PM +0200, Hanna Reitz wrote: > On 19.08.21 16:31, Jose R. Ziviani wrote: > > Hello Hanna, > > > > On Thu, Aug 19, 2021 at 12:12:00PM +0200, Hanna Reitz wrote: > > > We cannot write to images opened with O_DIRECT unless we all

Re: [PATCH] qemu-img: Allow target be aligned to sector size

Hello Hanna, On Thu, Aug 19, 2021 at 12:12:00PM +0200, Hanna Reitz wrote: > We cannot write to images opened with O_DIRECT unless we allow them to > be resized so they are aligned to the sector size: Since 9c60a5d1978, > bdrv_node_refresh_perm() ensures that for nodes whose length is not >

[PATCH v4] vga: don't abort when adding a duplicate isa-vga device

y, so it's not obvious that a VGA device already exists. This patch changes this behavior by displaying a message and exiting without crashing. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/44 Signed-off-by: Jose R. Ziviani --- v3 to v4: Used object_resolve_path_type instead of qemu_ram_blo

Re: [PATCH v3] vga: don't abort when adding a duplicate isa-vga device

On Tue, Aug 17, 2021 at 10:07:55AM +0200, Philippe Mathieu-Daudé wrote: > On 8/17/21 9:36 AM, Mark Cave-Ayland wrote: > > On 17/08/2021 08:25, Thomas Huth wrote: > > > >> On 16/08/2021 15.55, Jose R. Ziviani wrote: > >>> If users try to add an isa-vg

[PATCH v3] vga: don't abort when adding a duplicate isa-vga device

y, so it's not obvious that a VGA device already exists. This patch changes this behavior by displaying a message and exiting without crashing. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/44 Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Jose R. Ziviani --- v2 to v3: Improved error

[PATCH v2] vga: don't abort when adding a duplicate isa-vga device

y, so it's not obvious that a VGA device already exists. This patch changes this behavior by displaying a message and exiting without crashing. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/44 Signed-off-by: Jose R. Ziviani --- hw/display/vga-isa.c | 10 ++ 1 file changed, 10 insertion

[PATCH] vga: don't abort when adding a duplicate isa-vga device

y, so it's not obvious that a VGA device already exists. This patch changes this behavior by displaying a message and ignoring that device, starting qemu normally. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/44 Signed-off-by: Jose R. Ziviani --- hw/display/vga-isa.c | 9 + 1 file

Re: [PATCH v2 1/1] modules: Improve error message when module is not found

On Fri, Jul 23, 2021 at 05:27:25PM +0200, Claudio Fontana wrote: > On 7/23/21 4:36 PM, Jose R. Ziviani wrote: > > On Fri, Jul 23, 2021 at 04:02:26PM +0200, Claudio Fontana wrote: > >> On 7/23/21 3:50 PM, Jose R. Ziviani wrote: > >>> On Fri, Jul 23, 2021 at 11:41:19A

Re: [PATCH v2 1/1] modules: Improve error message when module is not found

On Fri, Jul 23, 2021 at 04:02:26PM +0200, Claudio Fontana wrote: > On 7/23/21 3:50 PM, Jose R. Ziviani wrote: > > On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote: > >> On 7/23/21 12:09 AM, Jose R. Ziviani wrote: > >>> When a module is not found

Re: [PATCH v2 1/1] modules: Improve error message when module is not found

On Fri, Jul 23, 2021 at 11:41:19AM +0200, Claudio Fontana wrote: > On 7/23/21 12:09 AM, Jose R. Ziviani wrote: > > When a module is not found, specially accelerators, QEMU displays > > a error message that not easy to understand[1]. This patch improves > > the readabili

[PATCH v2 1/1] modules: Improve error message when module is not found

dumped) ./qemu-system-x86_64 ... [2] qemu-system-x86_64 -accel tcg accel-tcg-x86_64 module is missing, install the package or config the library path correctly. Signed-off-by: Jose R. Ziviani --- accel/accel-softmmu.c | 5 - util/module.c | 14 -- 2 files changed, 12

[PATCH v2 0/1] Improve module accelerator error message

ing, install the package or config the library path correctly. Jose R. Ziviani (1): modules: Improve error message when module is not found accel/accel-softmmu.c | 5 - util/module.c | 14 -- 2 files changed, 12 insertions(+), 7 deletions(-) -- 2.32.0

Re: [RFC 3/3] qom: Improve error message in module_object_class_by_name()

On Wed, Jul 21, 2021 at 10:57:37AM +0100, Daniel P. Berrangé wrote: > On Wed, Jul 21, 2021 at 11:54:45AM +0200, Gerd Hoffmann wrote: > > > ObjectClass *module_object_class_by_name(const char *typename) > > > { > > > ObjectClass *oc; > > > @@ -1031,8 +1049,20 @@ ObjectClass

Re: [PATCH 0/1]

On Wed, Jul 21, 2021 at 07:24:02AM +0200, Thomas Huth wrote: > On 21/07/2021 00.13, Jose R. Ziviani wrote: > > Hello! > > > > This patch gives the ability to build TCG builtin even if > > --enable-modules is selected. This is useful to have a base > > QEMU with T

[PATCH 1/2] modules: Implement new helper functions

the module name given the typename. Signed-off-by: Jose R. Ziviani --- include/qemu/module.h | 4 +++ util/module.c | 57 +-- 2 files changed, 54 insertions(+), 7 deletions(-) diff --git a/include/qemu/module.h b/include/qemu/module.h index

[PATCH 2/2] qom: Improve error message in module_object_class_by_name()

is missing, install the package or config the library path correctly. ... Signed-off-by: Jose R. Ziviani --- accel/accel-softmmu.c | 5 - qom/object.c | 9 + 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/accel/accel-softmmu.c b/accel/accel-softmmu.c index 67276e4f52

[PATCH 0/2] Improve module accelerator error message

/boot/vmlinuz accel-tcg-x86_64 module is missing, install the package or config the library path correctly. Jose R. Ziviani (2): modules: Implement new helper functions qom: Improve error message in module_object_class_by_name() accel/accel-softmmu.c | 5 +++- include/qemu/module.h | 4

[PATCH 1/1] modules: Option to build native TCG with --enable-modules

Adds an option (--enable-tcg-builtin) to build TCG natively when --enable-modules argument is passed to the build system. It gives the opportunity to have this important accelerator built-in and still take advantage of the new modular system. Signed-off-by: Jose R. Ziviani --- configure

[PATCH 0/1]

Hello! This patch gives the ability to build TCG builtin even if --enable-modules is selected. This is useful to have a base QEMU with TCG native product but still using the benefits of modules. Thank you! Jose R. Ziviani (1): modules: Option to build native TCG with --enable-modules

Re: [RFC 3/3] qom: Improve error message in module_object_class_by_name()

On Mon, Jul 19, 2021 at 05:29:49PM +0200, Claudio Fontana wrote: > On 7/1/21 1:27 AM, Jose R. Ziviani wrote: > > module_object_class_by_name() calls module_load_qom_one if the object > > is provided by a dynamically linked library. Such library might not be > > ava

[RFC 1/3] modules: Add CONFIG_TCG_MODULAR in config_host

CONFIG_TCG_MODULAR is a complement to CONFIG_MODULES, in order to know if TCG will be a module, even if --enable-modules option was set. Signed-off-by: Jose R. Ziviani --- meson.build | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meson.build b/meson.build index 2d72b8cc06..c37a2358d4

[RFC 0/3] Improve module accelerator error message

://patchwork.kernel.org/project/qemu-devel/list/?series=506379 Jose R. Ziviani (3): modules: Add CONFIG_TCG_MODULAR in config_host modules: Implement module_is_loaded function qom: Improve error message in module_object_class_by_name() include/qemu/module.h | 3 +++ meson.build | 3

[RFC 3/3] qom: Improve error message in module_object_class_by_name()

or config the library path correctly. ... Signed-off-by: Jose R. Ziviani --- qom/object.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/qom/object.c b/qom/object.c index 6a01d56546..2d40245af9 100644 --- a/qom/object.c +++ b/qom/object.c @@ -1024,6 +1024,24

[RFC 2/3] modules: Implement module_is_loaded function

The function module_load_one() fills a hash table will all modules that were successfuly loaded. However, that table is a static variable of module_load_one(). This patch changes it and creates a function that informs whether a given module was loaded or not. Signed-off-by: Jose R. Ziviani

[RFC 2/2] modules: Fix warning in module_arch documentation

' Signed-off-by: Jose R. Ziviani --- include/qemu/module.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/qemu/module.h b/include/qemu/module.h index 8bc80535a4..456e190a55 100644 --- a/include/qemu/module.h +++ b/include/qemu/module.h @@ -115,7 +115,7 @@ void

[RFC 1/2] modules: Option to build native TCG with --enable-modules

Adds an option (--enable-tcg-builtin) to build TCG natively when --enable-modules argument is passed to the build system. It gives the opportunity to have the accelerator built-in and still take advantage of the new modular system. Signed-off-by: Jose R. Ziviani --- configure | 12

[RFC 0/2] Option to build native TCG with --enable-modules

Hello! I'm sending this simple patchset based on a patch still on review[1] just to understand if it's something that makes sense to the community. If so, I think it could be included in Gerd's patchset. Thank you! [1] https://patchwork.kernel.org/project/qemu-devel/list/?series=506379 Jose R

Re: [PATCH v4 00/34] modules: add meta-data database

Hello Gerd, Reviewed and tested successfully here. Thank you! Reviewed-by: Jose R. Ziviani On Thu, Jun 24, 2021 at 12:38:02PM +0200, Gerd Hoffmann wrote: > This patch series adds support for module meta-data. Today this is > either hard-coded in qemu (see qemu_load_module_fo

Re: [PATCH v3 03/24] modules: generate modinfo.c

ue, # to be > removed when added to a target > command: [modinfo_collect, '@INPUT@']) >endif > else > @@ -2055,6 +2055,17 @@ foreach d, list : modules >endforeach > endforeach > > +if enable_modules > + modinf

Re: [PATCH v3 03/24] modules: generate modinfo.c

Hello, Just a small change. On Fri, Jun 18, 2021 at 06:53:32AM +0200, Gerd Hoffmann wrote: > Add script to generate C source with a small > database containing the module meta-data. > > Signed-off-by: Gerd Hoffmann > --- > scripts/modinfo-generate.py | 84 +

Re: [PATCH 3/4] modules: module.h kerneldoc annotations

Hello Gerd, On Tue, Jun 22, 2021 at 02:51:09PM +0200, Gerd Hoffmann wrote: > --- > include/qemu/module.h | 59 +-- > 1 file changed, 45 insertions(+), 14 deletions(-) This header has a copyright date from 2009. Not sure if it requires an update. > >

[PATCH] tcg/arm: Fix tcg_out_op function signature

Commit 5e8892db93 fixed several function signatures but tcg_out_op for arm is missing. This patch fixes it as well. Signed-off-by: Jose R. Ziviani --- tcg/arm/tcg-target.c.inc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg

Performance issue with qcow2/raid

is using perf, but I appreciate if you have any hints measure qcow efficiently. [1] # lspci -vv | grep -i raid 1a:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108 [Invader] (rev 02) Kernel driver in use: megaraid_sas Kernel modules: megaraid_sas Thank you very much!

Re: Incorrect NVMe DLFEAT?

On 4/29/21, 10:22 AM, "Klaus Jensen" wrote: On Apr 29 16:51, Harris, James R wrote: >Hi, > Hi Jim, >I’m seeing SPDK test failures with QEMU NVMe controllers that I’ve >bisected to QEMU commit 2605257a26 (“hw/block/nvme: add the dataset

Incorrect NVMe DLFEAT?

Hi, I’m seeing SPDK test failures with QEMU NVMe controllers that I’ve bisected to QEMU commit 2605257a26 (“hw/block/nvme: add the dataset management command”). The failing tests are related to write zeroes handling. If an NVMe controller supports DSM, and DLFEAT indicates that deallocated

[Bug 1883784] Re: [ppc64le] qemu behavior differs from ppc64le hardware

I just ran the provided binaries on a qemu-system-ppc64 version 5.0-5 from Debian Bullseye and they also aborted there -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1883784 Title: [ppc64le] qemu

Re: [RHEL-8.1 virt 2/2] target/i386: sev: Do not pin the ram device memory region

- Original Message - > From: "Gary R Hook" > To: rhvirt-patc...@redhat.com > Cc: qemu-devel@nongnu.org, "Paolo Bonzini" , > gh...@redhat.com, "Eduardo Habkost" > , "Richard Henderson" > Sent: Tuesday, April 9, 2019 7:08

[Qemu-devel] [Bug 1776920] Re: qemu-img convert on Mac OSX creates corrupt images

Hi, I recently ran into problems and after a long time trying to find out the cause landed here, I got in trouble using a CentOs Cloud image: https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1905.qcow2.xz which extracts to a .qcow2 image with sha256 of:

[Qemu-devel] [RHEL-8.1 virt 1/2] memory: Fix the memory region type assignment order

BZ: 1667249 Branch: rhel-8.1.0 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1667249 Upstream Status: 4.0.0-rc1 Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20980582 Conflicts: None commit 2ddb89b00f947f785c9ca6742f28f954e3b75e62 Author: Singh, Brijesh Date:

[Qemu-devel] [RHEL-8.1 virt 2/2] target/i386: sev: Do not pin the ram device memory region

100644 --- a/target/i386/sev.c +++ b/target/i386/sev.c @@ -130,6 +130,17 @@ sev_ram_block_added(RAMBlockNotifier *n, void *host, size_t size) { int r; struct kvm_enc_region range; +ram_addr_t offset; +MemoryRegion *mr; + +/* + * The RAM device presents a memory region that

[Qemu-devel] [RHEL-8.1 virt 0/2] Enable SEV VM to boot with assigned PCI device

o C. L. de Paula (2): redhat: branching qemu-kvm to rhel-8.1.0 redhat: renaming branch to rhel-8.1.0 Gary R Hook (2): Subject: memory: Fix the memory region type assignment order Subject: target/i386: sev: Do not pin the ram device memory region .gitpublish | 6 +++--- memory.c

[Qemu-devel] [Bug 1818880] Re: Deadlock when detaching network interface

** Patch removed: "Debdiff for xenial v2" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5244567/+files/xenial_v2.debdiff ** Patch added: "Correct debdiff for xenial v2"

[Qemu-devel] [Bug 1818880] Re: Deadlock when detaching network interface

Patch v2: Added missing DEP3 info and corrected pkg version ** Patch added: "Debdiff for xenial v2" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5244567/+files/xenial_v2.debdiff -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1818880] Re: Deadlock when detaching network interface

** Changed in: qemu (Ubuntu Disco) Assignee: Heitor R. Alves de Siqueira (halves) => (unassigned) ** Changed in: qemu (Ubuntu Cosmic) Assignee: Heitor R. Alves de Siqueira (halves) => (unassigned) ** Changed in: qemu (Ubuntu Bionic) Assignee: Heitor R. Alves de Siqueira (

[Qemu-devel] [Bug 1818880] Re: Deadlock when detaching network interface

** Patch added: "Debdiff for xenial" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5244384/+files/xenial.debdiff ** Description changed: [Impact] Qemu guests hang indefinitely [Description] When running a Qemu guest with VirtIO network interfaces, detaching an

[Qemu-devel] [Bug 1818880] Re: Deadlock when detaching network interface

** Also affects: cloud-archive Importance: Undecided Status: New ** Changed in: cloud-archive Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1818880 Title:

[Qemu-devel] [Bug 1818880] [NEW] Deadlock when detaching network interface

emu Importance: Undecided Status: Fix Released ** Affects: qemu (Ubuntu) Importance: Undecided Assignee: Heitor R. Alves de Siqueira (halves) Status: Fix Released ** Affects: qemu (Ubuntu Xenial) Importance: Undecided Assignee: Heitor R. Alves de Siqueira (hal

[Qemu-devel] [Bug 1787754] [NEW] qemu sparc -cpu help does not generate correct display

Public bug reported: The output for the "-cpu help" on the Sparc executables is not generating accurate information. Running ./qemu-sparc64 -cpu help produces: Sparc Fujitsu Sparc64 IU 00040002 FPU MMU NWINS 4 Sparc Fujitsu Sparc64 III IU 00040003 FPU

[Qemu-devel] unknown keycodes

(qemu) unknown keycodes `empty+aliases(qwerty)’, please report to qemu-devel@nongnu.org reported. signature.asc Description: Message signed with OpenPGP using GPGMail

Re: [Qemu-devel] [PATCH] virtio_net: flush uncompleted TX on reset

Greg Kurz <gr...@kaod.org> wrote on 08/03/2018 12:27:37 AM: > From: Greg Kurz <gr...@kaod.org> > To: qemu-devel@nongnu.org > Cc: "Michael S. Tsirkin" <m...@redhat.com>, Jason Wang > <jasow...@redhat.com>, R Nageswara Sastry <nasas...@in.ibm.c

Re: [Qemu-devel] [patch] linux-user/syscall.c: Fix missing break for host_to_target_cmsg

On 2018-02-15 20:17, Laurent Vivier wrote: Le 08/02/2018 à 10:56, Nageswara R Sastry a écrit : On 2018-02-07 19:27, Laurent Vivier wrote: Le 07/02/2018 à 10:49, no-re...@patchew.org a écrit : Hi, This series failed build test on s390x host. Please find the details below. ...   CC

Re: [Qemu-devel] [patch] linux-user/syscall.c: Fix missing break for host_to_target_cmsg

On 2018-02-07 19:27, Laurent Vivier wrote: Le 07/02/2018 à 10:49, no-re...@patchew.org a écrit : Hi, This series failed build test on s390x host. Please find the details below. ... CC aarch64_be-linux-user/linux-user/syscall.o In file included from

[Qemu-devel] [patch] linux-user/syscall.c: Fix missing break for host_to_target_cmsg

Detected by by Coverity (CID 1385425) with out this break statement the assigned value of 'tgt_len' at line 1824 will be replaced by value of 'tgt_len' at line 1830. Signed-off-by: Nageswara R Sastry <rnsas...@linux.vnet.ibm.com> --- linux-user/syscall.c | 1 + 1 file changed, 1 ins

[Qemu-devel] [patch] linux-user/syscall.c: Fix missing break for host_to_target_cmsg

Detected by by Coverity (CID 1385425) with out this break statement the assigned value of 'tgt_len' at line 1824 will be replaced by value of 'tgt_len' at line 1830. Signed-off-by: Nageswara R Sastry <rnsas...@linux.vnet.ibm.com> --- linux-user/syscall.c | 1 + 1 file changed, 1 ins

Re: [Qemu-devel] [RFC v1] block/NVMe: introduce a new vhost NVMe host device to QEMU

On 1/29/18, 8:29 AM, "Stefan Hajnoczi" wrote: Each new feature has a cost in terms of maintainance, testing, documentation, and support. Users need to be educated about the role of each available storage controller and how to choose between them.

Re: [Qemu-devel] [PATCH 2/2] virtio: fix IO request length in virtio SCSI/block

equential read with >> 1 MB size results in the following pattern of the IO from the guest: >> 8,16 115754 2.766095122 2071 D R 2095104 + 1008 [dd] >> 8,16 115755 2.766108785 2071 D R 2096112 + 1008 [dd] >> 8,16 115756 2.766113486

[Qemu-devel] [Bug 1719870] Re: Converting 100G VHDX fixed image to QCOW2 fails

Bug is reproducible with setting VHDX Fixed Logicalsectorsize to 4096bytes >10G image created reflects as 1.2G virtual size in Qemu-img PS F:\> new-vhd -path test.vhdx -BlockSizeBytes 134217728 -SizeBytes 10737418240 -Fixed -LogicalSectorSizeBytes 4096 ComputerName: Path

[Qemu-devel] [Bug 1719870] Re: Converting 100G VHDX fixed image to QCOW2 fails

PS > Get-VHD .\VM.vhdx ComputerName: Server1 Path: \VM.vhdx VhdFormat : VHDX VhdType : Fixed FileSize: 107378376704 Size: 107374182400 MinimumSize : 107374182400 LogicalSectorSize :

[Qemu-devel] [Bug 1719870] Re: Converting 100G VHDX fixed image to QCOW2 fails

Command capture, PS > & 'C:\Program Files\qemu\qemu-img.exe' --version qemu-img version 2.10.0 (v2.10.0-11669-g579e69bd5b-dirty) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1719870] [NEW] Converting 100G VHDX fixed image to QCOW2 fails

Public bug reported: Virtual Size recognized incorrectly for VHDX fixed disk and conversion fails with error Expression: !qiov || bytes == qiov->size PS > & 'C:\Program Files\qemu\qemu-img.exe' --version qemu-img version 2.10.0 (v2.10.0-11669-g579e69bd5b-dirty) Copyright (c) 2003-2017 Fabrice

Re: [Qemu-devel] [PATCH v5 0/4] Introduce vhost-user-scsi and sample application

> On Jul 6, 2017, at 10:11 AM, Marc-André Lureau <marcandre.lur...@redhat.com> > wrote: > > Hi > > - Original Message - >> >>> On Jul 6, 2017, at 9:56 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> >>> >&

Re: [Qemu-devel] [PATCH v5 0/4] Introduce vhost-user-scsi and sample application

> On Jul 6, 2017, at 10:06 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > On 06/07/2017 19:03, Harris, James R wrote: >> >> vhost-user-blk: >> >> We have an initial implementation in our SPDK QEMU repo. Changpeng Liu >> (adde

Re: [Qemu-devel] [PATCH v5 0/4] Introduce vhost-user-scsi and sample application

> On Jul 6, 2017, at 9:56 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > On 06/07/2017 18:54, Harris, James R wrote: >> Hi Michael, >> >> Yes - we (SPDK team at Intel) have this on our TODO list, in addition >> to a polled mode virtio-sc

Re: [Qemu-devel] [PATCH v5 0/4] Introduce vhost-user-scsi and sample application

> On Jul 6, 2017, at 6:41 AM, Michael S. Tsirkin wrote: > > On Fri, Apr 21, 2017 at 02:53:33PM +, Felipe Franciosi wrote: >> >>> On 2 Mar 2017, at 21:47, Michael S. Tsirkin wrote: >>> >>> On Thu, Mar 02, 2017 at 10:25:49AM -0800, Felipe Franciosi wrote:

Re: [Qemu-devel] What is the best commit for record-replay?

I'm trying to use the deterministic record/replay feature, and I would like to know which commit I should take to get it work. In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as >> >>> Can you retry with the latest rc? There were some fixes regarding rr since >>>

Re: [Qemu-devel] What is the best commit for record-replay?

>> Hi, >> >> I'm trying to use the deterministic record/replay feature, and I would >> like to know which commit I should take to get it work. >> In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as > Can you retry with the latest rc? There were some fixes regarding rr since >

[Qemu-devel] What is the best commit for record-replay?

Hi, I'm trying to use the deterministic record/replay feature, and I would like to know which commit I should take to get it work. In RC0 it seems to be broken. I tried pre-MTTCG commit 2421f381dc, as mentioned here: http://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg02657.html with this

[Qemu-devel] [Bug 1655708] Re: target/ppc/int_helper.c:2806: strange expression ?

** Changed in: qemu Assignee: (unassigned) => Jose R. Ziviani (jrziviani) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1655708 Title: target/ppc/int_helper.c:2806: strange express

[Qemu-devel] [PATCH v2] target-mips: Implement Loongson 3A processor.

<< CP0St_KX)) != 0; if (((R == 0 && UX) || (R == 1 && SX) || (R == 3 && KX)) && -(!(env->insn_flags & (INSN_LOONGSON2E | INSN_LOONGSON2F +(!(env->insn_flags & INSN_LOONGSON)))

[Qemu-devel] [PATCH] target-mips: Implement Loongson 3A processor.

From: Heiher Signed-off-by: Heiher --- target-mips/mips-defs.h | 2 + target-mips/translate.c | 449 ++- target-mips/translate_init.c | 24 +++ 3 files changed, 469 insertions(+), 6 deletions(-) diff

Re: [Qemu-devel] [PATCH 00/15] optimize Qemu RSS usage

On 10/31/2016 05:00 PM, Michael R. Hines wrote: On 10/18/2016 05:47 AM, Peter Lieven wrote: Am 12.10.2016 um 23:18 schrieb Michael R. Hines: Peter, Greetings from DigitalOcean. We're experiencing the same symptoms without this patch. We have, collectively, many gigabytes of un-planned

Re: [Qemu-devel] [PATCH 00/15] optimize Qemu RSS usage

On 10/18/2016 05:47 AM, Peter Lieven wrote: Am 12.10.2016 um 23:18 schrieb Michael R. Hines: Peter, Greetings from DigitalOcean. We're experiencing the same symptoms without this patch. We have, collectively, many gigabytes of un-planned-for RSS being used per-hypervisor that we would like

Re: [Qemu-devel] [PATCH 00/15] optimize Qemu RSS usage

Thank you for the response! I'll run off and test that. =) /* * Michael R. Hines * Senior Engineer, DigitalOcean. */ On 10/18/2016 05:47 AM, Peter Lieven wrote: Am 12.10.2016 um 23:18 schrieb Michael R. Hines: Peter, Greetings from DigitalOcean. We're experiencing the same symptoms

Re: [Qemu-devel] [PATCH 00/15] optimize Qemu RSS usage

for it? - Michael /* * Michael R. Hines * Senior Engineer, DigitalOcean. */ On 06/28/2016 04:01 AM, Peter Lieven wrote: I recently found that Qemu is using several hundred megabytes of RSS memory more than older versions such as Qemu 2.2.0. So I started tracing memory allocation and found 2

Re: [Qemu-devel] [PATCH 0/3] RDMA error handling

Reviewed-by: Michael R. Hines <mich...@hinespot.com> (By the way, I no longer work for IBM and no longer have direct access to RDMA hardware. If someone is willing to let me login to something that does in the future, I don't mind debugging things. I just don't have any hardware of

Re: [Qemu-devel] [PATCH v5 0/7] Deterministic replay extensions

> This set of patches is related to the reverse execution and deterministic > replay of qemu execution. It includes recording and replaying of serial > devices > and block devices operations. > > With these patches one can record and deterministically replay behavior > of the system with

[Qemu-devel] cpu_memory_rw_debug doesn't work on MIPS?

If I understand correctly, the most advanced MMU that QEMU emulates for MIPS is "R4000-style" MMU - i.e. a "software-managed" TLB, where on TLB miss QEMU just emulates exception that should be handled by the guest OS. So, QEMU doesn't walk through the page directory, like it does when emulating

[Qemu-devel] Developing custom device for ARM

Hello, I implemented a simple sys_bus device that only communicates through port io. The purpose of this device is to be accessible via /dev/port only, with no need for any additional kernel modules. I Defined the memory region using memory_region_init_io and registered it using sysbus_add_io. I

Re: [Qemu-devel] Memory mapping on MIPS

> > Here is an excerpt from r4k_map_address(), related to addresses >= 0x8000. > > Actually, it maps 0x8010 and 0xA010 to the same physical > > address. What's the idea behind that? > > 0x8010 is kseg0 whereas 0xA010 is kseg1, both segments are > unmapped thus both refer to the

Re: [Qemu-devel] Memory mapping on MIPS

> > Here is an excerpt from r4k_map_address(), related to addresses >= 0x8000. > > Actually, it maps 0x8010 and 0xA010 to the same physical > > address. What's the idea behind that? > > 0x8010 is kseg0 whereas 0xA010 is kseg1, both segments are > unmapped thus both refer to the

  1   2   3   4   5   6   7   8   >