Re: [Qemu-devel] [RFC v4 15/27] monitor: let monitor_{suspend|resume} thread safe

On Thu, Nov 23, 2017 at 11:23:16AM +, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > Monitor code now can be run in more than one thread. Let the suspend > > and resume code be thread safe. > > > > Reviewed-by: Fam Zheng > > Signed-off-by: Peter

[Qemu-devel] [PATCH v1 2/2] tests: add test to check VirtQueue object

From: Prasad J Pandit An uninitialised VirtQueue object or one with Vring.align field set to zero(0) could lead to arithmetic exceptions. Add a unit test to validate it. Signed-off-by: Prasad J Pandit --- tests/virtio-blk-test.c | 21

Re: [Qemu-devel] [PATCH 01/25] ppc/xics: introduce an icp_create() helper

On 11/24/2017 03:51 AM, David Gibson wrote: > On Thu, Nov 23, 2017 at 02:29:31PM +0100, Cédric Le Goater wrote: >> The sPAPR and the PowerNV core objects create the interrupt presenter >> object of the CPUs in a very similar way. Let's provide a common >> routine in which we use the presenter

[Qemu-devel] [PATCH v1 0/2] check VirtiQueue Vring objects

From: Prasad J Pandit Hello, An user could attempt to use an uninitialised VirtQueue object or set Vring object with undue values, raising an unexpected exception in Qemu. This patch set fixes this issue and also adds a unit test to the suite. Thank you. -- Prasad J

[Qemu-devel] [PATCH v1 1/2] virtio: check VirtQueue Vring object is set

From: Prasad J Pandit An user could attempt to use an uninitialised VirtQueue object or unset Vring.align leading to a arithmetic exception. Add check to avoid it. Reported-by: Zhangboxian Signed-off-by: Prasad J Pandit

Re: [Qemu-devel] [RFC v4 09/27] monitor: create monitor dedicate iothread

On Thu, Nov 23, 2017 at 10:53:08AM +, Daniel P. Berrange wrote: > On Thu, Nov 23, 2017 at 10:51:43AM +, Dr. David Alan Gilbert wrote: > > * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote: > > > * Peter Xu (pet...@redhat.com) wrote: > > > > Create one IOThread for the monitors, prepared

[Qemu-devel] [PATCH v2 3/3] cpu: put AddressSpace into CPUAddressSpace

Now we can put AddressSpace into CPUAddressSpace struct, then we don't need dynamic allocation of AddressSpaces. Suggested-by: Paolo Bonzini Signed-off-by: Peter Xu --- exec.c | 33 ++--- 1 file changed, 18 insertions(+), 15

[Qemu-devel] [PATCH v2 1/3] cpu: refactor cpu_address_space_init()

Normally we create an address space for that CPU and pass that address space into the function. Let's just do it inside to unify address space creations. It'll simplify my next patch to rename those address spaces. Signed-off-by: Peter Xu --- cpus.c | 5

[Qemu-devel] [PATCH v2 2/3] cpu: suffix cpu address spaces with cpu index

Renaming cpu address space names so that they won't be the same when there are more than one. Signed-off-by: Peter Xu --- exec.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/exec.c b/exec.c index d845542139..41f89f8164 100644 --- a/exec.c +++

[Qemu-devel] [PATCH v2 0/3] cpu: suffix cpu address spaces with indexes

v2: - drop patch 1 since merged - add last patch as suggested by Paolo Please review, thanks. Peter Xu (3): cpu: refactor cpu_address_space_init() cpu: suffix cpu address spaces with cpu index cpu: put AddressSpace into CPUAddressSpace cpus.c | 5 + exec.c

Re: [Qemu-devel] [PATCH 2/3] cpu: refactor cpu_address_space_init()

