Re: [Qemu-devel] [PATCH 1/2] configure: Replace bash code by standard shell code

On Fri, Jul 20, Peter Maydell wrote: I actually wrote a patch sitting on top of this one by Stefan which moves the flag to QEMU_CFLAGS; both are in the 11-patch series dealing with various configure Werror issues: http://patchwork.ozlabs.org/patch/171689/ The actual CFLAGS issue had to be

Re: [Qemu-devel] [PATCH] xen-mapcache: don't unmap locked entry during mapcache invalidation

On Thu, Mar 15, Stefano Stabellini wrote: On Thu, 15 Mar 2012, Julien Grall wrote: When an IOREQ_TYPE_INVALIDATE is sent to QEMU, it invalidates all entry of the map cache even if it's locked. QEMU is not able to know that entry was invalidated, so when an IO access is requested a

[Qemu-devel] [PATCH] qemu/configure: fix CFLAGS handling for i386

to qemu.git since it has the same issue. Please apply to both trees. Signed-off-by: Olaf Hering o...@aepfle.de --- configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: qemu-xen-dir-remote/configure === --- qemu-xen-dir

Re: [Qemu-devel] [PATCH] qemu/configure: fix CFLAGS handling for i386

On Sat, Mar 31, Andreas Färber wrote: This is the only usage of += outside Makefile fragments, so I wonder if its use may have been by accident. Is it safe in a POSIX context? Or should we better use CFLAGS=$CFLAGS -march=486? Now that I look at the shebang, configure is a sh script and += is

Re: [Qemu-devel] [PATCH] qemu/configure: fix CFLAGS handling for i386

On Sat, Mar 31, Peter Maydell wrote: On 31 March 2012 16:41, Andreas Färber afaer...@suse.de wrote: This is the only usage of += outside Makefile fragments, so I wonder if its use may have been by accident. Is it safe in a POSIX context? Or should we better use CFLAGS=$CFLAGS -march=486?

[Qemu-devel] [PATCH v2] qemu/configure: fix CFLAGS handling for i386

. This patch is against the qemu-xen tree, but it should apply also to qemu.git since it has the same issue. Please apply to both trees. Signed-off-by: Olaf Hering o...@aepfle.de --- configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: qemu-xen-dir-remote/configure

[Qemu-devel] [PATCH] megasas: remove buildtime strings

Using __DATE__ or __TIME__ in binary pkgs changes the checksum of compiled binaries if they get rebuilt, even if there are no other source changes. Replace the dynamic strings with some equally informative static strings. Signed-off-by: Olaf Hering o...@aepfle.de --- Or remove both lines

Re: [Qemu-devel] [PATCH v2] xen_disk: add discard support

On Thu, Feb 20, Stefano Stabellini wrote: On Thu, 6 Feb 2014, Olaf Hering wrote: @@ -253,6 +254,8 @@ static int ioreq_parse(struct ioreq *ioreq) case BLKIF_OP_WRITE: ioreq-prot = PROT_READ; /* from memory */ break; +case BLKIF_OP_DISCARD: +return 0

Re: [Qemu-devel] [PATCH v2] xen_disk: add discard support

On Thu, Feb 20, Stefano Stabellini wrote: On Thu, 6 Feb 2014, Olaf Hering wrote: @@ -253,6 +254,8 @@ static int ioreq_parse(struct ioreq *ioreq) case BLKIF_OP_WRITE: ioreq-prot = PROT_READ; /* from memory */ break; +case BLKIF_OP_DISCARD: +return 0

Re: [Qemu-devel] [PATCH v2] xen_disk: add discard support

On Sun, Feb 23, Stefano Stabellini wrote: Given that 4.2 is the first Xen release to have BLKIF_OP_DISCARD, maybe we could just #define BLKIF_OP_DISCARD 5 in that case? Do we actually need to #ifndef BLKIF_OP_DISCARD? I will do just the #define and resend with that change. Olaf

[Qemu-devel] [PATCH v3] xen_disk: add discard support

was intentionally created non-sparse to avoid fragmentation. Signed-off-by: Olaf Hering o...@aepfle.de --- v3: define BLKIF_OP_DISCARD for xen-4.1 v2: depends on xen_disk: fix io accounting remove call to bdrv_acct_start hw/block/xen_blkif.h| 12 hw/block/xen_disk.c | 33

[Qemu-devel] [PATCH] xen_disk: add discard support

