Re: [Qemu-devel] [RFC PATCH v0] numa: API to lookup NUMA node by address

On Wed, 10 Jun 2015 18:20:53 +0530 Bharata B Rao wrote: > On Wed, Jun 10, 2015 at 11:43:19AM +0200, Igor Mammedov wrote: > > On Tue, 9 Jun 2015 09:40:54 -0300 > > Eduardo Habkost wrote: > > > > > On Tue, Jun 09, 2015 at 11:23:19AM +0200, Igor Mammedov wrote: > > > > On Mon, 8 Jun 2015 12:51:39

Re: [Qemu-devel] [PULL v2 1/3] hw/vfio/platform: vfio-platform skeleton

Gonglei, Thanks for the report and please apologize for the inconvenience. I am going to send a fix reverting to simple g_malloc0 then. Best Regards Eric On 06/11/2015 04:21 AM, Gonglei wrote: > On 2015/6/9 23:55, Alex Williamson wrote: >> +static int vfio_populate_device(VFIODevice *vbasedev)

Re: [Qemu-devel] [PATCH v2 1/3] cpu: Provide vcpu throttling interface

"Jason J. Herne" writes: > On 06/10/2015 04:45 AM, Dr. David Alan Gilbert wrote: >> * Jason J. Herne (jjhe...@linux.vnet.ibm.com) wrote: >>> On 06/09/2015 04:06 AM, Dr. David Alan Gilbert wrote: * Jason J. Herne (jjhe...@linux.vnet.ibm.com) wrote: > On 06/03/2015 02:11 PM, Jason J. Herne

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

On 06/11/2015 01:49 PM, Thibaut Collet wrote: > > Yes, but still need a mechanism to notify the backend of migration > > completion from qemu side if GUEST_ANNOUNCE is not negotiated. > > backend is aware of a connection with the guest (with the feature > negociation) and can send a rarp. This ra

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

> Yes, but still need a mechanism to notify the backend of migration > completion from qemu side if GUEST_ANNOUNCE is not negotiated. backend is aware of a connection with the guest (with the feature negociation) and can send a rarp. This rarp will be always sent by the backend when a VM is launch

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

On 06/11/2015 04:25 AM, Thibaut Collet wrote: > Yes backend can save everything to be able to send the rarp alone > after a live migration. Yes, but still need a mechanism to notify the backend of migration completion from qemu side if GUEST_ANNOUNCE is not negotiated. > Main purpose of this pa

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

The warning message is not really necessary is just a reminder. On Wed, Jun 10, 2015 at 10:50 PM, Michael S. Tsirkin wrote: > On Wed, Jun 10, 2015 at 10:25:57PM +0200, Thibaut Collet wrote: > > Yes backend can save everything to be able to send the rarp alone after > a live > > migration. > > Ma

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/11/2015 12:29 AM, Laszlo Ersek wrote: On 06/10/15 22:11, Laszlo Ersek wrote: On 06/10/15 21:34, Laszlo Ersek wrote: On 06/10/15 21:26, Marcel Apfelbaum wrote: BTW, did you try to boot from it :) ? No, not yet; I'll have to write additional OVMF code for that; but the syntax is OK, an

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/10/2015 10:34 PM, Laszlo Ersek wrote: On 06/10/15 21:26, Marcel Apfelbaum wrote: On 06/10/2015 08:07 PM, Laszlo Ersek wrote: The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot off devices behind the PXB. This happens because the sysbus_get_fw_dev_path() function in "h

Re: [Qemu-devel] [PATCH 2/3] virtio-blk: Use blk_drain() to drain IO requests

On Wed, 06/10 14:38, Alexander Yarygin wrote: > Each call of the virtio_blk_reset() function calls blk_drain_all(), > which works for all existing BlockDriverStates, while draining only > one is needed. > > This patch replaces blk_drain_all() by blk_drain() in virtio_blk_reset(). Please add a not

Re: [Qemu-devel] [PULL v2 1/3] hw/vfio/platform: vfio-platform skeleton