On Thu, Nov 23, 2017 at 05:06:31PM +0100, Paolo Bonzini wrote: > On 23/11/2017 10:23, Peter Xu wrote: > > +const char *prefix, MemoryRegion *mr) > > { > > CPUAddressSpace *newas; > > +AddressSpace *as = g_new0(AddressSpace, 1); > > + > > +assert(mr); > > +

[Qemu-devel] [PATCH v4 2/3] spapr/rtas: fix reboot of a a SMP TCG guest

Just like for hot unplug CPUs, when a guest is rebooted, the secondary CPUs can be awaken by the decrementer and start entering SLOF at the same time the boot CPU is. To be safe, let's disable on the secondaries all the exceptions which can cause an exit while the CPU is in power-saving mode.

[Qemu-devel] [PATCH v4 0/3] disable the decrementer interrupt when a CPU is unplugged

Hello, When a CPU is stopped with the 'stop-self' RTAS call, its state 'halted' is switched to 1 and, in this case, the MSR is not taken into account anymore in the cpu_has_work() routine. Only the pending hardware interrupts are checked with their LPCR:PECE* enablement bit. If the DECR timer

[Qemu-devel] [PATCH v4 3/3] spapr/rtas: do not reset the MSR in stop-self command

When a CPU is stopped with the 'stop-self' RTAS call, its state 'halted' is switched to 1 and, in this case, the MSR is not taken into account anymore in the cpu_has_work() routine. Only the pending hardware interrupts are checked with their LPCR:PECE* enablement bit. The CPU is now also

[Qemu-devel] [PATCH v4 1/3] spapr/rtas: disable the decrementer interrupt when a CPU is unplugged

When a CPU is stopped with the 'stop-self' RTAS call, its state 'halted' is switched to 1 and, in this case, the MSR is not taken into account anymore in the cpu_has_work() routine. Only the pending hardware interrupts are checked with their LPCR:PECE* enablement bit. If the DECR timer fires

Re: [Qemu-devel] [PATCH] pcc: define the Power-saving mode Exit Cause Enable bits in PowerPCCPUClass

On 11/24/2017 01:09 AM, David Gibson wrote: > On Thu, Nov 23, 2017 at 06:05:24PM +0100, Cédric Le Goater wrote: >> and use the value to define precisely the default value of the LPCR in >> the helper routine cpu_ppc_set_papr() >> >> Signed-off-by: Cédric Le Goater > > Applied to

Re: [Qemu-devel] [PATCH 1/3] pci: Initialize pci_dev->name before use

On Fri, Nov 24, 2017 at 11:16:53AM +1100, Alexey Kardashevskiy wrote: > On 23/11/17 20:23, Peter Xu wrote: > > From: Alexey Kardashevskiy > > > > This moves pci_dev->name initialization earlier so > > pci_dev->bus_master_as could get a name instead of an empty string. > > > >

[Qemu-devel] [PATCH v3] rcu: reduce more than 7MB heap memory by malloc_trim()

Since there are some issues in memory alloc/free machenism in glibc for little chunk memory, if Qemu frequently alloc/free little chunk memory, the glibc doesn't alloc little chunk memory from free list of glibc and still allocate from OS, which make the heap size bigger and bigger. This patch

Re: [Qemu-devel] [PATCH v2] rcu: reduce more than 7MB heap memory by malloc_trim()

On Thu, Nov 23, 2017 at 11:19:43AM +, Stefan Hajnoczi wrote: > On Thu, Nov 23, 2017 at 02:41:16PM +0800, Yang Zhong wrote: > > Since there are some issues in memory alloc/free machenism > > in glibc for little chunk memory, if Qemu frequently > > alloc/free little chunk memory, the glibc

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 1/7] s390x/pci: factor out endianess conversion

在 2017/11/23 下午8:18, Thomas Huth 写道: On 23.11.2017 13:07, Yi Min Zhao wrote: 在 2017/11/23 下午6:33, Cornelia Huck 写道: On Thu, 23 Nov 2017 11:25:10 +0100 Thomas Huth wrote: On 23.11.2017 11:08, Cornelia Huck wrote: On Thu, 23 Nov 2017 11:01:23 +0100 Thomas Huth

Re: [Qemu-devel] [PATCH 0/1] block: Workaround for the iotests errors

