Re: [Qemu-devel] spec, RFC: TLS support for NBD

On Sat, Oct 18, 2014 at 12:03:23AM +0200, Wouter Verhelst wrote: > Hi all, > > (added rjones from nbdkit fame -- hi there) [I'm happy to implement whatever you come up with, but I've added Florian Weimer to CC who is part of Red Hat's product security group] > So I think the following would make

[Qemu-devel] [PATCH] vfio: fix adding memory listener to the right address space

Depending on the device, container->space->as contains the valid AddressSpace. Using address_space_memory breaks devices sitting behind an iommu (and using a separate address space). Signed-off-by: Frank Blaschka --- hw/misc/vfio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --gi

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On 2014/10/17 16:43, zhanghailiang wrote: > On 2014/10/17 16:27, haifeng@huawei.com wrote: >> From: linhaifeng >> >> The VM start with share hugepage should close the hugefile fd >> when exit.Because the hugepage fd may be send to other process >> e.g vhost-user If qemu not close the fd the

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On 2014/10/17 21:26, Daniel P. Berrange wrote: > On Fri, Oct 17, 2014 at 04:57:27PM +0800, Linhaifeng wrote: >> >> >> On 2014/10/17 16:33, Daniel P. Berrange wrote: >>> On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng@huawei.com wrote: From: linhaifeng The VM start with share

Re: [Qemu-devel] [PATCH] hw/i386/pc_q35.c: Avoid g_assert_cmpint() as it is not in glib 2.12

> Subject: [Qemu-devel] [PATCH] hw/i386/pc_q35.c: Avoid g_assert_cmpint() as it > is not in glib 2.12 > > The function g_assert_cmpint() is not in glib 2.12, which is our current > minimum requirement. Rephrase the recently added assertion to avoid it. > > Signed-off-by: Peter Maydell > --- > h

Re: [Qemu-devel] memory hotplug with 2.1.2

Hi, Have you tried the latest qemu (you can git clone from http://git.qemu.org/qemu.git). Actually, i have posted a patch fc50ff0666315be5120c70ad00cd0b0097484b84 pc-dimm: Don't check dimm->node when there is non-NUMA config It should not break memory hotplug feature if there is non-NU

[Qemu-devel] spec, RFC: TLS support for NBD

Hi all, (added rjones from nbdkit fame -- hi there) So I think the following would make sense to allow TLS in NBD. This would extend the newstyle negotiation by adding two options (i.e., client requests), one server reply, and one server error as well as extend one existing reply, in the followi

Re: [Qemu-devel] [PATCH v6 11/32] target-arm: add CPREG secure state support

I fixed the issue by adding naming and a couple of macros for short-cutting the name. Interestingly and somewhat baffling, the only fields that needed the fix were the bank_fieldoffsets and fieldoffsets. It appears to be related to static initialization using these fields as all the CP15 anonymou

Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el

On Fri, Oct 17, 2014 at 08:57:38PM +0200, Torbjörn Granlund wrote: > Aurelien Jarno writes: > > I am using 2.1.2 under GNU/Linux. > > Ah, so you're not trying to reproduce the problem! I do. Well you talked about 2.1.0, the latest stable one is 2.1.2. Now if you prefer, we can conclude th

Re: [Qemu-devel] [PATCH v6 00/24] Split BlockBackend off BDS with an axe

Am 07.10.2014 um 13:59 hat Markus Armbruster geschrieben: > My last attempt got bogged down because I tried to do a reasonably > complete job, and the complexity proved more than I could handle with > the limited amount of uninterrupted time available. This time, I'm > cutting BlockBackend off wit

Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el

Aurelien Jarno writes: I am using 2.1.2 under GNU/Linux. Ah, so you're not trying to reproduce the problem! Are you passing the -cpu 5Kc argument? I don't think it's irrelevant, that's why I asked. If you don't provide this information, we won't be able to check which code paths are

[Qemu-devel] [PATCH] hw/i386/pc_q35.c: Avoid g_assert_cmpint() as it is not in glib 2.12

The function g_assert_cmpint() is not in glib 2.12, which is our current minimum requirement. Rephrase the recently added assertion to avoid it. Signed-off-by: Peter Maydell --- hw/i386/pc_q35.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35

Re: [Qemu-devel] [PATCH v4 1/1] xen-hvm.c: Add support for Xen access to vmport

On 10/17/14 13:41, Stefano Stabellini wrote: On Fri, 17 Oct 2014, Don Slutz wrote: This adds synchronisation of the 6 vcpu registers (only 32bits of them) that vmport.c needs between Xen and QEMU. This is to avoid a 2nd and 3rd exchange between QEMU and Xen to fetch and put these 6 vcpu registe

Re: [Qemu-devel] [PATCH v6 16/24] hw: Convert from BlockDriverState to BlockBackend, mostly

Am 07.10.2014 um 13:59 hat Markus Armbruster geschrieben: > Device models should access their block backends only through the > block-backend.h API. Convert them, and drop direct includes of > inappropriate headers. > > Just four uses of BlockDriverState are left: > > * The Xen paravirtual block

Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el

On Fri, Oct 17, 2014 at 03:53:35PM +0200, Torbjörn Granlund wrote: > Aurelien Jarno writes: > > I have installation running in qemu-system-mips with weeks of uptime > without any problem. I have however tried the above with QEMU 2.1, and > I have been unable to reproduce the issue. > > I

Re: [Qemu-devel] [PULL 13/23] q35/ahci: Pick up -cdrom and -hda options

On 17 October 2014 19:02, Peter Maydell wrote: > On 17 October 2014 18:57, Michael Tokarev wrote: >> On 10/17/2014 08:53 PM, Peter Maydell wrote: >>> g_assert_cmpint() was only added in glib 2.16, so this won't >>> build on glib 2.12. A compat fudge in glib-compat.h should >>> be easy, though. >>

Re: [Qemu-devel] [PATCH v4 1/1] xen-hvm.c: Add support for Xen access to vmport

On Fri, 17 Oct 2014, Don Slutz wrote: > This adds synchronisation of the 6 vcpu registers (only 32bits of > them) that vmport.c needs between Xen and QEMU. > > This is to avoid a 2nd and 3rd exchange between QEMU and Xen to > fetch and put these 6 vcpu registers used by the code in vmport.c > and

Re: [Qemu-devel] [PATCH] glib: add compatibility interface for g_strcmp0()

On 16 October 2014 12:59, wrote: > From: Gonglei > > This patch fixes compilation errors when building against glib < 2.16.0 > due to the missing g_strcmp0() function. > > Suggested-by: Peter Maydell > Signed-off-by: Gonglei > --- > Because g_strcmp0() was called in three places, I provide >

Re: [Qemu-devel] memory hotplug with 2.1.2

Hi Andrey, thank you for your answer. I know I can work around this by specifying a numa node. My question is though is the current behaviour considered to be a bug, or not. And if yes, when it is expected to get fixed. Thanks, Mikhail On Fri, Oct 17, 2014 at 5:54 PM, Andrey Korolyov wrote: >

Re: [Qemu-devel] [PULL 31/32] spapr_pci: Use XICS interrupt allocator and do not cache interrupts in PHB

On 27 June 2014 13:52, Alexander Graf wrote: > From: Alexey Kardashevskiy > > Currently SPAPR PHB keeps track of all allocated MSI (here and below > MSI stands for both MSI and MSIX) interrupt because > XICS used to be unable to reuse interrupts. This is a problem for > dynamic MSI reconfiguratio

Re: [Qemu-devel] [PULL 13/23] q35/ahci: Pick up -cdrom and -hda options

On 17 October 2014 18:57, Michael Tokarev wrote: > On 10/17/2014 08:53 PM, Peter Maydell wrote: >> g_assert_cmpint() was only added in glib 2.16, so this won't >> build on glib 2.12. A compat fudge in glib-compat.h should >> be easy, though. > > Or just change this to regular in-line comparison an

Re: [Qemu-devel] [PULL 13/23] q35/ahci: Pick up -cdrom and -hda options

On 10/17/2014 08:53 PM, Peter Maydell wrote: > On 4 October 2014 22:24, Stefan Hajnoczi wrote: >> From: John Snow >> >> This patch implements the backend for the Q35 board >> for us to be able to pick up and use drives defined >> by the -cdrom, -hda, or -drive if=ide shorthand options. >> >> Sign

Re: [Qemu-devel] [PULL 13/23] q35/ahci: Pick up -cdrom and -hda options

On 4 October 2014 22:24, Stefan Hajnoczi wrote: > From: John Snow > > This patch implements the backend for the Q35 board > for us to be able to pick up and use drives defined > by the -cdrom, -hda, or -drive if=ide shorthand options. > > Signed-off-by: John Snow > Reviewed-by: Markus Armbruster

[Qemu-devel] [PATCH qom v4 12/13] qdev: gpio: Define qdev_pass_gpios()

From: Peter Crosthwaite Allows a container to take ownership of GPIOs in a contained device and automatically connect them as GPIOs to the container. This prepares for deprecation of the SYSBUS IRQ functionality, which has this feature. We push it up to the device level instead of sysbus level.

[Qemu-devel] [PATCH qom v4 13/13] sysbus: Use TYPE_DEVICE GPIO functionality

From: Peter Crosthwaite Re-implement the Sysbus GPIOs to use the existing TYPE_DEVICE GPIO named framework. A constant string name is chosen to avoid conflicts with existing unnamed GPIOs. This unifies GPIOs are IRQs for sysbus devices and allows removal of all Sysbus state for GPIOs. Any exist

[Qemu-devel] [PATCH qom v4 11/13] qdev: gpio: Remove qdev_init_gpio_out x1 restriction

From: Peter Crosthwaite Previously this was restricted to a single call per-dev/per-name. With the conversion of the GPIO output state to QOM the implementation can now handle repeated calls. Remove the restriction. Reviewed-by: Alexander Graf Signed-off-by: Peter Crosthwaite Signed-off-by: Pa

[Qemu-devel] [PATCH qom v4 10/13] qdev: gpio: delete NamedGPIOList::out

From: Peter Crosthwaite All users of GPIO outputs are fully QOMified, using QOM properties to access the GPIO data. Delete. Reviewed-by: Alexander Graf Signed-off-by: Peter Crosthwaite Signed-off-by: Paolo Bonzini --- hw/core/qdev.c | 1 - include/hw/qdev-core.h | 1 - 2 files change

[Qemu-devel] [PATCH qom v4 09/13] irq: Remove qemu_irq_intercept_out

From: Peter Crosthwaite No more users left and obsoleted by qdev_intercept_gpio_out. Reviewed-by: Alexander Graf Signed-off-by: Peter Crosthwaite Signed-off-by: Paolo Bonzini --- hw/core/irq.c| 6 -- include/hw/irq.h | 1 - 2 files changed, 7 deletions(-) diff --git a/hw/core/irq.c

[Qemu-devel] [PATCH qom v4 06/13] qdev: gpio: Re-implement qdev_connect_gpio QOM style

From: Peter Crosthwaite Re-implement as a link setter. This should allow the QOM framework to keep track of ref counts properly etc. We need to add a default parent for the connecting input incase it's coming from a non-qdev source. We simply parent the IRQ to the machine in this case. Reviewed

[Qemu-devel] [PATCH qom v4 07/13] qdev: gpio: Add API for intercepting a GPIO

From: Peter Crosthwaite To replace the old qemu_irq intercept API (which had users reaching into qdev private state for GPIOs). Reviewed-by: Alexander Graf Signed-off-by: Peter Crosthwaite Signed-off-by: Paolo Bonzini --- hw/core/qdev.c | 25 + include/hw/qdev

[Qemu-devel] [PATCH qom v4 08/13] qtest/irq: Rework IRQ interception

From: Peter Crosthwaite Change the qtest intercept handler to accept just the individual IRQ being intercepted as opaque. n is still expected to be correctly set as for the original intercepted irq. qemu_intercept_irq_in is updated accordingly. Then covert the qemu_irq_intercept_out call to use

[Qemu-devel] [PATCH qom v4 00/13] GPIO/IRQ QOMification: Phase 2 - Getting rid of SYSBUS IRQs

These are the QOM IRQ patches from Peter Crosthwaite. I and Alex made the small changes I requested, so here they are. We tested them with v3 of the platform bus series. "-device eTSEC" works as expected and qom-test's property retrieval loop works fine with an eTSEC platform device added to the

[Qemu-devel] [PATCH qom v4 03/13] qdev: gpio: Register GPIO outputs as QOM links

From: Peter Crosthwaite Within the object that contains the GPIO output. This allows for connecting GPIO outputs via setting of a Link property. Also clear the link value to zero. This catch-alls the case where a device improperly inits a gpio_out (malloc instead of malloc0). Reviewed-by: Alexa

[Qemu-devel] [PATCH qom v4 05/13] qom: Demote already-has-a-parent to a regular error

From: Peter Crosthwaite Rather than an abort(). This allows callers to decide whether parenting an already-parented object is a fatal error condition. Useful for providing a default value for an object's parent in the case where you want to set one iff it doesn't already have one. Reviewed-by:

[Qemu-devel] [PATCH qom v4 04/13] qom: Allow clearing of a Link property

From: Peter Crosthwaite By passing in "" to object_property_set_link. The lead user of this is the QDEV GPIO framework which will implement GPIO disconnects via an "unlink". GPIO disconnection is used by qtest's irq_intercept_out command. Reviewed-by: Alexander Graf Signed-off-by: Peter Crost

[Qemu-devel] [PATCH qom v4 01/13] qdev: gpio: Don't allow name share between I and O

From: Peter Crosthwaite Only allow a GPIO name to be one or the other. Inputs and outputs are functionally different and should be in different namespaces. Prepares support for the QOMification of IRQs as Links or Child objects. The alternative is to munge names .e.g. with "-in" or "-out" suffix

[Qemu-devel] [PATCH qom v4 02/13] qdev: gpio: Register GPIO inputs as child objects

From: Peter Crosthwaite To the device that contains them. This will allow for referencing a GPIO input from it's canonical path (exciting for dynamic machine generation!) Reviewed-by: Alexander Graf Signed-off-by: Peter Crosthwaite Signed-off-by: Paolo Bonzini --- hw/core/qdev.c | 9

Re: [Qemu-devel] [PATCH v6 11/32] target-arm: add CPREG secure state support

Good to know. Thanks Laurent. On Oct 17, 2014 10:27 AM, "Laurent Desnogues" wrote: > On Fri, Oct 17, 2014 at 5:20 PM, Greg Bellows > wrote: > > So, I believe I reproduced the issue with gcc-4.4. 4.6 and 4.7 appear to > > work fine. I tried adding the "-fms-extensions" flag through configure's

Re: [Qemu-devel] memory hotplug with 2.1.2

Ah, just noticed there is a bug related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1150930 Mikhail On 17.10.2014 17:38, Mikhail Sennikovskii wrote: Hi all, Trying to hotplug RAM with qemu 2.1.2 using object_add memory-backend-ram,id=ram1,size=128M device_add pc-dimm,id=dimm1,memde

[Qemu-devel] [PATCH v6] Support vhd type VHD_DIFFERENCING

Now qemu only supports vhd type VHD_FIXED and VHD_DYNAMIC, so qemu can't read snapshot volume of vhd, and can't support other storage features of vhd file. This patch add read parent information in function "vpc_open", read bitmap in "vpc_read", and change bitmap in "vpc_write". Signed-off-by: Xi

[Qemu-devel] memory hotplug with 2.1.2

Hi all, Trying to hotplug RAM with qemu 2.1.2 using object_add memory-backend-ram,id=ram1,size=128M device_add pc-dimm,id=dimm1,memdev=ram1 gives the following error: {{{ 'DIMM property node has value 0' which exceeds the number of numa nodes: 0 Device 'pc-dimm' could not be initialized }}} wh

Re: [Qemu-devel] [PATCH v6 11/32] target-arm: add CPREG secure state support

On Fri, Oct 17, 2014 at 5:20 PM, Greg Bellows wrote: > So, I believe I reproduced the issue with gcc-4.4. 4.6 and 4.7 appear to > work fine. I tried adding the "-fms-extensions" flag through configure's > "--extra-cflags" but it dow not appear to work. Not sure if this is a > configure/make iss

Re: [Qemu-devel] [PATCH v6 11/32] target-arm: add CPREG secure state support

So, I believe I reproduced the issue with gcc-4.4. 4.6 and 4.7 appear to work fine. I tried adding the "-fms-extensions" flag through configure's "--extra-cflags" but it dow not appear to work. Not sure if this is a configure/make issue or if anonymous unions/structs are still disallowed. I'll

[Qemu-devel] writing a QEMU block driver

Hi there, Do let me know if I am asking these questions on the wrong forum. I'd like to write a QEMU block driver which forwards IO requests to a custom-built storage cluster. I have seen Jeff Cody's presentation and also browsed the source code for sheepdog, nbd and g

[Qemu-devel] qemu opengl status

Hi, I would like to run OpenGL application in a pentium3 guest (host x86_64). I would like to know if it is possible. can you give me directions ? I understand that altough I have smp host processors, only one cpu will emulate this kind of guest ? Regards, Steph

Re: [Qemu-devel] [PATCH v2] virtio-pci: fix migration for pci bus master

On Wed, Oct 15, 2014 at 05:34:25PM +0200, Greg Kurz wrote: > On Tue, 14 Oct 2014 19:55:23 +0300 > "Michael S. Tsirkin" wrote: > > Current support for bus master (clearing OK bit) together with the need to > > support guests which do not enable PCI bus mastering, leads to extra state > > in > > VI

Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el

Aurelien Jarno writes: I have installation running in qemu-system-mips with weeks of uptime without any problem. I have however tried the above with QEMU 2.1, and I have been unable to reproduce the issue. I have never had these problems with qemu-system-mips. They only happen with a 64-

Re: [Qemu-devel] [PATCH v4 1/1] xen-hvm.c: Add support for Xen access to vmport

> -Original Message- > From: qemu-devel-bounces+paul.durrant=citrix@nongnu.org > [mailto:qemu-devel-bounces+paul.durrant=citrix@nongnu.org] On > Behalf Of Paul Durrant > Sent: 17 October 2014 14:36 > To: Don Slutz; qemu-devel@nongnu.org > Cc: xen-de...@lists.xensource.com; Marcel Ap

Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections

Il 15/10/2014 17:59, Juan Quintela ha scritto: > My idea here is that, if you don't use libvirt, you just start without > -S. If you don't use libvirt or any other QEMU management layer, you're not going to do migration except for debugging purposes. There's just too much state going on to be abl

Re: [Qemu-devel] [PATCH v6 11/32] target-arm: add CPREG secure state support

Hmmm, I had not encountered this as I am using a new compiler which is presumeably using -std=c11. Here is what I am using: > gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 A quick search on gcc 4.4 shows that a different flag may be needed (-fms-extensions). There is also a special fl

Re: [Qemu-devel] [PATCH v4 1/1] xen-hvm.c: Add support for Xen access to vmport

> -Original Message- > From: Don Slutz [mailto:dsl...@verizon.com] > Sent: 17 October 2014 14:31 > To: Paul Durrant; Don Slutz; qemu-devel@nongnu.org > Cc: xen-de...@lists.xensource.com; Alexander Graf; Andreas Färber; > Anthony Liguori; Marcel Apfelbaum; Markus Armbruster; Michael S. Tsirk

Re: [Qemu-devel] [PATCH v4 1/1] xen-hvm.c: Add support for Xen access to vmport

On 10/17/14 08:34, Paul Durrant wrote: -Original Message- From: Don Slutz [mailto:dsl...@verizon.com] Sent: 17 October 2014 13:14 To: qemu-devel@nongnu.org; Paul Durrant Cc: xen-de...@lists.xensource.com; Alexander Graf; Andreas Färber; Anthony Liguori; Don Slutz; Marcel Apfelbaum; Markus

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On Fri, Oct 17, 2014 at 04:57:27PM +0800, Linhaifeng wrote: > > > On 2014/10/17 16:33, Daniel P. Berrange wrote: > > On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng@huawei.com wrote: > >> From: linhaifeng > >> > >> The VM start with share hugepage should close the hugefile fd > >> when exi

Re: [Qemu-devel] The status about vhost-net on kvm-arm?

Thanks for your feedback, >static irqreturn_t vm_interrupt(int irq, void *opaque) { > .. > > /* Read and acknowledge interrupts */ > /*status = readl(vm_dev->base + VIRTIO_MMIO_INTERRUPT_STATUS); > writel(status, vm_dev->base + VIRTIO_MMIO_INTERRUPT_ACK); > > if

Re: [Qemu-devel] [PATCH v4 1/1] xen-hvm.c: Add support for Xen access to vmport

> -Original Message- > From: Don Slutz [mailto:dsl...@verizon.com] > Sent: 17 October 2014 13:14 > To: qemu-devel@nongnu.org; Paul Durrant > Cc: xen-de...@lists.xensource.com; Alexander Graf; Andreas Färber; > Anthony Liguori; Don Slutz; Marcel Apfelbaum; Markus Armbruster; Michael > S. Tsi

Re: [Qemu-devel] The status about vhost-net on kvm-arm?

On 2014/10/15 22:39, GAUGUEY Rémy 228890 wrote: > Hello, > > Using this Qemu patchset as well as recent irqfd work, I’ve tried to make > vhost-net working on Cortex-A15. > Unfortunately, even if I can correctly generate irqs to the guest through > irqfd, it seems to me that some pieces are sti

[Qemu-devel] [PATCH v4 1/1] xen-hvm.c: Add support for Xen access to vmport

This adds synchronisation of the 6 vcpu registers (only 32bits of them) that vmport.c needs between Xen and QEMU. This is to avoid a 2nd and 3rd exchange between QEMU and Xen to fetch and put these 6 vcpu registers used by the code in vmport.c and vmmouse.c The registers are passed in the new sha

[Qemu-devel] [PATCH v4 0/1] Add support for Xen access to vmport

Changes RFC-v2x to v4: Stefano Stabellini Please try to get rid of the #ifdefs. Moved 2 #ifdefs into hw/xen/xen_common.h Changes v2 to RFC-v2x: Paul Durrant Use a 2nd shared page. Added HVM_PARAM_VMPORT_IOREQ_PFN usage. Changes v1 to v2: More info in commit message.

Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram with memory_region_allocate_system_memory

Il 14/10/2014 14:48, Peter Maydell ha scritto: > Why don't we just do that automatically for all RAM regions > the machine creates? We're already splitting up a contiguous > chunk of RAM to parcel out to RAM regions, that's what the > indirection through ramaddrs is all about. I can think of one r

Re: [Qemu-devel] Counting barrier instructions in ARM

Pranith Kumar writes: > Hi Peter, > > On Thu, Oct 16, 2014 at 4:05 AM, Peter Maydell > wrote: >> On 16 October 2014 03:45, Pranith Kumar wrote: >>> The problem I am facing is that this seems to be crashing when run with a >>> multi-threaded executable. >> >> This is nothing to do with your ch

[Qemu-devel] [Bug 1382477] [NEW] hw/i386/intel_iommu.c:902: wrong logical operator ?

Public bug reported: /home/dcb/qemu/trunk/qemu/hw/i386/intel_iommu.c:902:5: error: logical ‘and’ applied to non-boolean constant [-Werror=logical-op] pvtd_as = s->address_spaces[VTD_SID_TO_BUS(source_id)]; ^ $ fgrep VTD_SID_TO_BUS `find . -name \*.h -print` ./include/hw/i386/intel_iomm

Re: [Qemu-devel] [PATCH 3/6] target-mips: CP0_Status.CU0 no longer allows the user to access CP0

Reviewed-by: Yongbok Kim Regards, Yongbok On 14/07/2014 17:19, Leon Alrae wrote: Signed-off-by: Leon Alrae --- target-mips/cpu.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/target-mips/cpu.h b/target-mips/cpu.h index a35ab9d..b981ec7 100644 --- a/target-mips/

[Qemu-devel] [PATCH v4 3/3] monitor: delete device_del_bus_completion

device_del_bus_completion() that gathers devices from buses is unused; delete it. Signed-off-by: Zhu Guihua --- monitor.c | 20 1 file changed, 20 deletions(-) diff --git a/monitor.c b/monitor.c index 9c3fa01..42affb7 100644 --- a/monitor.c +++ b/monitor.c @@ -4340,25 +4340

[Qemu-devel] [PATCH v4 0/3] monitor: add peripheral device del completion support

After inputting device_del command in monitor, we expect to list all hotpluggable devices automatically by pressing tab key. This patchset provides the function to list all peripheral devices such as memory devices. v4: - delete unused device_del_bus_completion (Igor) - modify the way to get value

[Qemu-devel] [PATCH v4 1/3] qdev: add qdev_build_hotpluggable_device_list helper

For peripheral device del completion, add a function to build a list for hotpluggable devices. Signed-off-by: Zhu Guihua --- hw/core/qdev.c | 13 + include/hw/qdev-core.h | 2 ++ 2 files changed, 15 insertions(+) diff --git a/hw/core/qdev.c b/hw/core/qdev.c index a1e9247..9

[Qemu-devel] [PATCH v4 2/3] monitor: add del completion for peripheral device

Add peripheral_device_del_completion() to let peripheral device del completion be possible. Signed-off-by: Zhu Guihua --- monitor.c | 24 1 file changed, 24 insertions(+) diff --git a/monitor.c b/monitor.c index 2d14f39..9c3fa01 100644 --- a/monitor.c +++ b/monitor.c @@

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On 2014/10/17 16:57, Linhaifeng wrote: > > > On 2014/10/17 16:33, Daniel P. Berrange wrote: >> On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng@huawei.com wrote: >>> From: linhaifeng >>> >>> The VM start with share hugepage should close the hugefile fd >>> when exit.Because the hugepage f

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On 2014/10/17 16:56, Gonglei wrote: > On 2014/10/17 16:33, Daniel P. Berrange wrote: > >> On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng@huawei.com wrote: >>> From: linhaifeng >>> >>> The VM start with share hugepage should close the hugefile fd >>> when exit.Because the hugepage fd may

Re: [Qemu-devel] [PATCH v6] numa: make 'info numa' take into account hotplugged memory

On 2014/10/17 16:50, zhanghailiang wrote: > When do memory hotplug, if there is numa node, we should add > the memory size to the corresponding node memory size. > > For now, it mainly affects the result of hmp command "info numa". > > Reviewed-by: Igor Mammedov > Signed-off-by: zhanghailiang

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On 2014/10/17 16:33, Daniel P. Berrange wrote: > On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng@huawei.com wrote: >> From: linhaifeng >> >> The VM start with share hugepage should close the hugefile fd >> when exit.Because the hugepage fd may be send to other process >> e.g vhost-user If q

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On 2014/10/17 16:33, Daniel P. Berrange wrote: > On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng@huawei.com wrote: >> From: linhaifeng >> >> The VM start with share hugepage should close the hugefile fd >> when exit.Because the hugepage fd may be send to other process >> e.g vhost-user If

[Qemu-devel] [PATCH v6] numa: make 'info numa' take into account hotplugged memory

When do memory hotplug, if there is numa node, we should add the memory size to the corresponding node memory size. For now, it mainly affects the result of hmp command "info numa". Reviewed-by: Igor Mammedov Signed-off-by: zhanghailiang --- v6: - remove unnecessary 'di' variable (GongLei) v5

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On 2014/10/17 16:27, haifeng@huawei.com wrote: From: linhaifeng The VM start with share hugepage should close the hugefile fd when exit.Because the hugepage fd may be send to other process e.g vhost-user If qemu not close the fd the other process can not free the hugepage otherwise exit pro

Re: [Qemu-devel] [PATCH] fix the memory leak for share hugepage

On Fri, Oct 17, 2014 at 04:27:17PM +0800, haifeng@huawei.com wrote: > From: linhaifeng > > The VM start with share hugepage should close the hugefile fd > when exit.Because the hugepage fd may be send to other process > e.g vhost-user If qemu not close the fd the other process can > not free

[Qemu-devel] [PATCH] fix the memory leak for share hugepage

From: linhaifeng The VM start with share hugepage should close the hugefile fd when exit.Because the hugepage fd may be send to other process e.g vhost-user If qemu not close the fd the other process can not free the hugepage otherwise exit process,this is ugly,so qemu should close all shared fd

Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el

On Sun, Aug 03, 2014 at 02:11:30AM +0200, Torbjörn Granlund wrote: > I forgot to mention one of the popular crashes: > > Assertion failed: (len <= 64), function tcg_gen_deposit_i64, file > /var/tmp/pkg/usr/ports/emulators/qemu-devel/work/qemu-2.0.0/tcg/tcg-op.h, > line 2206. > > (This correspon

Re: [Qemu-devel] Crashes of qemu-system-mips64 and qemu-system-mips64el

On Sat, Aug 02, 2014 at 10:49:22PM +0200, Torbjörn Granlund wrote: > Qemu versions 1.7.0, 1.7.1, 2.0.0, 2.1.0 do not run Debian mips64 BE or > LE stably. While install in 32-bit mode typically works, running the > 64-bit kernel causes qemu to segfault or abort after a while. > > How to reproduce: