Re: [Qemu-devel] [PATCH v2 0/5] Removal of deprecated -no-kvm* options

On 07.05.2018 07:37, Markus Armbruster wrote: > Paolo Bonzini writes: > >> On 04/05/2018 19:01, Thomas Huth wrote: >>> The -no-kvm* options are a remainder of the ancient "qemu-kvm" >>> fork. They have never been officially documented in our qemu-doc, >>> they have been

Re: [Qemu-devel] [PATCH v2 0/5] Removal of deprecated -no-kvm* options

Paolo Bonzini writes: > On 04/05/2018 19:01, Thomas Huth wrote: >> The -no-kvm* options are a remainder of the ancient "qemu-kvm" >> fork. They have never been officially documented in our qemu-doc, >> they have been marked as deprecated in the sources since a very >> long

Re: [Qemu-devel] release retrospective, next release timing, numbering

On 04.05.2018 19:30, Richard Henderson wrote: > On 05/04/2018 06:20 AM, Kevin Wolf wrote: >> I'm not sure what the exact systemd model is, but as we came to the >> conclusion that there is no semantic difference between major and minor >> version number for QEMU, I'd just merge them. >> >> This

Re: [Qemu-devel] [PATCH v2 0/5] Removal of deprecated -no-kvm* options

On 04.05.2018 23:57, Paolo Bonzini wrote: > On 04/05/2018 19:01, Thomas Huth wrote: >> The -no-kvm* options are a remainder of the ancient "qemu-kvm" >> fork. They have never been officially documented in our qemu-doc, >> they have been marked as deprecated in the sources since a very >> long

[Qemu-devel] [PATCH 1/1] sandbox: avoid to compile options if CONFIG_SECCOMP undefined

If CONFIG_SECCOMP is undefined, the option 'elevatorprivileges' remains complied. This would make libvirt set the corresponding capability and then trigger the guest startup fails. So let's wrap the options with CONFIG_SECCOMP. Signed-off-by: Yi Min Zhao --- vl.c | 2 ++ 1

[Qemu-devel] [PATCH 0/1] Bug: Sandbox: libvirt breakdowns qemu guest

1. Problem Description == If QEMU is built without seccomp support, 'elevatorprivileges' remains compiled. This option of sandbox is treated as an indication for seccomp blacklist support in libvirt. This behavior is introduced by the libvirt commits 31ca6a5 and 3527f9d. It

Re: [Qemu-devel] [PULL 00/24] target-arm queue

Hi Peter, On 05/04/2018 07:58 PM, Peter Maydell wrote: > On 4 May 2018 at 18:15, Peter Maydell wrote: >> target-arm queue: Eric's SMMUv3 patchset, and an array >> of minor bugfixes and improvements from various others. >> >> thanks >> -- PMM >> >> The following changes

[Qemu-devel] [PATCH 2/2] migration: not wait RDMA_CM_EVENT_DISCONNECTED event after rdma_disconnect

When cancel migration during RDMA precopy, the source qemu main thread hangs sometime. The backtrace is: (gdb) bt #0 0x7f249eabd43d in write () from /lib64/libpthread.so.0 #1 0x7f24a1ce98e4 in rdma_get_cm_event (channel=0x4675d10, event=0x7ffe2f643dd0) at src/cma.c:2189

Re: [Qemu-devel] [PATCH] device_tree: Add qemu_fdt_totalsize function

On 6 May 2018 at 14:39, David Gibson wrote: > Well, I'm biased of course, but I think we'd be better off just > ditching the wrapper. In its present form it is so limited as to not > really add any value. If it was rewritten to do something useful > (e.g. handling

[Qemu-devel] [PATCH 1/2] migration: update index field when delete or qsort RDMALocalBlock

rdma_delete_block function deletes RDMALocalBlock base on index field, but not update the index field. So when next time invoke rdma_delete_block, it will not work correctly. If start and cancel migration repeatedly, some RDMALocalBlock not invoke ibv_dereg_mr to decrease kernel mm_struct vmpin.

[Qemu-devel] [PATCH 4/4] uninorth: remove token register from uninorth device

>From observation of various OS sources it can be seen that the token register introduced in 4e46dcdbd3 "PPC: Newworld: Add uninorth token register" is not required, since the only register currently implemented is the uninorth hardware version which is read-only. Remove the token register

[Qemu-devel] [PATCH 0/4] uninorth/macio: minor fixups

Here is another set of uninorth/macio fixups from various working branches in my QEMU git repository. Patch 1 adds min_access_size/max_access_size to unin_ops as suggested by David when reviewing my last set of uninorth patches. Patch 2 adds trace-events to the macio timer device in order to

[Qemu-devel] [PATCH 2/4] macio: add trace-events to timer device

Signed-off-by: Mark Cave-Ayland --- hw/misc/macio/macio.c | 3 +++ hw/misc/macio/trace-events | 4 2 files changed, 7 insertions(+) diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c index 79621eb879..f9a40eea81 100644 --- a/hw/misc/macio/macio.c

[Qemu-devel] [PATCH 3/4] macio: add impl min_access_size and max_access_size to timer_ops

>From testing all my local images the timer registers are only ever read or written with 32-bit accesses. Signed-off-by: Mark Cave-Ayland --- hw/misc/macio/macio.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/misc/macio/macio.c

[Qemu-devel] [PATCH 1/4] uninorth: add impl min_access_size and max_access_size to unin_ops

>From testing all my local images the uninorth registers are only ever read or written with 32-bit accesses. Signed-off-by: Mark Cave-Ayland --- hw/pci-host/uninorth.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/pci-host/uninorth.c

Re: [Qemu-devel] [PATCH] device_tree: Add qemu_fdt_totalsize function

On Sun, May 06, 2018 at 01:23:30PM +0100, Peter Maydell wrote: > On 5 May 2018 at 22:59, Michael Clark wrote: > > Okay, so an alternative is to call fdt_pack() and then fdt_totalsize(). > > Thanks! > > > > QEMU has its own wrapper around libfdt and neither the fdt_pack() nor > >

Re: [Qemu-devel] [PATCH] device_tree: Add qemu_fdt_totalsize function

On Sun, May 06, 2018 at 09:59:50AM +1200, Michael Clark wrote: > On Sat, May 5, 2018 at 11:48 PM, David Gibson > wrote: > > > On Sat, May 05, 2018 at 11:44:25AM +0100, Peter Maydell wrote: > > > cc'ing David -- is this the best way to do this? > > > > > > (It would

Re: [Qemu-devel] [PATCH] device_tree: Add qemu_fdt_totalsize function

On 5 May 2018 at 22:59, Michael Clark wrote: > Okay, so an alternative is to call fdt_pack() and then fdt_totalsize(). > Thanks! > > QEMU has its own wrapper around libfdt and neither the fdt_pack() nor > fdt_totalsize() functions are exposed. > > Some architecture use only the

[Qemu-devel] Compilation error for qemu-system-ppc on Fedora 28

Hi all, I get these errors compiling qemu-system-ppc on Fedora 28, gcc 8.0.1: /home/hsp/src/qemu-master/hw/ppc/e500.c: In function ‘ppce500_load_device_tree’: /home/hsp/src/qemu-master/hw/ppc/e500.c:442:37: error: ‘/pic@’ directive output may be truncated writing 5 bytes into a region of size