was intentionally created non-sparse to avoid fragmentation. Signed-off-by: Olaf Hering o...@aepfle.de --- The counter part for libxl is here, will go into xen-4.5: http://lists.xenproject.org/archives/html/xen-devel/2014-01/msg02632.html checkpatch comaplains about tabs in hw/block/xen_blkif.h

Re: [Qemu-devel] [PATCH] xen_disk: add discard support

On Mon, Feb 03, Kevin Wolf wrote: Am 30.01.2014 um 16:02 hat Olaf Hering geschrieben: +case BLKIF_OP_DISCARD: +{ +struct blkif_request_discard *discard_req = (void *)ioreq-req; +bdrv_acct_start(blkdev-bs, ioreq-acct, +discard_req

Re: [Qemu-devel] [PATCH] xen_disk: add discard support

On Tue, Feb 04, Olaf Hering wrote: On Tue, Feb 04, Kevin Wolf wrote: Now you call bdrv_acct_done() in the callback without having a matching bdrv_acct_start(). You need to make it conditional in the callback. Stefano, Is ioreq_runio_qemu_aio symetric in this regard anyway? In case

Re: [Qemu-devel] [PATCH] xen_disk: add discard support

On Mon, Feb 03, Kevin Wolf wrote: Am 30.01.2014 um 16:02 hat Olaf Hering geschrieben: +++ b/hw/block/xen_disk.c +case BLKIF_OP_DISCARD: +{ +struct blkif_request_discard *discard_req = (void *)ioreq-req; +bdrv_acct_start(blkdev-bs, ioreq-acct

Re: [Qemu-devel] [PATCH] xen_disk: add discard support

On Tue, Feb 04, Kevin Wolf wrote: Now you call bdrv_acct_done() in the callback without having a matching bdrv_acct_start(). You need to make it conditional in the callback. I see. Stefano, Is ioreq_runio_qemu_aio symetric in this regard anyway? In case of

[Qemu-devel] [PATCH] xen_disk: fix io accounting

bdrv_acct_done was called unconditional. But in case the ioreq has no segments there is no matching bdrv_acct_start call. This could lead to bogus accounting values. Found by code inspection. Signed-off-by: Olaf Hering o...@aepfle.de --- hw/block/xen_disk.c | 13 - 1 file changed

[Qemu-devel] [PATCH v2] xen_disk: add discard support

was intentionally created non-sparse to avoid fragmentation. Signed-off-by: Olaf Hering o...@aepfle.de --- v2: depends on xen_disk: fix io accounting remove call to bdrv_acct_start hw/block/xen_blkif.h | 12 hw/block/xen_disk.c | 33 + 2 files changed, 45

[Qemu-devel] [PATCH v2] xen_disk: fix io accounting

bdrv_acct_done was called unconditional. But in case the ioreq has no segments there is no matching bdrv_acct_start call. This could lead to bogus accounting values. Found by code inspection. Signed-off-by: Olaf Hering o...@aepfle.de --- v2: add comment /* fall through */ hw/block/xen_disk.c

Re: [Qemu-devel] [PATCH v2] xen_disk: fix io accounting

On Fri, Feb 07, Stefano Stabellini wrote: added to my queue, I'll fix the tab manually Thanks, sorry for the TAB. Olaf

[Qemu-devel] emulating a display, instead of just a dumb graphics card

Right now qemu does appearently just emulate a graphics card (Cirrus for example), but not an attached monitor/display. The result is confusion in the guest OS. The current DRM drivers in upstream Linux seem to default to VESA modes. These are either provided by qemu, or Xorg uses a fixed

[Qemu-devel] [PATCH] build: preserve debug symbols with --enable-debug-info

the symbols. The requirement to pass also --disable-strip looks odd. Signed-off-by: Olaf Hering o...@aepfle.de Cc: Paolo Bonzini pbonz...@redhat.com Cc: Peter Maydell peter.mayd...@linaro.org Cc: Michael Tokarev m...@tls.msk.ru Cc: Stefan Hajnoczi stefa...@redhat.com Cc: Stefan Weil s...@weilnetz.de

Re: [Qemu-devel] [PATCH] build: preserve debug symbols with --enable-debug-info

On Thu, Sep 25, Peter Maydell wrote: On 25 September 2014 09:06, Olaf Hering o...@aepfle.de wrote: During code review for xen I noticed that --enable-debug-info would still strip the binaries because strip_opt= defaults to yes. If --enable-debug-info is passed to configure it has

Re: [Qemu-devel] [PATCH] build: preserve debug symbols with --enable-debug-info

On Thu, Sep 25, Stefan Hajnoczi wrote: If you make this change and packagers are unaware, they could accidentally ship qemu packages that contain the full debug symbols in the binaries. rpm will take care of that all by itself. Olaf

Re: [Qemu-devel] get a handle for the tap device to shut it down

On Fri, Nov 28, Olaf Hering wrote: I wonder if the missing disable of the tap device is intentional, or just an oversight, or if its just to complicated to get from a PCIDevice * to the other end and call the -cleanup function. qemu-traditional did just close all tap devices. With qemu

[Qemu-devel] [PATCH] gtk: fix vte version check

vte_terminal_set_encoding takes 3 args since 0.38.0. This fixes commit fba958c6 ("gtk: implement set_echo") Signed-off-by: Olaf Hering <o...@aepfle.de> --- ui/gtk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui/gtk.c b/ui/gtk.c index 01b8216..58d20ee

Re: [Qemu-devel] [Xen-devel] [PULL 3/4] xen: add pvUSB backend

On Mon, May 23, Gerd Hoffmann wrote: > +++ b/hw/usb/Makefile.objs > +common-obj-$(CONFIG_XEN_BACKEND) += xen-usb.o > +++ b/hw/usb/xen-usb.c > +usb_bus_new(>bus, sizeof(usbif->bus), _usb_bus_ops, > xen_sysdev); xen_sysdev is in an i386-only file, as a result qemu fails to link. Olaf

[Qemu-devel] qemu-upstream compile failure in intel_iommu.c:vtd_context_device_invalidate

Compiling qemu-xen at 2ce1d30 ("xenfb.c: avoid expensive loops when prod <= out_cons") leads to this error with -O1: xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c: In function ‘vtd_context_device_invalidate’: xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c:911:46: error: ‘mask’ may be used

Re: [Qemu-devel] bogus bdrv_check_request in bdrv_co_discard

On Wed, Mar 09, Kevin Wolf wrote: > Removing integer overflow checks without removing the potentially > overflowing operation doesn't feel like a particularly good idea, > though. Why does the code use signed ints anyway for sectors and offset?! Olaf

Re: [Qemu-devel] bogus bdrv_check_request in bdrv_co_discard

On Wed, Mar 09, Olaf Hering wrote: > Why does the code use signed ints anyway for sectors and offset?! I have to check mainline (next week), at least this fixes mkfs for me: +++ xen-4.4.3-testing/tools/qemu-xen-dir-remote/block/raw-posix.c @@ -792,8 +792,8 @@ static BlockDriverAI

[Qemu-devel] bogus bdrv_check_request in bdrv_co_discard

What is the purpose of the bdrv_check_request() call in bdrv_co_discard? It seems a frontend cant possibly know what the limit is in the qemu-of-the-day, I found no interface to propagate BDRV_REQUEST_MAX_SECTORS into the guest. I think to handle nb_sectors > BDRV_REQUEST_MAX_SECTORS

Re: [Qemu-devel] bogus bdrv_check_request in bdrv_co_discard

On Wed, Mar 09, Olaf Hering wrote: > On Wed, Mar 09, Kevin Wolf wrote: > > > Removing integer overflow checks without removing the potentially > > overflowing operation doesn't feel like a particularly good idea, > > though. > > Why does the code use signed ints

Re: [Qemu-devel] [PATCH] build: link with libatomic on powerpc-linux

On Fri, Apr 01, Peter Maydell wrote: > On 1 April 2016 at 13:00, Olaf Hering <o...@aepfle.de> wrote: > > Building on powerpc-linux fails with undefined reference to __atomic_load_8 > > in > > icount_warp_rt(). Force linking to -latomic. > > We should instead b

Re: [Qemu-devel] [Qemu-block] [PATCH] block: split large discard requests from block frontend

On Fri, Apr 01, Max Reitz wrote: > In any case, do you have a test case where a guest was able to submit a > request that led to the overflow error you described in the commit message? mkfs -t ext4 /dev/sdb1 in a xen guest with qcow2 as backing device. When I added discard support to libxl I

[Qemu-devel] [PATCH] block: split large discard requests from block frontend

Large discard requests lead to sign expansion errors in qemu. Since there is no API to tell a guest about the limitations qmeu has to split a large request itself. Signed-off-by: Olaf Hering <o...@aepfle.de> Cc: Stefan Hajnoczi <stefa...@redhat.com> Cc: Kevin Wolf <kw...@redhat.

[Qemu-devel] [PATCH] build: link with libatomic on powerpc-linux

Building on powerpc-linux fails with undefined reference to __atomic_load_8 in icount_warp_rt(). Force linking to -latomic. Fixes a0aa44b ("include/qemu/atomic.h: default to __atomic functions") Signed-off-by: Olaf Hering <o...@aepfle.de> Cc: Paolo Bonzini <pbonz...@redhat

[Qemu-devel] [PATCH v2] build: link with libatomic on powerpc-linux

Building on powerpc-linux fails with undefined reference to __atomic_load_8 in icount_warp_rt(). Force linking to -latomic. Fixes a0aa44b ("include/qemu/atomic.h: default to __atomic functions") Signed-off-by: Olaf Hering <o...@aepfle.de> Cc: Paolo Bonzini <pbonz...@redhat

[Qemu-devel] [PATCH 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

Implement SUSE specific unplug protocol for emulated PCI devices in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'. This protocol was implemented and used since Xen 3.0.4. It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and openSUSE 12.3. Signed-off-by: Olaf Hering &l

[Qemu-devel] [PATCH 1/2] xen_platform: unplug also SCSI disks

-off-by: Olaf Hering <o...@aepfle.de> --- hw/i386/xen/xen_platform.c | 5 + 1 file changed, 5 insertions(+) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index aa78393..d94b53c 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -115,6 +

[Qemu-devel] [PATCH 0/2] Xen HVM unplug changes

Update unplug in Xen HVM guests to cover more cases. Please review. Olaf Olaf Hering (2): xen_platform: unplug also SCSI disks xen_platform: SUSE xenlinux unplug for emulated PCI hw/i386/xen/xen_platform.c | 36 +++- 1 file changed, 35 insertions(+), 1

[Qemu-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

Implement SUSE specific unplug protocol for emulated PCI devices in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'. This protocol was implemented and used since Xen 3.0.4. It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and openSUSE 12.3. Signed-off-by: Olaf Hering &l

Re: [Qemu-devel] qemu-2.7 regression, IPXE boot in HVM fails

On Wed, Aug 31, Olaf Hering wrote: > The following HVM domU.cfg crashes during boot from emulated network > with qemu 2.7, but it works fine with qemu stable-2.6 branch: > > name='hvm' > memory=1024 > vcpus=2 > boot="n" > disk=[ 'file:/disk0.raw,hda,w', ] >

[Qemu-devel] [PATCH v2 0/2] Xen HVM unplug changes

Update unplug in Xen HVM guests to cover more cases. Please review. Olaf changes in v2: - fix issues reported by checkpatch Olaf Hering (2): xen_platform: unplug also SCSI disks xen_platform: SUSE xenlinux unplug for emulated PCI hw/i386/xen/xen_platform.c | 35

[Qemu-devel] [PATCH v2 1/2] xen_platform: unplug also SCSI disks

-off-by: Olaf Hering <o...@aepfle.de> --- hw/i386/xen/xen_platform.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index aa78393..53be3c7 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -114,6 +

[Qemu-devel] qemu-2.7 regression, IPXE boot in HVM fails

The following HVM domU.cfg crashes during boot from emulated network with qemu 2.7, but it works fine with qemu stable-2.6 branch: name='hvm' memory=1024 vcpus=2 boot="n" disk=[ 'file:/disk0.raw,hda,w', ] vif=[ 'mac=00:08:15:41:10:80,bridge=br0', ] keymap="de" serial="pty" builder="hvm" vnc=1

Re: [Qemu-devel] [PATCH v2 1/2] xen_platform: unplug also SCSI disks

On Wed, Sep 14, Stefano Stabellini wrote: > Written like this, the code will unplug any Xen SCSI disks together with > Xen IDE disks when the guest writes "1" to ioport `0x10`. I am sorry to > be pedantic, but the recent changes introduced to > docs/misc/hvm-emulated-unplug.markdown do not cover

Re: [Qemu-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

On Wed, Sep 14, Stefano Stabellini wrote: > The doc says: > > "If VMDP was configured to control just NIC devices it would write the > value 0x1 to offset 0x8. If VMDP was configured to control just storage > devices it would write the value 0x2 to offset 0x8." > > So 0x1 to 0x8 to unplug NICs,

Re: [Qemu-devel] [PATCH v4 06/20] ppc/pnv: add XSCOM infrastructure

On Mon, Oct 03, Cédric Le Goater wrote: > +++ b/include/hw/ppc/pnv_xscom.h > +typedef struct PnvChip PnvChip; This causes a compile error with gcc 4.5.1: ... [ 552s] In file included from /usr/src/packages/BUILD/qemu-20161104T092624.9226682/hw/ppc/pnv.c:29:0: [ 552s]

Re: [Qemu-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

On Thu, Oct 13, Stefano Stabellini wrote: > On Fri, 2 Sep 2016, Olaf Hering wrote: > > Implement SUSE specific unplug protocol for emulated PCI devices > > in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'. > > This protocol was implemented and used since Xen 3.0.4.

[Qemu-devel] [PATCH v3 0/2] Xen HVM unplug changes

Update unplug in Xen HVM guests to cover more cases. Please review. changes in v3: - adapt to API changes from 49137bf ("block-backend: remove blk_flush_all") changes in v2: - fix issues reported by checkpatch Olaf Hering (2): xen_platform: unplug also SCSI disks xen_plat

[Qemu-devel] [PATCH v3 1/2] xen_platform: unplug also SCSI disks

-off-by: Olaf Hering <o...@aepfle.de> --- hw/i386/xen/xen_platform.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index f85635c..91d8a7a 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -114,6 +

[Qemu-devel] [PATCH v3 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

versions are handled as well. Signed-off-by: Olaf Hering <o...@aepfle.de> --- hw/i386/xen/xen_platform.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index 91d8a7a..2e1e543 100644 --- a/hw/i3

Re: [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23. November 2016 21:44:50 MEZ, schrieb Olaf Hering <o...@aepfle.de>: >Is this a can for 2.x? candidate Olaf

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Wed, Nov 23, Olaf Hering wrote: > > > +if (!blk_split_discard(ioreq, req->sector_number, > > > req->nr_sectors)) { > > > +goto err; > > How is error handling supposed to work here? In the guest the cmd is stuck, instead of getting

[Qemu-devel] [PATCH v2] xen_disk: split discard input to match internal representation

: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Fixes f313520 ("xen_disk: add discard support") Signed-off-by: Olaf Hering <o...@aepf

[Qemu-devel] [PATCH v3] xen_disk: split discard input to match internal representation

: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Fixes f313520 ("xen_disk: add discard support") Signed-off-by: Olaf Hering <o...@aepf

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

Ping. On Fri, Nov 18, Olaf Hering wrote: > On Fri, Nov 18, Olaf Hering wrote: > > > @@ -708,12 +743,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > > +if (!blk_split_discard(ioreq, req->sector_number, > > req->nr_sectors)) { > > +

Re: [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation

Am 23. November 2016 13:27:13 MEZ, schrieb Kevin Wolf : >Am 23.11.2016 um 12:40 hat Eric Blake geschrieben: >> Qualifies as a bug fix, so requesting 2.8 inclusion. >> Reviewed-by: Eric Blake Is this a can for 2.x? Olaf

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Fri, Nov 18, Eric Blake wrote: > if (sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) I have looked at this for a while now and cant spot how this would cover all cases. Are you saying there should be just a single overflow check, yours? My change has two: one to check for wrap around

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Tue, Nov 22, Eric Blake wrote: > if (sec_start + sec_count < sec_count || > sec_start > (INT64_MAX >> BDRV_SECTOR_BITS) - sec_count) { > return false; > } My point was: how does this handle sec_start=0,sec_count=UINT64_MAX or sec_start=INT64_MAX,sec_count=INT64_MAX? For me this gets

Re: [Qemu-devel] [Qemu-block] [PATCH] block: split large discard requests from block frontend

On Fri, May 06, Max Reitz wrote: > On 01.04.2016 19:49, Olaf Hering wrote: > > On Fri, Apr 01, Max Reitz wrote: > > > >> In any case, do you have a test case where a guest was able to submit a > >> request that led to the overflow error you described in the comm

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

Am 18. November 2016 14:43:18 MEZ, schrieb Eric Blake <ebl...@redhat.com>: >On 11/18/2016 04:24 AM, Olaf Hering wrote: >> The guest sends discard requests as u64 sector/count pairs, but the >> block layer operates internally with s64/s32 pairs. The conversion >> lead

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Fri, Nov 18, Eric Blake wrote: > On 11/18/2016 04:24 AM, Olaf Hering wrote: > > +/* Overflowing byte limit? */ > > +if ((sec_start + sec_count) > ((INT64_MAX + INT_MAX) >> > > BDRV_SECTOR_BITS)) { > This is undefined. INT64_MAX + anything non-negati

Re: [Qemu-devel] [Qemu-block] [PATCH] block: split large discard requests from block frontend

On Thu, Nov 17, Olaf Hering wrote: > Looking at current master, BLKIF_OP_DISCARD is indeed broken. The values > passed from the guest are u64 and get stashed into signed values. I will > add a loop to repeatedly call blk_aio_pdiscard with small chunks of > BDRV_REQUEST_MAX_SECT

[Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Signed-off-by: Olaf Hering <o...@aepfle.de> --- hw/block/xen_disk.

Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges

On Fri, Nov 18, Olaf Hering wrote: > @@ -708,12 +743,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > +if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) { > +goto err; How is error handling supposed to work here? Initially I forgot

Re: [Qemu-devel] [PATCH] hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()

On Wed, Nov 02, Thomas Huth wrote: > Olaf Hering reported a build failure due to an undefined reference > to 'qemu_log_vprintf'. Explicitely including qemu/log.h seems to > fix the issue. > > Signed-off-by: Thomas Huth <th...@redhat.com> Tested-by: Olaf Hering &l

[Qemu-devel] build failures in master

Not sure if there are automated build tests to catch such mistakes, these errors appeared after qemu-20161028T142950.fd209e4: [ 337s] ../hw/xen/xen_pvdev.o: In function `xen_pv_printf': [ 337s] /home/abuild/rpmbuild/BUILD/qemu-20161101T165305.4eb28ab/hw/xen/xen_pvdev.c:220: undefined

Re: [Qemu-devel] build failures in master

On Wed, Nov 02, Thomas Huth wrote: > Does it work if you add an explicit #include "qemu/log.h" at the > beginning of that file (after osdep.h)? I will try that. > system. Which version of GTK are you using? 2.18.9 as included in SLE11. Olaf signature.asc Description: PGP signature

Re: [Qemu-devel] build failures in master

On Wed, Nov 02, Olaf Hering wrote: > On Wed, Nov 02, Thomas Huth wrote: > > Does it work if you add an explicit #include "qemu/log.h" at the > > beginning of that file (after osdep.h)? > I will try that. Yes, that helps. Thanks. Olaf signature.asc Description: PGP signature

Re: [Qemu-devel] [PATCH] xen-disk: use g_malloc0 to fix build

On Fri, Jul 28, Eric Blake wrote: > This version is prone to multiplication overflow (well, maybe not, but > you have to audit for that). Wouldn't it be better to use: What could go wrong? qemu will die either way, I think. Olaf signature.asc Description: PGP signature

[Qemu-devel] [PATCH] xen-disk: use g_malloc0 to fix build

g_malloc0_n is available since glib-2.24. To allow build with older glib versions use the generic g_malloc0, which is already used in many other places in the code. Fixes commit 3284fad728 ("xen-disk: add support for multi-page shared rings") Signed-off-by: Olaf Hering <o...@aepfl

[Qemu-devel] [PATCH v2] xen-disk: use g_new0 to fix build

g_malloc0_n is available since glib-2.24. To allow build with older glib versions use the generic g_new0, which is already used in many other places in the code. Fixes commit 3284fad728 ("xen-disk: add support for multi-page shared rings") Signed-off-by: Olaf Hering <o...@aepfl

Re: [Qemu-devel] [Xen-devel] [PULL 3/3] xen-disk: add support for multi-page shared rings

On Tue, Jun 27, Stefano Stabellini wrote: > From: Paul Durrant > The blkif protocol has had provision for negotiation of multi-page shared > rings for some time now and many guest OS have support in their frontend > drivers. > +++ b/hw/block/xen_disk.c > +domids =

Re: [Qemu-devel] [PULL 1/2] xen-disk: use g_new0 to fix build

On Wed, Sep 20, Stefano Stabellini wrote: > From: Olaf Hering <o...@aepfle.de> > g_malloc0_n is available since glib-2.24. To allow build with older glib > versions use the generic g_new0, which is already used in many other > places in the code. > Fixes commit 3284fad728 (&

Re: [Qemu-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42

Am Fri, 4 May 2018 17:00:23 +0100 schrieb Daniel P. Berrangé : > - I suggested following libvirt's lead in writing a policy for how > we pick supported OS targets to inform maintainers when min versions > can be increased. Since Xen depends on qemu, it also means

[Qemu-devel] [PATCH v2] replace functions which are only available in glib-2.24

, with g_renew. Fixes commit 418026ca43 ("util: Introduce vfio helpers") Signed-off-by: Olaf Hering <o...@aepfle.de> --- This must go into stable-2.12. util/vfio-helpers.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/util/vfio-helpers.c b/util/vfio

Re: [Qemu-devel] [PATCH] replace functions which are only available in glib-2.24

Am Mon, 14 May 2018 23:04:31 -0700 (PDT) schrieb no-re...@patchew.org: > vfio-helpers.c:525:17: error: assignment from incompatible pointer type Does anyone happen to know what s390x is trying to do here? Olaf pgpHBYpHmh42k.pgp Description: Digitale Signatur von OpenPGP

[Qemu-devel] [PATCH] replace functions which are only available in glib-2.24

, with g_renew. Fixes commit 418026ca43 ("util: Introduce vfio helpers") Signed-off-by: Olaf Hering <o...@aepfle.de> --- This must go into stable-2.12. util/vfio-helpers.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/util/vfio-helpers.c b/util/vfio

Re: [Qemu-devel] [PATCH v1] configure: recognize more rpmbuild macros

Am Wed, 9 May 2018 00:15:42 +0200 schrieb Paolo Bonzini : > Actually, --program-prefix= and --exec-prefix= have a meaning, they > cannot just be ignored. For now I've removed this line; what is the > exact incantation used by SUSE Linux? Like in every other rpm.rpm I guess:

Re: [Qemu-devel] [PATCH v2 1/3] glib: bump min required glib library version to 2.40

Am Thu, 7 Jun 2018 09:25:24 +0100 schrieb Daniel P. Berrangé : > https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms SLE12-SP2: 2.48.2 Olaf pgpzqS0yDN306.pgp Description: Digitale Signatur von OpenPGP

Re: [Qemu-devel] [PATCH v1] configure: require glib-2.24

Am Thu, 26 Apr 2018 13:52:04 +0200 schrieb Paolo Bonzini : > min-glib Dockerfile is using glib 2.22 Why did it not prevent the bad commit from entering 2.12? Olaf pgpLXaYUkUuzv.pgp Description: Digitale Signatur von OpenPGP

[Qemu-devel] sed invocation for keycodemapdb not portable

With commit 927128222b ("ui: add keycodemapdb repository as a GIT submodule") sed is called with -E, which requires a recent sed. The version of sed shipped with SLE11 is 4.1.5, which does not understand the option '-E'. As a result xen-4.11 will fail to build. Is there a way to achive the same

Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue

Am Thu, 9 Aug 2018 16:37:05 +0200 schrieb Paolo Bonzini : > If no RAM is allocated (i.e. xen_map_cache will return NULL), however, > the memory should not be registered as RAM with the memory API. So I > think the bug is in Xen code. Someone familiar with that code has to figure that out. A

Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue

Am Thu, 9 Aug 2018 16:38:16 +0200 schrieb Olaf Hering : > Someone familiar with that code has to figure that out. A ballooned page will > trigger that bug. Indeed, xen-4.4 + qemu-3.0 crashes with ballooned pages. That can easily happen if the domU does readdir via NFS. Olaf Thread 1

Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue

Am Thu, 9 Aug 2018 16:52:22 +0200 schrieb Paolo Bonzini : > I think the simplest fix is for the map > cache to set aside a zero page and return it whenever it is asked for a > ballooned page. Can qemu actually know if it ran into a ballooned page? I think no. Olaf pgpmdqCLn4Xnn.pgp

[Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue

The codepaths behind qemu_ram_ptr_length can return NULL. Avoid crashing the device-model in such case, just move on. Signed-off-by: Olaf Hering --- This happens if calling xendevicemodel_create_ioreq_server() is disabled, and eventually if that function returns an error. --- exec.c | 3 ++- 1

Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue

Am Thu, 9 Aug 2018 16:14:03 +0200 schrieb Olaf Hering : > The codepaths behind qemu_ram_ptr_length can return NULL. While that might be a bug by itself, the question is why in that case no memset(buf, 0xff, l) is done? Olaf pgpPcpqmT0hnz.pgp Description: Digitale Signatur von OpenPGP

Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue

Am Fri, 10 Aug 2018 14:29:28 +0200 schrieb Paolo Bonzini : > On 10/08/2018 12:32, Olaf Hering wrote: > > Am Fri, 10 Aug 2018 12:25:09 +0200 > > schrieb Paolo Bonzini : > > So you mean that function must not return NULL? > > Or should the caller check for the result?

Re: [Qemu-devel] [PATCH v1] exec: handle NULL pointer in flatview_read_continue

Am Fri, 10 Aug 2018 12:25:09 +0200 schrieb Paolo Bonzini : > There are many more callers of qemu_ram_ptr_length, and none of them check > the result. So you mean that function must not return NULL? Or should the caller check for the result? Olaf pgp6zq9J9aL36.pgp Description: Digitale

Re: [Qemu-devel] [PATCH v2] configure: require glib-2.24 on Linux

Am Wed, 18 Apr 2018 10:04:03 -0500 schrieb Eric Blake : > Rather than hacking configure, why not fix util/vfio-helpers.c to avoid > g_realloc_n()? We've done it before; see commit 071d405 I can not really test it, this variant may work: --- a/util/vfio-helpers.c +++

Re: [Qemu-devel] [PATCH v2] configure: require glib-2.24 on Linux

Am Wed, 18 Apr 2018 10:04:03 -0500 schrieb Eric Blake : > avoid g_realloc_n()? I guess there is some global header for this, to prevent further accidents? extern void *g_realloc_n_can_not_be_used(void); #define g_realloc_n(a,b,c) g_realloc_n_can_not_be_used() Olaf

Re: [Qemu-devel] [PATCH v1] configure: require glib-2.24

Am Wed, 18 Apr 2018 14:45:38 +0200 schrieb Cornelia Huck : > Are we ready to give up support for whatever distro is still on 2.22? This is SLE11, in case it matters for this discussion. Olaf pgp5sY4ljZvqS.pgp Description: Digitale Signatur von OpenPGP

[Qemu-devel] [PATCH v2] configure: require glib-2.24 on Linux

Since usage of g_realloc_n was introduced, glib-2.22 can not be used anymore on Linux. Leave non-Linux unchanged because one developer system still uses it. Fixes commit 418026ca43 ("util: Introduce vfio helpers") Signed-off-by: Olaf Hering <o...@aepfle.de> --- configure |

Re: [Qemu-devel] [PATCH v1] configure: require glib-2.24

Am Wed, 18 Apr 2018 13:47:53 +0100 schrieb Daniel P. Berrangé : > IIRC, one of Peters desired build targets required 2.22, but I guess we > missed this bug because that platform would not enable vfio functionality ? Does the check in configure need a wrap "if Linux", just as

[Qemu-devel] [PATCH v1] configure: require glib-2.24

Since usage of g_realloc_n was introduced, glib-2.22 can not be used anymore. Fixes commit 418026ca43 ("util: Introduce vfio helpers") Signed-off-by: Olaf Hering <o...@aepfle.de> --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b

Re: [Qemu-devel] [PATCH v1] configure: require glib-2.24

Am Wed, 18 Apr 2018 05:53:58 -0700 (PDT) schrieb no-re...@patchew.org: > This series failed docker-build@min-glib build test. I guess that test must be fixed either way because it does not test what it is supposed to test... Olaf pgpgzq5OJ4fiN.pgp Description: Digitale Signatur von OpenPGP

[Qemu-devel] [PATCH v1] roms/ipxe: use configured compiler for ipxe

mmand "gcc" hardcoded. That binary may not be suitable to build ipxe. Reuse the same compiler command that is used to build qemu by specifying CC and HOST_CC as make commandline option to override the built-in defaults of ipxe. Signed-off-by: Olaf Hering <o...@aepfle.de> --- roms/Makefile

Re: [Qemu-devel] [PATCH v1] roms/ipxe: use configured compiler for ipxe

Am Wed, 18 Apr 2018 10:13:10 +0200 schrieb Olaf Hering <o...@aepfle.de>: > configure allows to run a dedicated compiler binary, which is stored in > CC and HOST_CC variables, and overrides the default 'cc' command. > This command however is not used when building ipxe from source.

[Qemu-devel] [PATCH v1] configure: recognize more rpmbuild macros

Extend the list of recognized, but ignored options from rpms %configure macro. This fixes build on hosts running SUSE Linux. Signed-off-by: Olaf Hering <o...@aepfle.de> --- configure | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure b/configure index 0a19b033bc..6e9b994f21

  1   2   >