On 2015/6/9 23:55, Alex Williamson wrote: > +static int vfio_populate_device(VFIODevice *vbasedev) > +{ > +int i, ret = -1; > +VFIOPlatformDevice *vdev = > +container_of(vbasedev, VFIOPlatformDevice, vbasedev); > + > +if (!(vbasedev->flags & VFIO_DEVICE_FLAGS_PLATFORM)) { > +

Re: [Qemu-devel] [PATCH v1 0/4] Add feature to start QEMU without vhost-user backend

On 2015/05/29 13:42, Tetsuya Mukawa wrote: > Hi guys, > > Here are patches to add feature to start QEMU without vhost-user backend. > Currently, if we want to use vhost-user backend, the backend must start before > QEMU. Also, if QEMU or the backend is closed unexpectedly, there is no way to > reco

[Qemu-devel] [PATCH v4 4/4] qmp/hmp: add rocker device support

From: Scott Feldman Add QMP/HMP support for rocker devices. This is mostly for debugging purposes to see inside the device's tables and port configurations. Some examples: (qemu) info rocker sw1 name: sw1 id: 0x013512005452 ports: 4 (qemu) info rocker-ports sw1 ena/speed/

[Qemu-devel] [PATCH v4 3/4] rocker: bring link up/down on PHY enable/disable

From: Scott Feldman When the OS driver enables/disables the port, go ahead and set the port's link status to up/down in response to the change. This more closely emulates real hardware when the PHY for the port is brought up/down and the PHY negotiates carrier (link status) with link partner. I

[Qemu-devel] [PATCH v4 2/4] rocker: update tests using hw-derived interface names

From: Scott Feldman With previous patch to support phy name attribute for each port, the OS can name port interfaces using the hw-derived name. So update rocker tests to use the new hw-derived interface names. Signed-off-by: Scott Feldman Reviewed-by: Stefan Hajnoczi --- tests/rocker/bridge

[Qemu-devel] [PATCH v4 0/4] rocker device updates

From: Scott Feldman v4: Address review comments from Stefan Hajnoczi: - hmp.c: change flow->hits printing to PRIu64 since it's uint64_t Address review comments from Eric Blake: - qapi/rocker.txt: fix comments to match commands - qmp-commands.hx: wrap some long comment lines v3: Address r

[Qemu-devel] [PATCH v4 1/4] rocker: Add support for phys name

From: David Ahern Add ROCKER_TLV_CMD_PORT_SETTINGS_PHYS_NAME to port settings. This attribute exports the port name to the guest OS allowing it to name interfaces with sensible defaults. Mostly done by Scott for phys_id support; adapted to phys_name by David. Signed-off-by: Scott Feldman Signe

[Qemu-devel] [PATCH v3 3/6] hw/pci-bridge: create interrupt-less, hotplug-less bridge for PXB

OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI Bus driver globally signals the firmware that PCI enumeration and resource allocation have completed. At this point QEMU regenerates the ACPI payload in an fw_cfg read callback, and this is when the PXB's _CRS gets populated.

[Qemu-devel] [PATCH v3 4/6] hw/core: rebase sysbus_get_fw_dev_path() to g_strdup_printf()

Cc: Markus Armbruster Cc: Marcel Apfelbaum Cc: Michael S. Tsirkin Signed-off-by: Laszlo Ersek --- Notes: v3: - new in v3 hw/core/sysbus.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c index b53c351..0ebb4e2 1

[Qemu-devel] [PATCH v3 6/6] hw/pci-bridge: set explicit OFW unit address for TYPE_PXB_HOST

The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot off devices behind the PXB. This happens because the sysbus_get_fw_dev_path() function in "hw/core/sysbus.c" doesn't have enough information to format a unique identifier for the PXB in question, and consequently the OpenFirmwa

[Qemu-devel] [PATCH v3 1/6] i386/acpi-build: more traditional _UID and _HID for PXB root buses

The ACPI specification permits the _HID and _UID objects to evaluate to strings. (See "6.1.5 _HID (Hardware ID)" and "6.1.12 _UID (Unique ID)" in the ACPI v6.0 spec.) With regard to related standards, the UEFI specification can also express a device address composed from string _HID and _UID ident

[Qemu-devel] [PATCH v3 0/6] PXB tweaks and fixes

V2 was at: . Patches #1 through #3 have not been modified, relative to v2. Patch #4 has been dropped and reimlpemented with an arguably better / simpler approach. PXE-boot tested with OVMF, using a virtio-net-pci NIC behind a PXB. Thanks

[Qemu-devel] [PATCH v3 5/6] hw/core: explicit OFW unit address property for SysBusDevice

The sysbus_get_fw_dev_path() function formats OpenFirmware device path nodes ("driver-name@unit-address") for sysbus devices. The first choice for "unit-address" is the base address of the device's first MMIO region. The second choice is its first IO port. However, if two sysbus devices with the s

[Qemu-devel] [PATCH v3 2/6] i386/acpi-build: fix PXB workarounds for unsupported BIOSes

The patch apci: fix PXB behaviour if used with unsupported BIOS uses the following condition to see if a "PXB mem/IO chunk" has *not* been configured by the BIOS: (!range_base || range_base > range_limit) When this condition evaluates to true, said patch *omits* the corresponding entry from

Re: [Qemu-devel] [PATCH target-arm v1 8/9] arm: xlnx-zynqmp: Preface CPU variables with "A"

On Tue, Jun 2, 2015 at 4:57 PM, Alistair Francis wrote: > On Tue, Jun 2, 2015 at 4:04 AM, Peter Crosthwaite > wrote: >> The CPUs currently supported by zynqmp are the APU (application >> processing unit) CPUs. There are other CPUs in Zynqmp so unqualified >> "cpus" in ambiguous. Preface the varia

Re: [Qemu-devel] [PATCH target-arm v1 1/9] target-arm: Prepare support for Cortex-R5

On Mon, Jun 1, 2015 at 11:44 AM, Peter Maydell wrote: > On 1 June 2015 at 19:04, Peter Crosthwaite > wrote: >> Introduce a CPU model for the Cortex R5 processor. ARMv7 with MPU, >> and both thumb and ARM div instructions. >> >> Signed-off-by: Peter Crosthwaite > > This patch needs to go last, n

Re: [Qemu-devel] [PATCH 6/8] qcow2: add autoclear bit for dirty bitmaps

On 06/08/2015 11:21 AM, Vladimir Sementsov-Ogievskiy wrote: > From: Vladimir Sementsov-Ogievskiy > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/qcow2-dirty-bitmap.c | 5 + > block/qcow2.c | 13 +++-- > block/qcow2.h | 9 + > 3 fil

Re: [Qemu-devel] [PATCH target-arm v1 6/9] target-arm: Implement PMSAv7 MPU

On Wed, Jun 10, 2015 at 3:21 PM, Peter Maydell wrote: > On 10 June 2015 at 23:17, Peter Crosthwaite > wrote: >> On Tue, Jun 2, 2015 at 4:59 AM, Peter Maydell >> wrote: >>> On 1 June 2015 at 19:04, Peter Crosthwaite >>> wrote: +switch (access_type) { +case 0: +re

Re: [Qemu-devel] [PATCH v2 11/13] block: Add list of children to BlockDriverState

On 06/10/2015 07:47 AM, Kevin Wolf wrote: > This allows iterating over all children of a given BDS, not only > including bs->file and bs->backing_hd, but also driver-specific > ones like VMDK extents or Quorum children. > > For bdrv_swap(), the list of children of the swapped BDS stays at that > B

Re: [Qemu-devel] [PATCH v2 10/13] queue.h: Add QLIST_FIX_HEAD_PTR()

On 06/10/2015 07:47 AM, Kevin Wolf wrote: > If the head of a list has been moved to a different memory location, the > le_prev link in the first list entry has to be fixed up. Provide a macro > that implements this fixup. > > Signed-off-by: Kevin Wolf > --- > include/qemu/queue.h | 6 ++ > 1

Re: [Qemu-devel] [PATCH v2 09/13] block: Drain requests before swapping nodes in bdrv_swap()

On 06/10/2015 07:47 AM, Kevin Wolf wrote: > bdrv_swap() requires that there are no requests in flight on either of > the two devices. The request coroutine would work on the wrong > BlockDriverState object (with bs->opaque even being interpreted as a > different type potentially) and all sorts of b

Re: [Qemu-devel] [PATCH 4/8] block: add bdrv_load_dirty_bitmap

On 06/09/2015 12:01 PM, Stefan Hajnoczi wrote: > On Mon, Jun 08, 2015 at 06:21:22PM +0300, Vladimir Sementsov-Ogievskiy wrote: >> +BdrvDirtyBitmap *bdrv_load_dirty_bitmap(BlockDriverState *bs, >> +BlockDriverState *file, >> +

Re: [Qemu-devel] [PATCH target-arm v1 6/9] target-arm: Implement PMSAv7 MPU

On 10 June 2015 at 23:17, Peter Crosthwaite wrote: > On Tue, Jun 2, 2015 at 4:59 AM, Peter Maydell > wrote: >> On 1 June 2015 at 19:04, Peter Crosthwaite >> wrote: >>> +switch (access_type) { >>> +case 0: >>> +return *prot & PAGE_READ ? 0 : 0x00D; >>> +case 1: >>> +

Re: [Qemu-devel] [PATCH target-arm v1 6/9] target-arm: Implement PMSAv7 MPU

On Tue, Jun 2, 2015 at 4:59 AM, Peter Maydell wrote: > On 1 June 2015 at 19:04, Peter Crosthwaite > wrote: >> Unified MPU only. Uses ARM architecture major revision to switch >> between PMSAv5 and v7 when ARM_FEATURE_MPU is set. PMSA v6 remains >> unsupported and is asserted against. >> >> The r

Re: [Qemu-devel] [PATCH v2 07/13] block: Use QemuOpts in bdrv_open_common()

On 06/10/2015 07:47 AM, Kevin Wolf wrote: > Instead of manually parsing options and then deleting them from the > options QDict, just use QemuOpts like most other places that deal with > block device options. > > More options will be added there and then QemuOpts is a lot more > managable than ope

Re: [Qemu-devel] [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption

I already forgot the old one: I got a 2.3.0 qemu installed on the RHEL 5.3 machine, and since this machine has more disk spaces than the CentOS6.4 (now 6.6), so I copied again all emulated machine images from CentOS to RHEL machine, and started to build a new one for RHEL7.1 LE for Power on the 2.3

Re: [Qemu-devel] [PATCH v2 03/13] check-qdict: Test cases for new functions

On 06/10/2015 07:46 AM, Kevin Wolf wrote: > This adds test cases for the following new QDict functions: > > * qdict_array_entries() > * qdict_set_default_str() > * qdict_copy_default() > > Signed-off-by: Kevin Wolf > --- > tests/check-qdict.c | 67 >

Re: [Qemu-devel] [PATCH v2 02/13] qdict: Add qdict_{set, copy}_default()

On 06/10/2015 07:46 AM, Kevin Wolf wrote: > In the block layer functions that determine options for a child block > device, it's a common pattern to either copy options from the parent's > options or to set a default string if the option isn't explicitly set > yet for the child. Provide convenience

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/10/15 22:11, Laszlo Ersek wrote: > On 06/10/15 21:34, Laszlo Ersek wrote: >> On 06/10/15 21:26, Marcel Apfelbaum wrote: >>> BTW, did you try to boot from it :) ? >> >> No, not yet; I'll have to write additional OVMF code for that; but the >> syntax is OK, and the information is there, so I'm

Re: [Qemu-devel] [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption

Both X86_64. > Date: Wed, 10 Jun 2015 16:56:35 + > From: dgilb...@redhat.com > To: w...@hotmail.com > Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk > corruption > > if you're running the 2.3.0 on the RHEL5.3 and the 1.53 on CentOS6.6 we can't > know if the problem >

[Qemu-devel] [PATCH 1/4] prep: QOM'ify System I/O

Part of the functionality is extracted from hw/ppc/prep.c. Also add support for board identification/equipment registers. Signed-off-by: Hervé Poussineau --- hw/ppc/Makefile.objs | 1 + hw/ppc/prep_systemio.c | 300 + trace-events |

[Qemu-devel] [PATCH 2/4] prep: add RS/6000 debug device

Signed-off-by: Hervé Poussineau --- default-configs/ppc-softmmu.mak | 1 + hw/ppc/Makefile.objs| 1 + hw/ppc/rs6000_debug.c | 260 3 files changed, 262 insertions(+) create mode 100644 hw/ppc/rs6000_debug.c diff --git a/default-

[Qemu-devel] [PATCH 3/4] prep: add IBM RS/6000 7020 (40p) memory controller

Signed-off-by: Hervé Poussineau --- default-configs/ppc-softmmu.mak | 1 + hw/ppc/Makefile.objs| 1 + hw/ppc/rs6000_mc.c | 229 trace-events| 7 ++ 4 files changed, 238 insertions(+) create mode 100644 hw

[Qemu-devel] [PATCH 4/4] prep: add IBM RS/6000 7020 (40p) machine emulation

Machine is very simple (only one PCI host bridge and an ISA bridge). Provide a ibm_40p.cfg file to add more devices to this machine. Syntax is: qemu-system-ppc -M 40p -readconfig ibm_40p.cfg Signed-off-by: Hervé Poussineau --- default-configs/ppc-softmmu.mak | 2 + docs/ibm_40p.cfg

[Qemu-devel] [PATCH 0/4] PPC IBM 40p PReP emulation

Hi, This patchset adds the emulation of the IBM RS/6000 7020 (40p). The real machine is able to run AIX (up to 4.3.3), Windows NT (up to 4.0 SP1), the beta of OS/2 PowerPC, Solaris, Linux, NetBSD/PReP ... I've tested current emulation with Open Firmware PReP and with official firmware. Patch 2

Re: [Qemu-devel] [PATCH] block: Change bitmap truncate conditional to assertion

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/10/2015 04:52 PM, Eric Blake wrote: > On 06/10/2015 11:24 AM, John Snow wrote: >> Requires: 1433796555-5608-1-git-send-email-js...@redhat.com >> [PATCH] block: record new size in bdrv_dirty_bitmap_truncate >> > > Shouldn't this be after th

Re: [Qemu-devel] [PATCH] block: Change bitmap truncate conditional to assertion

On 06/10/2015 11:24 AM, John Snow wrote: > Requires: 1433796555-5608-1-git-send-email-js...@redhat.com > [PATCH] block: record new size in bdrv_dirty_bitmap_truncate > Shouldn't this be after the '---' separator? > This is an artifact of an older version that had both all-bitmap and >

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

On Wed, Jun 10, 2015 at 10:25:57PM +0200, Thibaut Collet wrote: > Yes backend can save everything to be able to send the rarp alone after a live > migration. > Main purpose of this patch is to answer to the point raise by Jason on the > previous version of my patch: > > Yes, your patch works well f

Re: [Qemu-devel] [PATCH v2 01/13] qdict: Add qdict_array_entries()

On 06/10/2015 07:46 AM, Kevin Wolf wrote: > This counts the entries in a flattened array in a QDict without > actually splitting the QDict into a QList. > > bdrv_open_image() doesn't take a QList, but rather a QDict and a key > prefix string, so this is more convenient for block drivers which have

Re: [Qemu-devel] Query QEMU Tablet / Mouse position / Mouse freeze in guest

Hi Gerd, thanks a lot! After some browsing through search result lists, it looks similar to the issue that was reported here: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1323758 I will try the input_* tracepoints if this does not fix it. I need some feedback from my colleague to check if i

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

Yes backend can save everything to be able to send the rarp alone after a live migration. Main purpose of this patch is to answer to the point raise by Jason on the previous version of my patch: > Yes, your patch works well for recent drivers. But the problem is legacy > guest/driver without VIRTIO

[Qemu-devel] Modifying start location for binary translation

Hello there, I've been working to understand how QEMU works in an attempt to use it for a project on dynamic binary translation. I've been tracing my way through the user-mode emulation files via GDB and careful examination of the source code (I'm working with v1.1 as it's a bit simpler to unders

Re: [Qemu-devel] [PATCH v3 16/16] [RFC] dma/rc4030: do multiple calls to address_space_rw when doing DMA transfers

On 10 June 2015 at 20:37, Hervé Poussineau wrote: > Hi Leon, > > > Le 10/06/2015 14:00, Leon Alrae a écrit : >> >> Hi Hervé, >> >> On 03/06/2015 21:45, Hervé Poussineau wrote: >>> >>> This fixes Windows NT 4.0/MIPS, which was always bugchecking with >>> IRQL_NOT_LESS_OR_EQUAL. >>> >>> Signed-off-b

Re: [Qemu-devel] [PATCH v3 16/16] [RFC] dma/rc4030: do multiple calls to address_space_rw when doing DMA transfers

On 10 June 2015 at 20:37, Hervé Poussineau wrote: > Hi Leon, > > > Le 10/06/2015 14:00, Leon Alrae a écrit : >> >> Hi Hervé, >> >> On 03/06/2015 21:45, Hervé Poussineau wrote: >>> >>> This fixes Windows NT 4.0/MIPS, which was always bugchecking with >>> IRQL_NOT_LESS_OR_EQUAL. >>> >>> Signed-off-b

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/10/15 21:34, Laszlo Ersek wrote: > On 06/10/15 21:26, Marcel Apfelbaum wrote: >> On 06/10/2015 08:07 PM, Laszlo Ersek wrote: >>> The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot >>> off devices behind the PXB. This happens because the >>> sysbus_get_fw_dev_path() functi

[Qemu-devel] [PATCH] gt64xxx: access right I/O port when activating byte swapping

Incidentally, this fixes YAMON on big endian guest. Signed-off-by: Hervé Poussineau --- hw/mips/gt64xxx_pci.c | 62 +-- 1 file changed, 60 insertions(+), 2 deletions(-) diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c index 10fcca3..39dd

[Qemu-devel] Chrome version Release!

To qemu-devel@nongnu.org I have released the Chrome version of QEMU. https://chrome.google.com/webstore/detail/pnacl-qemu/mogglnfmfhjnjmeehdjppldblehpniom Sorry, my english is very poor. I would like if possible to link the URL above http://wiki.qemu.org/Links You can download this source code

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/10/15 21:26, Marcel Apfelbaum wrote: > On 06/10/2015 08:07 PM, Laszlo Ersek wrote: >> The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot >> off devices behind the PXB. This happens because the >> sysbus_get_fw_dev_path() function in "hw/core/sysbus.c" doesn't have >> enou

Re: [Qemu-devel] [PATCH v3 16/16] [RFC] dma/rc4030: do multiple calls to address_space_rw when doing DMA transfers

Hi Leon, Le 10/06/2015 14:00, Leon Alrae a écrit : Hi Hervé, On 03/06/2015 21:45, Hervé Poussineau wrote: This fixes Windows NT 4.0/MIPS, which was always bugchecking with IRQL_NOT_LESS_OR_EQUAL. Signed-off-by: Hervé Poussineau --- hw/dma/rc4030.c | 14 -- 1 file changed, 12 i

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/10/15 21:26, Marcel Apfelbaum wrote: > On 06/10/2015 08:07 PM, Laszlo Ersek wrote: >> The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot >> off devices behind the PXB. This happens because the >> sysbus_get_fw_dev_path() function in "hw/core/sysbus.c" doesn't have >> enou

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/10/2015 08:07 PM, Laszlo Ersek wrote: The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot off devices behind the PXB. This happens because the sysbus_get_fw_dev_path() function in "hw/core/sysbus.c" doesn't have enough information to format a unique identifier for the PX

Re: [Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

On 06/10/2015 08:07 PM, Laszlo Ersek wrote: The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot off devices behind the PXB. This happens because the sysbus_get_fw_dev_path() function in "hw/core/sysbus.c" doesn't have enough information to format a unique identifier for the PX

Re: [Qemu-devel] [PULL 0/5] vga updates

emote-tracking branch 'remotes/rth/tags/pull-tcg-20150609' into > staging (2015-06-09 15:29:34 +0100) > > are available in the git repository at: > > > git://git.kraxel.org/qemu tags/pull-vga-20150610-1 > > for you to fetch changes up to 62232bf48456bda4058ceae058

Re: [Qemu-devel] [PATCH v2 3/4] hw/pci-bridge: create interrupt-less, hotplug-less bridge for PXB

On 06/10/15 20:22, Marcel Apfelbaum wrote: > On 06/10/2015 08:07 PM, Laszlo Ersek wrote: >> OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI >> Bus driver globally signals the firmware that PCI enumeration and >> resource >> allocation have completed. At this point QEMU rege

Re: [Qemu-devel] [PATCH RFC v2 0/3] Fix slow startup with many disks

Am 10.06.2015 um 13:38 schrieb Alexander Yarygin: > Changes in v2: > - Patch "block-backend: Introduce blk_drain() and replace blk_drain_all()" > splitted to two. > - blk_drain() moved to above virtio_blk_data_plane_stop(). > > During reset the aio_poll() function is called at least

Re: [Qemu-devel] [PATCH v2 3/4] hw/pci-bridge: create interrupt-less, hotplug-less bridge for PXB

On 06/10/2015 08:07 PM, Laszlo Ersek wrote: OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI Bus driver globally signals the firmware that PCI enumeration and resource allocation have completed. At this point QEMU regenerates the ACPI payload in an fw_cfg read callback, an

[Qemu-devel] [PATCH] block: Change bitmap truncate conditional to assertion

Requires: 1433796555-5608-1-git-send-email-js...@redhat.com [PATCH] block: record new size in bdrv_dirty_bitmap_truncate This is an artifact of an older version that had both all-bitmap and single-bitmap truncate functions, and some info got lost in the shuffle. Bitmaps can only be froz

Re: [Qemu-devel] [PULL v3 0/8] fw_cfg patch queue

482df92717f8b4a3b746081a62b724f: > > Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20150609' into > staging (2015-06-09 15:29:34 +0100) > > are available in the git repository at: > > > git://git.kraxel.org/qemu tags/pull-fw_cfg-20150610-1 >

[Qemu-devel] [PATCH v2 3/4] hw/pci-bridge: create interrupt-less, hotplug-less bridge for PXB

OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI Bus driver globally signals the firmware that PCI enumeration and resource allocation have completed. At this point QEMU regenerates the ACPI payload in an fw_cfg read callback, and this is when the PXB's _CRS gets populated.

[Qemu-devel] [PATCH v2 4/4] hw/pci-bridge: push down PXB in qtree in order to format PXB bus numer

The PXB implementation doesn't allow firmware (SeaBIOS or OVMF) to boot off devices behind the PXB. This happens because the sysbus_get_fw_dev_path() function in "hw/core/sysbus.c" doesn't have enough information to format a unique identifier for the PXB in question, and consequently the OpenFirmwa

[Qemu-devel] [PATCH v2 2/4] i386/acpi-build: fix PXB workarounds for unsupported BIOSes

The patch apci: fix PXB behaviour if used with unsupported BIOS uses the following condition to see if a "PXB mem/IO chunk" has *not* been configured by the BIOS: (!range_base || range_base > range_limit) When this condition evaluates to true, said patch *omits* the corresponding entry from

[Qemu-devel] [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption

and I've just seen your older bug report - https://bugs.launchpad.net/qemu/+bug/1289898 - isn't this exactly the same problem? Why open a new bug? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1463812

[Qemu-devel] [PATCH v2 0/4] PXB tweaks and fixes

Version 2 of: http://thread.gmane.org/gmane.comp.emulators.qemu/342206/focus=342208 - Patches #1 and #2 have not been changed. - Patch #3 replaces #3 and #4 from v1. - Patch #4 addresses a separate issue, raised originally in bullet (7) of

[Qemu-devel] [PATCH v2 1/4] i386/acpi-build: more traditional _UID and _HID for PXB root buses

The ACPI specification permits the _HID and _UID objects to evaluate to strings. (See "6.1.5 _HID (Hardware ID)" and "6.1.12 _UID (Unique ID)" in the ACPI v6.0 spec.) With regard to related standards, the UEFI specification can also express a device address composed from string _HID and _UID ident

[Qemu-devel] [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption

if you're running the 2.3.0 on the RHEL5.3 and the 1.53 on CentOS6.6 we can't know if the problem is with the qemu 2.3.0 or with running it on the older host? Please run the two qemus on the same host and see if the problem follows the host or the qemu version. Also, just checking; is that 64b

[Qemu-devel] [Bug 1463909] [NEW] virtio: networking not working when guest's eth0 is not in promiscuous mode

Public bug reported: We are unable to get http responses from qemu guest machine until interface inside qemu guest machine is in promiscuous mode. Our configuration is following: | Host server| | /eth1.10(IP1)

Re: [Qemu-devel] [PATCH 4/4] i386/acpi-build: build_crs(): fetch BAR from PCI config space directly

On Wed, Jun 10, 2015 at 01:07:17PM +0200, Laszlo Ersek wrote: > On 06/10/15 12:06, Marcel Apfelbaum wrote: > > On 06/09/2015 11:34 PM, Laszlo Ersek wrote: > >> On 06/07/15 11:23, Michael S. Tsirkin wrote: > >>> On Sat, Jun 06, 2015 at 01:46:29AM +0200, Laszlo Ersek wrote: > OVMF downloads the

Re: [Qemu-devel] [PATCH 4/4] i386/acpi-build: build_crs(): fetch BAR from PCI config space directly

On Tue, Jun 09, 2015 at 10:34:32PM +0200, Laszlo Ersek wrote: > On 06/07/15 11:23, Michael S. Tsirkin wrote: > > On Sat, Jun 06, 2015 at 01:46:29AM +0200, Laszlo Ersek wrote: > >> OVMF downloads the ACPI linker/loader script from QEMU when the edk2 PCI > >> Bus driver globally signals the firmware

Re: [Qemu-devel] [PATCH v3 1/2] ACPI: Add definitions for the SPCR table

On Wed, Jun 10, 2015 at 05:52:38AM -0400, Andrew Jones wrote: > SPCR is the Serial Port Console Redirection Table. See the document > linked from http://uefi.org/acpi. For serial port types, "Interface > Type", see the documentation for the Debug Port Table 2 (DBG2). > > Signed-off-by: Andrew Jone

Re: [Qemu-devel] [PATCH v3 0/2] ACPI: ARM: add SPCR table

On Wed, Jun 10, 2015 at 05:52:37AM -0400, Andrew Jones wrote: > Adding this table allows the guest to boot without the console= > parameter added to the kernel command line. And anyway, kernel doc > Documentation/arm64/acpi_object_usage.txt says it's a required > table for arm64. Looks good to me.

Re: [Qemu-devel] [PATCH v3 2/2] hw/arm/virt-acpi-build: Add SPCR table

On Wed, Jun 10, 2015 at 05:52:39AM -0400, Andrew Jones wrote: > Signed-off-by: Andrew Jones > Tested-by: Shannon Zhao Acked-by: Michael S. Tsirkin > --- > hw/arm/virt-acpi-build.c | 43 ++- > 1 file changed, 42 insertions(+), 1 deletion(-) > > diff --g

Re: [Qemu-devel] [PATCH 1/2] qapi: Add "detect-zeroes" option to drive-mirror

On Wed, Jun 10, 2015 at 7:04 PM, Alexandre DERUMIER wrote: >>>Sorry, forgot to mention - of course I`ve pulled all previous >>>zeroing-related queue, so I haven`t had only the QMP-related fix >>>running on top of the master :) > > Hi, I had a discussion about rbd mirroring, detect-zeroes and spars

Re: [Qemu-devel] [PATCH 1/2] qapi: Add "detect-zeroes" option to drive-mirror

>>Sorry, forgot to mention - of course I`ve pulled all previous >>zeroing-related queue, so I haven`t had only the QMP-related fix >>running on top of the master :) Hi, I had a discussion about rbd mirroring, detect-zeroes and sparse target, some months ago with paolo http://qemu.11.n7.nabbl

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

On Wed, Jun 10, 2015 at 05:48:47PM +0200, Thibaut Collet wrote: > I have involved QEMU because QEMU prepares the rarp. I agree that backend has > probably all the information to do that. > But backend does not know if the guest supports the  > VIRTIO_NET_F_GUEST_ANNOUNCE Why not? Backend has the

Re: [Qemu-devel] [PULL v2 0/3] Initial vfio-platform support

On 9 June 2015 at 16:55, Alex Williamson wrote: > The following changes since commit 2e29dd7c44db30e3d3c108ab2a622cbdac6d16f0: > > Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into > staging (2015-06-08 14:07:32 +0100) > > are available in the git repository at: > > > g

Re: [Qemu-devel] [PATCH 1/2] qapi: Add "detect-zeroes" option to drive-mirror

> '{"execute":"drive-mirror", "arguments": { "device": > "drive-virtio-disk0", "target": > "rbd:dev-rack2/vm33090-dest:id=qemukvm:key=xxx:auth_supported=cephx\\;none:mon_host=10.6.0.1\\:6789\\;10.6.0.3\\:6789\\;10.6.0.4\\:6789", > "mode": "existing", "sync": "full", "detect-zeroes": true, "format":

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

I have involved QEMU because QEMU prepares the rarp. I agree that backend has probably all the information to do that. But backend does not know if the guest supports the VIRTIO_NET_F_GUEST_ANNOUNCE and will send a useless rarp. Maybe this duplication of requests is not very important and in this

Re: [Qemu-devel] [PATCH 1/2] qapi: Add "detect-zeroes" option to drive-mirror

On Mon, Jun 8, 2015 at 10:06 AM, Fam Zheng wrote: > The new optional flag defaults to true, in which case, mirror job would > check the read sectors and use sparse write if they are zero. Otherwise > data will be fully copied. > > Signed-off-by: Fam Zheng > --- > block/mirror.c| 21

Re: [Qemu-devel] [PATCH v3 1/2] vhost user: add support of live migration

On Wed, Jun 10, 2015 at 03:52:43PM +0200, Michael S. Tsirkin wrote: > > +void vhost_net_inject_rarp(struct vhost_net *net, const uint8_t *buf, > > size_t size) > > +{ > > +if ((net->dev.acked_features & (1 << VIRTIO_NET_F_GUEST_ANNOUNCE)) == > > 0) { > > +fprintf(stderr, > > +

Re: [Qemu-devel] [PATCH v3 2/2] vhost user: Add RARP injection for legacy guest

On Wed, Jun 10, 2015 at 03:43:03PM +0200, Thibaut Collet wrote: > In case of live migration with legacy guest (without > VIRTIO_NET_F_GUEST_ANNOUNCE) > a message is added between QEMU and the vhost client/backend. > This message provides the RARP content, prepared by QEMU, to the vhost > client/ba

Re: [Qemu-devel] [PATCH 1/8] spec: add qcow2-dirty-bitmaps specification

Am 08.06.2015 um 17:21 hat Vladimir Sementsov-Ogievskiy geschrieben: > From: Vladimir Sementsov-Ogievskiy > > Persistent dirty bitmaps will be saved into qcow2 files. It may be used > as 'internal' bitmaps (for qcow2 drives) or as 'external' bitmaps for > other drives (there may be qcow2 file wit

Re: [Qemu-devel] [PATCH v2 RFC 0/8] block: persistent dirty bitmaps

On Mon, Jun 08, 2015 at 06:21:18PM +0300, Vladimir Sementsov-Ogievskiy wrote: > QCow2 header is extended by fields 'nb_dirty_bitmaps' and > 'dirty_bitmaps_offset' like with snapshots. > > Proposed command line syntax is the following: > > -dirty-bitmap [option1=val1][,option2=val2]... Two questi

Re: [Qemu-devel] [PATCH v3 1/2] vhost user: add support of live migration

> vhost_net_inject_rarp is vhost-user specific. For this function test on VIRTIO_NET_F_GUEST_ANNOUNCE bit is important to take a decision and call a new vhost ioctl (see next patch) if the guest does not support this feature and allow the vhost client/backend send the RARP packet. Use of the VIRTI

[Qemu-devel] [PATCH v2 6/7] virtio-9p-device: move qdev properties into virtio-9p-device.c

As only one place in virtio-9p-device.c uses DEFINE_VIRTIO_9P_PROPERTIES, there is no need to expose it. Inline it into virtio-9p-device.c to avoid wrongly use. Signed-off-by: Shannon Zhao Signed-off-by: Shannon Zhao Reviewed-by: Paolo Bonzini Acked-by: Cornelia Huck --- hw/9pfs/virtio-9p-dev

[Qemu-devel] [PATCH v2 5/7] virtio-serial-bus: move qdev properties into virtio-serial-bus.c

As only one place in virtio-serial-bus.c uses DEFINE_VIRTIO_SERIAL_PROPERTIES, there is no need to expose it. Inline it into virtio-serial-bus.c to avoid wrongly use. Signed-off-by: Shannon Zhao Signed-off-by: Shannon Zhao Reviewed-by: Paolo Bonzini Acked-by: Cornelia Huck --- hw/char/virtio-

[Qemu-devel] [PATCH v2 3/7] virtio-scsi: move qdev properties into virtio-scsi.c

As only one place in virtio-scsi.c uses DEFINE_VIRTIO_SCSI_PROPERTIES and DEFINE_VIRTIO_SCSI_FEATURES, there is no need to expose them. Inline them into virtio-scsi.c to avoid wrongly use. Signed-off-by: Shannon Zhao Signed-off-by: Shannon Zhao Reviewed-by: Paolo Bonzini Acked-by: Cornelia Huck

[Qemu-devel] [PATCH v2 4/7] virtio-rng: move qdev properties into virtio-rng.c

As only one place in virtio-rng.c uses DEFINE_VIRTIO_RNG_PROPERTIES, there is no need to expose it. Inline it into virtio-rng.c to avoid wrongly use. Signed-off-by: Shannon Zhao Signed-off-by: Shannon Zhao Reviewed-by: Paolo Bonzini Acked-by: Cornelia Huck --- hw/virtio/virtio-rng.c |

[Qemu-devel] [PATCH v2 7/7] vhost-scsi: move qdev properties into vhost-scsi.c

As only one place in vhost-scsi.c uses DEFINE_VHOST_SCSI_PROPERTIES, there is no need to expose it. Inline it into vhost-scsi.c to avoid wrongly use. Signed-off-by: Shannon Zhao Signed-off-by: Shannon Zhao Reviewed-by: Paolo Bonzini Acked-by: Cornelia Huck --- hw/scsi/vhost-scsi.c |

[Qemu-devel] [PATCH v2 2/7] virtio-net.h: Remove unsed DEFINE_VIRTIO_NET_PROPERTIES

Remove unsed DEFINE_VIRTIO_NET_PROPERTIES in virtio-net.h and delete a space typo. Signed-off-by: Shannon Zhao Signed-off-by: Shannon Zhao Reviewed-by: Paolo Bonzini Acked-by: Cornelia Huck --- include/hw/virtio/virtio-net.h | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --

[Qemu-devel] [PATCH v2 1/7] virtio-net: move qdev properties into virtio-net.c

As only one place in virtio-net.c uses DEFINE_VIRTIO_NET_FEATURES, there is no need to expose it. Inline it into virtio-net.c to avoid wrongly use. Signed-off-by: Shannon Zhao Signed-off-by: Shannon Zhao Reviewed-by: Paolo Bonzini --- hw/net/virtio-net.c| 44 +++

  1   2   3   >