On Fri, Nov 24, 2017 at 01:57:46AM +0800, Fam Zheng wrote: > Jeff's block job patch made the latent drain bug visible, and I find this > patch, which by itself also makes some sense, can hide it again. :) With it > applied we are at least back to the ground where patchew's iotests (make >

Re: [Qemu-devel] [QEMU-PPC] [PATCH 0/2] target/ppc: hpt on radix and compat migration fixes

On Fri, Nov 24, 2017 at 03:23:23PM +1100, Suraj Jitindar Singh wrote: > The following patches fix 2 migration bugs. > > The first being that migration of a hpt guest on a radix host currently > doesn't work. The first patch fixes this by installing the correct value > in patb_entry. > > The

[Qemu-devel] [QEMU-PPC] [PATCH 2/2] target/ppc: Fix setting of cpu->compat_pvr on incoming migration

cpu->compat_pvr is used to store the current compat mode of the cpu. On the receiving side during incoming migration we check compatibility with the compat mode by calling ppc_set_compat(). However we fail to set the compat mode with the hypervisor since the "new" compat mode doesn't differ from

[Qemu-devel] [QEMU-PPC] [PATCH 0/2] target/ppc: hpt on radix and compat migration fixes

The following patches fix 2 migration bugs. The first being that migration of a hpt guest on a radix host currently doesn't work. The first patch fixes this by installing the correct value in patb_entry. The second bug is that migration in a compat mode will currently result in no compat mode

[Qemu-devel] [QEMU-PPC] [PATCH 1/2] target/ppc: Move setting of patb_entry on hash table init

The patb_entry is used to store the location of the process table in guest memory. The msb is also used to indicate the mmu mode of the guest, that is patb_entry & 1 << 63 ? radix_mode : hash_mode. Currently we set this to zero in spapr_setup_hpt_and_vrma() since if this function gets called then

Re: [Qemu-devel] [PATCH v8 4/5] crash: export paddr_vmcoreinfo_note()

On Thu, Nov 23, 2017 at 06:36:57AM -0800, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 03:02:05PM +0100, Marc-André Lureau wrote: > > The following patch is going to use the symbol from the fw_cfg module, > > to call the function and write the note location details in the > > vmcoreinfo

Re: [Qemu-devel] [PATCH 04/25] spapr: move the IRQ allocation routines under the machine

On Thu, Nov 23, 2017 at 02:29:34PM +0100, Cédric Le Goater wrote: > Also change the prototype to use a sPAPRMachineState and prefix them > with spapr_irq_. It will let us synchronise the IRQ allocation with > the XIVE interrupt mode when available. > > Signed-off-by: Cédric Le Goater

Re: [Qemu-devel] [PATCH 06/25] spapr: introduce a spapr_irq_get_qirq() helper

On Thu, Nov 23, 2017 at 02:29:36PM +0100, Cédric Le Goater wrote: > xics_get_qirq() is only used by the sPAPR machine. Let's move it there > and change its name to reflect its scope. It will be useful for XIVE > support which will use its own set of qirqs. > > Signed-off-by: Cédric Le Goater

Re: [Qemu-devel] [PATCH 05/25] spapr: introduce a spapr_irq_set() helper

On Thu, Nov 23, 2017 at 02:29:35PM +0100, Cédric Le Goater wrote: > It will make synchronisation easier with the XIVE interrupt mode when > available. The 'irq' parameter refers to the global IRQ number space. > > Signed-off-by: Cédric Le Goater s/spapr_irq_set/spapr_irq_set_lsi/

Re: [Qemu-devel] [PATCH 01/25] ppc/xics: introduce an icp_create() helper

On Thu, Nov 23, 2017 at 02:29:31PM +0100, Cédric Le Goater wrote: > The sPAPR and the PowerNV core objects create the interrupt presenter > object of the CPUs in a very similar way. Let's provide a common > routine in which we use the presenter 'type' as a child identifier. > > Signed-off-by:

Re: [Qemu-devel] [PATCH 02/25] ppc/xics: assign of the CPU 'intc' pointer under the core

On Thu, Nov 23, 2017 at 02:29:32PM +0100, Cédric Le Goater wrote: > The 'intc' pointer of the CPU references the interrupt presenter in > the XICS interrupt mode. When the XIVE interrupt mode is available and > activated, the machine will need to reassign this pointer to reflect > the change. > >

Re: [Qemu-devel] [PATCH for 2.11] virtio-net: don't touch virtqueue if vm is stopped

On 2017年11月23日 18:59, Stefan Hajnoczi wrote: On Thu, Nov 23, 2017 at 11:37:46AM +0800, Jason Wang wrote: Guest state should not be touched if VM is stopped, unfortunately we didn't check running state and tried to drain tx queue unconditionally in virtio_net_set_status(). A crash was then

Re: [Qemu-devel] [Qemu-ppc] [PATCH 06/12] i2c: add mpc8540 i2c controller

On Thu, Nov 23, 2017 at 04:39:10PM +0100, Cédric Le Goater wrote: > Hello, > > The model should be QOM'ified. > > On 11/20/2017 04:24 AM, Michael Davidsaver wrote: > > Signed-off-by: Michael Davidsaver > > --- > > hw/i2c/Makefile.objs | 1 + > > hw/i2c/mpc8540_i2c.c

Re: [Qemu-devel] [PATCH 01/12] e500: add board config options

On Wed, Nov 22, 2017 at 11:55:04AM -0600, Michael Davidsaver wrote: > On 11/21/2017 09:28 PM, David Gibson wrote: > > On Sun, Nov 19, 2017 at 09:24:09PM -0600, Michael Davidsaver wrote: > >> allow board code to skip common NIC and guest image setup > >> and configure decrementor frequency. > >>

Re: [Qemu-devel] [PATCH 1/3] pci: Initialize pci_dev->name before use

On 23/11/17 20:23, Peter Xu wrote: > From: Alexey Kardashevskiy > > This moves pci_dev->name initialization earlier so > pci_dev->bus_master_as could get a name instead of an empty string. > > Reviewed-by: Philippe Mathieu-Daudé > Reviewed-by: Peter Xu

Re: [Qemu-devel] [PATCH] pcc: define the Power-saving mode Exit Cause Enable bits in PowerPCCPUClass

On Thu, Nov 23, 2017 at 06:05:24PM +0100, Cédric Le Goater wrote: > and use the value to define precisely the default value of the LPCR in > the helper routine cpu_ppc_set_papr() > > Signed-off-by: Cédric Le Goater Applied to ppc-for-2.12. Sorry, I forgot if we needed this for

Re: [Qemu-devel] [PATCH 1/2] virtio: check VirtQueue Vring object is set

On 23/11/2017 20:01, P J P wrote: > @@ -182,7 +182,7 @@ void virtio_queue_update_rings(VirtIODevice *vdev, int n) > { > VRing *vring = >vq[n].vring; > > -if (!vring->desc) { > +if (!vring->desc || !vring->align) { > /* not yet setup -> nothing to do */ > return; >

Re: [Qemu-devel] [PATCH] memory-internal.h: Remove obsolete claim that header is obsolete

On 21/11/2017 17:04, Philippe Mathieu-Daudé wrote: >> I'm not sure what you're suggesting. I definitely think the >> s390 usage is pretty nasty but I guess it would need some >> rework to get rid of. For everything else, it's nice >> to have somewhere to share these things. You could argue >> for

Re: [Qemu-devel] [PATCH] tcg: Fix complilation with TCG

On 22/11/2017 13:14, Peter Maydell wrote: >> We do this all of the time for more regular tests that are obviously >> compile-time. I am a really big fan of this, because it makes sure that the >> (usually 32-bit) else branch continues to compile. > I'm happy with code that is "we assume the

Re: [Qemu-devel] [PATCH 13/25] spapr: introduce the XIVE Event Queues

On Thu, 2017-11-23 at 14:29 +0100, Cédric Le Goater wrote: > The Event Queue Descriptor (EQD) table, also known as Event Notification > Descriptor (END), is one of the internal tables the XIVE interrupt > controller uses to redirect exception from event sources to CPU > threads. Keep in mind tha

Re: [Qemu-devel] [PATCH v7 11/13] xilinx_spips: Don't set TX FIFO UNDERFLOW at cmd done

Good day Alistair, Thank you very much for reviewing agian! I will update the patch set according to your comments and come back with a new version (v8)! Best regards, Francisco Iglesias On 23 November 2017 at 01:39, Alistair Francis wrote: > On Thu, Nov 2, 2017 at 5:01

Re: [Qemu-devel] [PATCH] Remove MemoryRegionSection check code from sparc_cpu_get_phys_page_debug()

On 22/11/17 06:32, Jean-Christophe Dubois wrote: > This code is preventing the MMU debug code from displaying virtual > mappings of IO devices (anything that is not located in the RAM). > > Before this patch, Qemu would output 0x (-1) as the > physical address corresponding to a

[Qemu-devel] [Bug 1378554] Re: qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit

Yes, qemu's working fine on aarch64 so this must have been fixed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1378554 Title: qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit

[Qemu-devel] [Bug 1378554] Re: qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit

Ah, my mail client found the thread that tells me this was fixed in commit 35e4e96c4d5bfcf. So we can close this. ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1596204] Re: UART problem in raspi2

This is because you're running a binary for the raspberry pi 1 on a model of the raspberry pi 2. The peripherals are at different locations on the two boards, and so your program doesn't work. You can fix that by changing all the register addresses that start 0x20. to 0x3f, or more

Re: [Qemu-devel] [PATCH] Remove MemoryRegionSection check code from sparc_cpu_get_phys_page_debug()

On 22/11/17 19:20, Jean-Christophe DUBOIS wrote: > The reported error seems to be unrelated to the patch. > > There seems to be an issue with the build infrastructure. > > Looking at "history" in the mailing list this kind of (unrelated) issue > seems to happen from time to time. > > JC Yes

[Qemu-devel] [PATCH 1/2] virtio: check VirtQueue Vring object is set

From: Prasad J Pandit An user could attempt to use an uninitialised VirtQueue object or unset Vring.align leading to a arithmetic exception. Add check to avoid it. Reported-by: Zhangboxian Signed-off-by: Prasad J Pandit

[Qemu-devel] [PATCH 0/2] check VirtiQueue Vring objects

From: Prasad J Pandit Hello, An user could attempt to use an uninitialised VirtQueue object or set Vring object with undue values, raising an unexpected exception in Qemu. This patch set fixes this issue and also adds a unit test to the suite. Thank you. -- Prasad J

[Qemu-devel] [PATCH 2/2] tests: add test to check VirtQueue object

From: Prasad J Pandit An uninitialised VirtQueue object or one with Vring.align field set to zero(0) could lead to arithmetic exceptions. Add a unit test to validate it. Signed-off-by: Prasad J Pandit --- tests/virtio-blk-test.c | 21

[Qemu-devel] [Bug 1378554] Re: qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit

Richard, is this 3 year old bug still an issue? ** Tags added: arm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1378554 Title: qemu segfault in virtio_scsi_handle_cmd_req_submit on ARM 32 bit

Re: [Qemu-devel] [PATCH v2] configure: Deal with OpenBSD/i386 emulation linker

On 20 November 2017 at 13:46, Peter Maydell wrote: > On 7 November 2017 at 23:46, Brad Smith wrote: >> OpenBSD/i386 uses elf_i386_obsd for the emulation linker. >> >> Signed-off-by: Brad Smith >> >> >> diff --git a/configure

[Qemu-devel] [Bug 1172613] Re: [qemu 1.4.1] inconsistent behavior on different architecture

In particular, the only crashes here are the ones where --library-path isn't specified, so it isn't even a case of "QEMU should somehow support whiteouts in --library-path so you can tell it to ignore the host ld.so.cache". So I'm going to close this bug report (with 'invalid' as the closest

[Qemu-devel] [Bug 1364501] Re: Gdb hangs when trying to single-step after an invalid instruction

** Tags added: arm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1364501 Title: Gdb hangs when trying to single-step after an invalid instruction Status in QEMU: New Bug description: When

[Qemu-devel] [Bug 1172613] Re: [qemu 1.4.1] inconsistent behavior on different architecture

This is going to be the same "glibc crashes if it sees a wrong- endianness /etc/ld.so.cache" situation also seen in lp:1701798. Personally I think it's a glibc bug, not really a QEMU bug. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

On 11/23/2017 06:44 PM, Auger Eric wrote: > Hi Cornelia, Peter, > > On 23/11/17 18:14, Cornelia Huck wrote: >> On Thu, 23 Nov 2017 17:01:32 + >> Peter Maydell wrote: >> >>> On 23 November 2017 at 16:05, Auger Eric wrote: When using

[Qemu-devel] [PATCH 0/1] block: Workaround for the iotests errors

Jeff's block job patch made the latent drain bug visible, and I find this patch, which by itself also makes some sense, can hide it again. :) With it applied we are at least back to the ground where patchew's iotests (make docker-test-block@fedora) can pass. The real bug is that in the middle of

[Qemu-devel] [PATCH 1/1] block: Don't poll for drain end

Only drained_begin cares about in flight requests are processed, there is no need to do BDRV_POLL_WHILE() if begin==false, because all that need to be done is recursively invoking children's callbacks. Signed-off-by: Fam Zheng --- block/io.c | 8 +--- 1 file changed, 5

Re: [Qemu-devel] [PATCH for-2.11?] osdep.h: Make TIME_MAX handle different time_t types

Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH for-2.11?] osdep.h: Make TIME_MAX handle different time_t types Type: series Message-id: 1511452598-6077-1-git-send-email-peter.mayd...@linaro.org === TEST SCRIPT BEGIN

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

Hi Cornelia, Peter, On 23/11/17 18:14, Cornelia Huck wrote: > On Thu, 23 Nov 2017 17:01:32 + > Peter Maydell wrote: > >> On 23 November 2017 at 16:05, Auger Eric wrote: >>> When using update-linux-headers.sh I get suspicious errors at the

Re: [Qemu-devel] [PATCH] block: Fix qemu crash when using scsi-block

Am 23.11.2017 um 18:31 hat Paolo Bonzini geschrieben: > On 23/11/2017 18:29, Kevin Wolf wrote: > >> Note that a similar issue exists in > >> blk_ioctl()/blk_ioctl_entry()/blk_prw() where blk_prw() always creates > >> the QEMUIOVector even if blk_ioctl()/blk_ioctl_entry() does not need a > >>

Re: [Qemu-devel] [PATCH] block: Fix qemu crash when using scsi-block

On 23/11/2017 18:29, Kevin Wolf wrote: >> Note that a similar issue exists in >> blk_ioctl()/blk_ioctl_entry()/blk_prw() where blk_prw() always creates >> the QEMUIOVector even if blk_ioctl()/blk_ioctl_entry() does not need a >> QEMUIOVector. This will need to be fixed separately to keep it >>

Re: [Qemu-devel] [PATCH] block: Fix qemu crash when using scsi-block

Am 23.11.2017 um 18:05 hat Deepa Srinivasan geschrieben: > blk_aio_prwv() now takes a void pointer and the coroutine functions > have been modified to cast it into QEMUIOVector if needed. It does not > use an union in BlkRwCo since this leads to code - blk_aio_prwv() > would have to write to the

Re: [Qemu-devel] [PATCH] block: Fix qemu crash when using scsi-block

On 23/11/2017 18:05, Deepa Srinivasan wrote: > blk_aio_prwv() now takes a void pointer and the coroutine functions > have been modified to cast it into QEMUIOVector if needed. It does > not use an union in BlkRwCo since this leads to code - blk_aio_prwv() > would have to write to the void pointer

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

On Thu, 23 Nov 2017 17:01:32 + Peter Maydell wrote: > On 23 November 2017 at 16:05, Auger Eric wrote: > > When using update-linux-headers.sh I get suspicious errors at the end: > > grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such

[Qemu-devel] [PATCH] pcc: define the Power-saving mode Exit Cause Enable bits in PowerPCCPUClass

and use the value to define precisely the default value of the LPCR in the helper routine cpu_ppc_set_papr() Signed-off-by: Cédric Le Goater --- target/ppc/cpu-qom.h| 1 + target/ppc/translate_init.c | 23 +++ 2 files changed, 12 insertions(+), 12

Re: [Qemu-devel] qemu x86 CPUID leafs override

Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] qemu x86 CPUID leafs override Type: series Message-id: 20171123131331.5jyqwlbgthijq...@pd.tnic === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git log --oneline

Re: [Qemu-devel] [PATCH] block: Fix qemu crash when using scsi-block

blk_aio_prwv() now takes a void pointer and the coroutine functions have been modified to cast it into QEMUIOVector if needed. It does not use an union in BlkRwCo since this leads to code - blk_aio_prwv() would have to write to the void pointer member, but coroutines would sometimes read the

Re: [Qemu-devel] [PATCH 2/2] qemu-options: Mention locking option of file driver

Am 23.11.2017 um 14:59 hat Fam Zheng geschrieben: > Signed-off-by: Fam Zheng > --- > qemu-options.hx | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/qemu-options.hx b/qemu-options.hx > index 3728e9b4dd..bcb7a88ec3 100644 > --- a/qemu-options.hx > +++

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

On 23 November 2017 at 16:05, Auger Eric wrote: > When using update-linux-headers.sh I get suspicious errors at the end: > grep: /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such file or > directory > sed: can't read /tmp/tmp.A5NjLtHOij/include/asm/kvm_virtio.h: No such

Re: [Qemu-devel] [PATCH 1/2] docs: Add image locking subsection

Am 23.11.2017 um 14:59 hat Fam Zheng geschrieben: > This documents the image locking feature and explains when and how > related options can be used. > > Signed-off-by: Fam Zheng > --- > docs/qemu-block-drivers.texi | 36 > qemu-doc.texi

Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids

On Thu, 23 Nov 2017 17:09:16 +0100 Halil Pasic wrote: [I need time to process your other remarks.] > On 11/22/2017 01:13 PM, Cornelia Huck wrote: > >> Also I can't find anything about vfio-ccw in the upstream users > >> manual for 2.10.91. > > > > We have an

[Qemu-devel] [PATCH] block: Fix qemu crash when using scsi-block

Starting qemu with the following arguments causes qemu to segfault: ... -device lsi,id=lsi0 -drive file=iscsi:<...>,format=raw,if=none,node-name= iscsi1 -device scsi-block,bus=lsi0.0,id=<...>,drive=iscsi1 This patch fixes blk_aio_ioctl() so it does not pass stack addresses to

Re: [Qemu-devel] [PATCH 1/2] docs: Add image locking subsection

Hello, Am 23.11.2017 um 14:59 schrieb Fam Zheng: > diff --git a/docs/qemu-block-drivers.texi b/docs/qemu-block-drivers.texi > index 1cb1e55686..fa2e90d15f 100644 > --- a/docs/qemu-block-drivers.texi > +++ b/docs/qemu-block-drivers.texi > @@ -785,6 +785,42 @@ warning: ssh server

[Qemu-devel] [PATCH v2 1/5] softfloat: add floatx80_mod()

copied from previous: Written by Andreas Grabher for Previous, NeXT Computer Emulator. Signed-off-by: Laurent Vivier --- fpu/softfloat.c | 88 + include/fpu/softfloat.h | 1 + 2 files changed, 89 insertions(+) diff

[Qemu-devel] [PATCH v2 3/5] softfloat: use floatx80_infinity in softfloat

Since f3218a8 ("softfloat: add floatx80 constants") floatx80_infinity is defined but never used. This patch updates floatx80 functions to use this definition. This allows to define a different default Infinity value on m68k: the m68k FPU defines infinity with all bits set to zero in the

[Qemu-devel] [PATCH v2 2/5] target/m68k: add fmod/frem

Use floatx80_mod() and floatx80_rem() The quotient byte of the FPSR is updated with the result of the operation. Signed-off-by: Laurent Vivier --- target/m68k/cpu.h| 1 + target/m68k/fpu_helper.c | 33 + target/m68k/helper.h | 2

[Qemu-devel] [PATCH v2 4/5] softfloat: add floatx80_getman(), floatx80_getexp(), floatx80_scale()

copied from previous: Written by Andreas Grabher for Previous, NeXT Computer Emulator. Signed-off-by: Laurent Vivier --- fpu/softfloat-specialize.h | 15 ++ fpu/softfloat.c| 132 + include/fpu/softfloat.h| 3

[Qemu-devel] [PATCH v2 5/5] target-m68k: add fscale, fgetman and fgetexp

using floatx80_scale(), floatx80_getman() and floatx80_getexp() Signed-off-by: Laurent Vivier --- target/m68k/fpu_helper.c | 15 +++ target/m68k/helper.h | 3 +++ target/m68k/translate.c | 9 + 3 files changed, 27 insertions(+) diff --git

[Qemu-devel] [PATCH v2 0/5] target/m68k: implement 680x0 FPU (part 3)

Implement fmod, frem, fscale, fgetman and fgetexp. Instead of using functions of libm (v1 of this series) and converting between host long double and floatx80 type the new version (v2) adds new floatx80 functions in softfloat. All the floatx80 functions are copied from "Previous", the NeXT

[Qemu-devel] QEMU Summit 2017: minutes

As usual, during this year's KVM Forum we also held the QEMU Summit, which is where the more active subsystem maintainers meet up for a discussion of various maintenance and other project issues. As usual, none of this is set-in-stone decisions; further input and discussion on-list is welcome.

Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion

On 23/11/2017 17:14, Dan Williams wrote: > On Wed, Nov 22, 2017 at 8:05 PM, Xiao Guangrong > wrote: >> >> >> On 11/22/2017 02:19 AM, Rik van Riel wrote: >> >>> We can go with the "best" interface for what >>> could be a relatively slow flush (fsync on a >>> file on

Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion

On Wed, Nov 22, 2017 at 8:05 PM, Xiao Guangrong wrote: > > > On 11/22/2017 02:19 AM, Rik van Riel wrote: > >> We can go with the "best" interface for what >> could be a relatively slow flush (fsync on a >> file on ssd/disk on the host), which requires >> that the

Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids

On 11/22/2017 01:13 PM, Cornelia Huck wrote: [..] >> The original question was about weather keep the start putting >> non-virtual devices into (the non-guest-visible) 0 if no devno is >> specified, or rather fill the default first and only then spill >> to the next css. > > Combined with what

Re: [Qemu-devel] [Qemu-ppc] [PATCH 01/12] e500: add board config options

On 11/22/2017 06:55 PM, Michael Davidsaver wrote: > On 11/21/2017 09:28 PM, David Gibson wrote: >> On Sun, Nov 19, 2017 at 09:24:09PM -0600, Michael Davidsaver wrote: >>> allow board code to skip common NIC and guest image setup >>> and configure decrementor frequency. >>> Existing boards

Re: [Qemu-devel] [PATCH 2/3] cpu: refactor cpu_address_space_init()

On 23/11/2017 10:23, Peter Xu wrote: > +const char *prefix, MemoryRegion *mr) > { > CPUAddressSpace *newas; > +AddressSpace *as = g_new0(AddressSpace, 1); > + > +assert(mr); > +address_space_init(as, mr, prefix); > Now that

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

Hi Peter, On 23/11/17 16:19, Peter Maydell wrote: > On 23 November 2017 at 14:56, Eric Auger wrote: >> At the moment the ITS is not properly reset. On System reset or >> reboot, previous ITS register values and caches are left >> unchanged. Some of the registers might

Re: [Qemu-devel] [PATCH for-2.11?] osdep.h: Make TIME_MAX handle different time_t types

On 23/11/2017 16:56, Peter Maydell wrote: > In our various supported host OSes, the time_t type may be either 32 > or 64 bit, and could in theory also be either signed or unsigned. > Notably, in OpenBSD time_t is a 64 bit type even if 'long' is 32 > bits, so using LONG_MAX for TIME_MAX is

[Qemu-devel] [PATCH for-2.11?] osdep.h: Make TIME_MAX handle different time_t types

In our various supported host OSes, the time_t type may be either 32 or 64 bit, and could in theory also be either signed or unsigned. Notably, in OpenBSD time_t is a 64 bit type even if 'long' is 32 bits, so using LONG_MAX for TIME_MAX is incorrect. Use an approach suggested by Paolo Bonzini

Re: [Qemu-devel] [BUG/RFC] INIT IPI lost when VM starts

2017-11-20 06:57+, Gonglei (Arei): > Hi Paolo, > > What's your opinion about this patch? We found it just before finishing > patches > for the past two days. I think your case was fixed by f4ef19108608 ("KVM: X86: Fix loss of pending INIT due to race"), but that patch didn't fix it

Re: [Qemu-devel] [Qemu-ppc] [PATCH 06/12] i2c: add mpc8540 i2c controller

Hello, The model should be QOM'ified. On 11/20/2017 04:24 AM, Michael Davidsaver wrote: > Signed-off-by: Michael Davidsaver > --- > hw/i2c/Makefile.objs | 1 + > hw/i2c/mpc8540_i2c.c | 287 > +++ > 2 files changed, 288

Re: [Qemu-devel] [PULL 0/2] Migration PULL take 2

On 22 November 2017 at 08:45, Juan Quintela wrote: > Hi > > This uses the right verslion of postcopy_running from from Daniel. > > Please, apply. > > Later, Juan. > > The following changes since commit a15d835f00dce270fd3194e83d9910f4b5b44ac0: > > Update version for

Re: [Qemu-devel] [PATCH] osdep: Deal with TIME_MAX and OpenBSD 64-bit time_t

On 6 November 2017 at 17:41, Paolo Bonzini wrote: > What about > > #define type_max(t) \ > ((t) -1 > 0 \ > ? (t)~0 \ > : (((t)1) << \ > (sizeof(t) * 8 - 1)) - 1)\ >

Re: [Qemu-devel] [RFC v3 0/4] vITS Reset

On 23 November 2017 at 14:56, Eric Auger wrote: > At the moment the ITS is not properly reset. On System reset or > reboot, previous ITS register values and caches are left > unchanged. Some of the registers might point to some guest RAM > tables which are not valid

Re: [Qemu-devel] QEMU 3.0 ?

On Thu, 23 Nov 2017 12:17:54 +0100 Paolo Bonzini wrote: > On 23/11/2017 11:57, Thomas Huth wrote: > > On 23.11.2017 11:17, Peter Maydell wrote: > >> On 23 November 2017 at 10:03, Cornelia Huck wrote: > >>> On Mon, 13 Nov 2017 08:14:28 +0100 > >>>

[Qemu-devel] [RFC v3 1/4] hw/intc/arm_gicv3_its: Don't call post_load on reset

>From the very beginning, post_load() was called from common reset. This is not standard and obliged to discriminate the reset case from the restore case using the iidr value. Let's get rid of that call. Signed-off-by: Eric Auger --- hw/intc/arm_gicv3_its_common.c | 2 --

[Qemu-devel] [RFC v3 3/4] linux-headers: Partial header update for ITS reset

This aims at importing the KVM_DEV_ARM_ITS_CTRL_RESET attribute which allows to trigger a reset of the in-kernel emulated ITS. This is now upstream but not tagged yet with v4.15-rc0 Signed-off-by: Eric Auger --- linux-headers/asm-arm/kvm.h | 1 +

[Qemu-devel] [RFC v3 2/4] hw/intc/arm_gicv3_its: Implement a minimalist reset

At the moment the ITS is not properly reset and this causes various bugs on save/restore. We implement a minimalist reset through individual register writes but for kernel versions before v4.15 this fails voiding the vITS cache. We cannot claim we have a comprehensive reset (hence the error

[Qemu-devel] [RFC v3 4/4] hw/intc/arm_gicv3_its: Implement full reset

Voiding the ITS caches is not supposed to happen via individual register writes. So we introduced a dedicated ITS KVM device ioctl to perform a cold reset of the ITS: KVM_DEV_ARM_VGIC_GRP_CTRL/KVM_DEV_ARM_ITS_CTRL_RESET. Let's use this latter if the kernel supports it. Signed-off-by: Eric Auger

[Qemu-devel] [RFC v3 0/4] vITS Reset

At the moment the ITS is not properly reset. On System reset or reboot, previous ITS register values and caches are left unchanged. Some of the registers might point to some guest RAM tables which are not valid anymore. This leads to state inconsistencies that are detected by the kernel

Re: [Qemu-devel] [PATCH v8 4/5] crash: export paddr_vmcoreinfo_note()

On Thu, Nov 23, 2017 at 03:02:05PM +0100, Marc-André Lureau wrote: > The following patch is going to use the symbol from the fw_cfg module, > to call the function and write the note location details in the > vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note. Sounds like fw_cfg

  1   2   3   >