Re: [Qemu-devel] [PATCH V2 2/2] block/nfs: add support for nfs_umount

On Wed, Sep 11, 2019 at 5:48 PM Max Reitz wrote: > > On 10.09.19 17:41, Peter Lieven wrote: > > libnfs recently added support for unmounting. Add support > > in Qemu too. > > > > Signed-off-by: Peter Lieven > > --- > > block/nfs.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git

Re: [Qemu-devel] [PATCH] block/nfs: add support for nfs_umount

On Thu, Sep 5, 2019 at 8:16 PM Peter Lieven wrote: > > Am 05.09.19 um 12:05 schrieb ronnie sahlberg: > > On Thu, Sep 5, 2019 at 7:43 PM Peter Lieven wrote: > >> Am 04.09.19 um 11:34 schrieb Kevin Wolf: > >>> Am 03.09.2019 um 21:52 hat Peter Lieven geschriebe

Re: [Qemu-devel] [PATCH] block/nfs: add support for nfs_umount

>fh filedescriptor from your eventsystem. Because the fd is about to be closed so there is great chance it will be recycled for a completely different purpose if you open any other files from qemu. 3, call nfs_umount() Internally this will close the socket to the NFS server, then go through thr process to open a new socket to the portmapper to discover the mount server, then close that socket and reconnect a new socket again to the mount server and perform the UMNT call. ronnie sahlberg > Peter > >

Re: [Qemu-devel] iSER transport name is not good

normal iSCSI or whether it should use iSER. I think RDMA would be a less good name for this as RDMA is not only used to transport iSCSI but is also used for NFS as well as SMB. regards ronnie sahlberg On Fri, Dec 8, 2017 at 4:41 AM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: >

Re: [Qemu-devel] [PATCH 3/8] qemu-options qemu-doc: Move "Device URL Syntax" to qemu-doc

outside the list of options both in qemu-doc and in >> qemu.1. >> >> There's substantial overlap with the existing qemu-doc section "Disk >> Images". Mark with a TODO comment. >> >> Output of --help will be fixed next. >> >> Cc: Ronnie Sahl

Re: [Qemu-devel] [PATCH 4/8] qemu-options: Move -iscsi under "Block device options"

Reviewed-by: Ronnie Sahlberg <ronniesahlb...@gmail.com> Would be nice if this died at some stage : [,password=password] But that is for a different patch. On Wed, Oct 4, 2017 at 8:12 PM, Marc-André Lureau <marcandre.lur...@gmail.com> wrote: > On Mon, Oct 2, 2017 at 4:03 PM, Ma

Re: [Qemu-devel] [PATCH 5/8] qemu-options: Add missing -iscsi Texinfo documentation

Reviewed-by: Ronnie Sahlberg <ronniesahlb...@gmail.com> On Tue, Oct 3, 2017 at 12:03 AM, Markus Armbruster <arm...@redhat.com> wrote: > Cc: Ronnie Sahlberg <ronniesahlb...@gmail.com> > Cc: Kevin Wolf <kw...@redhat.com> > Cc: Max Reitz <mre...@redhat.com> &

Re: [Qemu-devel] iSER-Libiscsi presentation from SDC2016

Congratulation to a fantastic presentation Roy. Very impressive data! On Wed, Sep 21, 2016 at 11:39 AM, Roy Shterman wrote: > Hi all, > > > > Attached presentation was presented in SDC 2016 in Santa-Clara and actually > summaries the iSER implementation inside Libiscsi/QEMU.

Re: [Qemu-devel] [PATCH] block/iscsi: Adding iser support in Libiscsi-QEMU

It is never too late. I can start working on a patch to add "iser://" URL support to libiscsi right now. It should be a trivial change. I think I would prefer iser:// instead of iscsi+iser:// but it is not religiusly. Let me know if you rather want iscsi+iser. But you would still need some

Re: [Qemu-devel] [Qemu-block] [PATCH] send readcapacity10 when readcapacity16 failed

MMC devices: READ CAPACITY 10 support is mandatory. No support for READ CAPACITY 16 SBC devices: READ CAPACITY 10 is mandatory READ CAPACITY 16 support is only required when you have thin provisioning or protection information (or if the device is >2^32 blocks) Almost all, but apparently not all,

Re: [Qemu-devel] [PATCH] iscsi: Add chap and "initiator-name" etc as per drive options

On Fri, Sep 11, 2015 at 8:20 AM, Eric Blake wrote: > On 09/11/2015 12:00 AM, Fam Zheng wrote: >> Previously we use "-iscsi id=target-iqn,user=foo,password=bar,..." to >> specify iscsi connection parameters, unfortunately it doesn't work with >> qemu-img. >> >> This patch adds

Re: [Qemu-devel] [Qemu-stable] Recent patches for 2.4

On Tue, Aug 4, 2015 at 5:53 AM, Peter Lieven p...@kamp.de wrote: Am 04.08.2015 um 14:29 schrieb Peter Lieven: Am 04.08.2015 um 14:09 schrieb Paolo Bonzini: On 04/08/2015 13:57, Peter Lieven wrote: Okay, what I found out is that in aio_poll I get revents = POLLIN for the nfs file

Re: [Qemu-devel] [PATCH] block/iscsi: add support for request timeouts

LGTM It is good to finally have timeouts that work in libiscsi, and a consumer that can use and benefit from it. On Tue, Jun 16, 2015 at 4:45 AM, Peter Lieven p...@kamp.de wrote: libiscsi starting with 1.15 will properly support timeout of iscsi commands. The default will remain no timeout,

Re: [Qemu-devel] [PATCH] block/iscsi: do not forget to logout from target

Reviewed-By: Ronnie Sahlberg ronniesahlb...@gmail.com On Tue, Apr 14, 2015 at 1:37 AM, Peter Lieven p...@kamp.de wrote: We actually were always impolitely dropping the connection and not cleanly logging out. Cc: qemu-sta...@nongnu.org Signed-off-by: Peter Lieven p...@kamp.de --- block

Re: [Qemu-devel] [Qemu-block] [PATCH] block/iscsi: handle zero events from iscsi_which_events

On Wed, Apr 8, 2015 at 1:38 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Apr 7, 2015 at 9:08 PM, Peter Lieven p...@kamp.de wrote: Please CC qemu-devel@nongnu.org in the future. All patches must be on the qemu-devel mailing list so they can be merged (for transparency). I have added

Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests

On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 08/09/2014 16:35, Peter Lieven ha scritto: messages. :) So you would not throw an error msg here? No, though a trace could be useful. Is there a howto somewhere how to implement that? Try commit

Re: [Qemu-devel] [PATCH 0/4] introduce max_transfer_length

Looks good to me. (minor question is just why not let default max be 0x for both 10 and 16 CDBs ?) On Fri, Sep 5, 2014 at 9:51 AM, Peter Lieven p...@kamp.de wrote: This series adds the basics for introducing a maximum transfer length to the block layer. Its main purpose is currently

Re: [Qemu-devel] [PATCH 0/4] introduce max_transfer_length

Feel free to add a Reviewed-by: Ronnie Sahlberg ronniesahlb...@gmail.com to the patches. On Fri, Sep 5, 2014 at 12:52 PM, Peter Lieven p...@kamp.de wrote: Am 05.09.2014 um 19:05 schrieb ronnie sahlberg: Looks good to me. (minor question is just why not let default max be 0x for both 10

Re: [Qemu-devel] [PATCH] block/iscsi: use 16 byte CDBs only when necessary

On Wed, Sep 3, 2014 at 1:09 AM, Peter Lieven p...@kamp.de wrote: Am 02.09.2014 um 21:30 schrieb Peter Lieven p...@kamp.de: Looking at the code, is it possible that not the guest is causing trouble here, but multiwrite_merge code? From what I see the only limit it has when merging

Re: [Qemu-devel] [PATCH] block/iscsi: use 16 byte CDBs only when necessary

On Wed, Sep 3, 2014 at 7:18 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 03/09/2014 16:17, ronnie sahlberg ha scritto: I think (a) would be best. But I would suggest some small modifications: Set the default max to something even smaller, like 256 sectors. This should not have much effect

Re: [Qemu-devel] [PATCH] block/iscsi: use 16 byte CDBs only when necessary

be targets that support really huge MaxBurstLengths 32MB. For those you probably want to switch to WRITE16 when the SCSI transfer length goes 0x. - if (iscsilun-use_16_for_rw) { + if (iscsilun-use_16_for_rw || num_sectors 0x) { regards ronnie sahlberg On Mon, Sep 1, 2014 at 8:21 AM

Re: [Qemu-devel] [RFC] How to handle feature regressions in new QEMU releases

On Wed, Jul 16, 2014 at 10:29 AM, Michael Tokarev m...@tls.msk.ru wrote: 16.07.2014 21:23, ronnie sahlberg wrote: If you ask debian to upgrade. Could you ask them to wait and upgrade after I have release the next version, hopefully if all goes well, at the end of this week? There's

Re: [Qemu-devel] [PULL 00/14] SCSI changes for 2014-06-18

On Wed, Jun 18, 2014 at 8:57 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 18/06/2014 17:53, Peter Maydell ha scritto: Then you probably need to fix the configure test ;-) This is Ubuntu Trusty so really pretty recent (it's my main x86 build machine, not some oddball platform); libiscsi-dev

Re: [Qemu-devel] [PATCH] block/iscsi: use 16 byte CDBs only when necessary

Looks good. As an alternative, you could do the 10 vs 16 decision based on the LBA instead of the size of the device : -if (use_16_for_ws) { + if (lba = 0x1) { iTask.task = iscsi_writesame16_task(iscsilun-iscsi, iscsilun-lun, lba,

Re: [Qemu-devel] [PATCH] block/iscsi: use 16 byte CDBs only when necessary

On Wed, Jun 4, 2014 at 7:43 AM, Peter Lieven p...@kamp.de wrote: Am 04.06.2014 16:00, schrieb ronnie sahlberg: Looks good. As an alternative, you could do the 10 vs 16 decision based on the LBA instead of the size of the device : -if (use_16_for_ws) { + if (lba = 0x1

Re: [Qemu-devel] [PATCH 08/20] nfs: Handle failure for potentially large allocations

For this case and for the iscsi case, isn't it likely that once this happens the guest is pretty much doomed since I/O to the disk will no longer work ? Should we also change the block layer so that IF *_readv/_writev fails with -ENOMEM then it should try again but break the request up into a

Re: [Qemu-devel] [PATCH 08/22] iscsi: implement .bdrv_detach/attach_aio_context()

On Thu, May 8, 2014 at 4:33 AM, Stefan Hajnoczi stefa...@redhat.com wrote: On Wed, May 07, 2014 at 04:09:27PM +0200, Peter Lieven wrote: On 07.05.2014 12:29, Paolo Bonzini wrote: Il 07/05/2014 12:07, Stefan Hajnoczi ha scritto: On Fri, May 02, 2014 at 12:39:06AM +0200, Peter Lieven wrote:

Re: [Qemu-devel] [PATCHv6 0/6] block: add native support for NFS

Please try to sync libnfs again. Autotools is still a bit of a mystery for me. On Tue, Jan 28, 2014 at 2:16 AM, Stefan Hajnoczi stefa...@redhat.com wrote: On Mon, Jan 27, 2014 at 07:28:07PM +0100, Peter Lieven wrote: Am 27.01.2014 17:11, schrieb Stefan Hajnoczi: On Mon, Jan 13, 2014 at

Re: [Qemu-devel] [PATCHv5] block: add native support for NFS

header to send to the server. But if you want to parse the url yourself, you can do that too, by just calling nfs_set_auth(nfs, libnfs_authunix_create(..., 10, 10, ... Regards Ronnie Sahlberg

Re: [Qemu-devel] [PATCHv5] block: add native support for NFS

On Fri, Jan 10, 2014 at 8:10 AM, Peter Lieven p...@kamp.de wrote: Ronnie, can you also give a short advise on Kevin's question about short reads. I think they can happen if we read beyond past EOF or not? Short reads should normally not happen in libnfs itself since servers are often

Re: [Qemu-devel] [Qemu-ppc] [PATCH] spapr_vscsi: Fix REPORT_LUNS handling

On Thu, Jan 2, 2014 at 7:41 AM, Alexander Graf ag...@suse.de wrote: On 02.01.2014, at 16:31, Alexander Graf ag...@suse.de wrote: On 18.10.2013, at 14:33, Nathan Whitehorn nwhiteh...@freebsd.org wrote: Intercept REPORT_LUNS commands addressed either to SRP LUN 0 or the well-known LUN for

Re: [Qemu-devel] [PATCHv4] block: add native support for NFS

by an url of the form: nfs://host/export/filename For example: qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2 You need LibNFS from Ronnie Sahlberg available at: git://github.com/sahlberg/libnfs.git for this to work. During configure it is automatically probed for libnfs

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

The sync calls uses a trivial eventloop built into libnfs using poll(). Mixing the _async() and _sync() interfaces in libnfs means you may risk running nested eventloops. Pain and tears lie behind that door. On Fri, Dec 20, 2013 at 6:43 AM, Peter Lieven p...@kamp.de wrote: On 20.12.2013 15:38,

Re: [Qemu-devel] [PATCH] block/iscsi: return -ENOMEM if an async call fails immediately

Looks good. Reviewed-by: Ronnie Sahlberg ronniesahlb...@gmail.com On Fri, Dec 20, 2013 at 1:02 AM, Peter Lieven p...@kamp.de wrote: if an async libiscsi call fails directly it can only be due to an out of memory condition. All other errors are returned through the callback. Signed-off

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

On Wed, Dec 18, 2013 at 2:00 AM, Orit Wasserman owass...@redhat.com wrote: On 12/18/2013 01:03 AM, Peter Lieven wrote: Am 17.12.2013 um 18:32 schrieb Daniel P. Berrange berra...@redhat.com: On Tue, Dec 17, 2013 at 10:15:25AM +0100, Peter Lieven wrote: This patch adds native support for

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

On Wed, Dec 18, 2013 at 8:59 AM, Peter Lieven p...@kamp.de wrote: Am 18.12.2013 um 15:42 schrieb ronnie sahlberg ronniesahlb...@gmail.com: On Wed, Dec 18, 2013 at 2:00 AM, Orit Wasserman owass...@redhat.com wrote: On 12/18/2013 01:03 AM, Peter Lieven wrote: Am 17.12.2013 um 18:32 schrieb

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

On Wed, Dec 18, 2013 at 9:42 AM, Peter Lieven p...@kamp.de wrote: Am 18.12.2013 um 18:33 schrieb ronnie sahlberg ronniesahlb...@gmail.com: On Wed, Dec 18, 2013 at 8:59 AM, Peter Lieven p...@kamp.de wrote: Am 18.12.2013 um 15:42 schrieb ronnie sahlberg ronniesahlb...@gmail.com: On Wed, Dec

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

can simply be specified by an url of the form: nfs://host/export/filename For example: qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2 You need libnfs from Ronnie Sahlberg available at: git://github.com/sahlberg/libnfs.git for this to work. During configure

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

On Tue, Dec 17, 2013 at 9:03 AM, Peter Lieven p...@kamp.de wrote: On 17.12.2013 17:47, Stefan Hajnoczi wrote: ... Which NFS protocol versions are supported by current libnfs? Will check that out. Ronnie? It uses NFS v3 only.

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

On Tue, Dec 17, 2013 at 9:03 AM, Peter Lieven p...@kamp.de wrote: On 17.12.2013 17:47, Stefan Hajnoczi wrote: On Tue, Dec 17, 2013 at 10:15:25AM +0100, Peter Lieven wrote: ... +if (nfs_pwrite_async(client-context, client-fh, + sector_num * BDRV_SECTOR_SIZE, +

Re: [Qemu-devel] [PATCHv2] block: add native support for NFS

On Tue, Dec 17, 2013 at 2:36 PM, Peter Lieven p...@kamp.de wrote: Am 17.12.2013 um 18:13 schrieb ronnie sahlberg ronniesahlb...@gmail.com: On Tue, Dec 17, 2013 at 9:03 AM, Peter Lieven p...@kamp.de wrote: On 17.12.2013 17:47, Stefan Hajnoczi wrote: ... Which NFS protocol versions

Re: [Qemu-devel] [PATCH] block: add native support for NFS

simply be specified by an url of the form: nfs://host/export/filename For example: qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2 You need libnfs from Ronnie Sahlberg available at: git://github.com/sahlberg/libnfs.git for this to work. During configure

Re: [Qemu-devel] [PATCH] block: add native support for NFS

For example: qemu-img create -f qcow2 nfs://10.0.0.1/qemu-images/test.qcow2 You need libnfs from Ronnie Sahlberg available at: git://github.com/sahlberg/libnfs.git for this to work. During configure it is automatically probed for libnfs and support is enabled on-the-fly. You can forbid

Re: [Qemu-devel] [PATCH v2 20/20] scsi-disk: correctly implement WRITE SAME

+#define SCSI_WRITE_SAME_MAX 524288 ... +data-iov.iov_len = MIN(data-nb_sectors * 512, SCSI_WRITE_SAME_MAX); I don't think you should just clamp the data to 512k, instead I think you should report the 512k max write same size through BlockLimitsVPD/MaximumWriteSameLength to the

Re: [Qemu-devel] [PATCH v2 20/20] scsi-disk: correctly implement WRITE SAME

That means the initiator will do the split into smaller manageable chunks for you and you get a 1-to-1 mapping between WS10/16 that the initiator issues to qemu and the write-same calls that qemu generates. On Tue, Nov 19, 2013 at 9:23 AM, ronnie sahlberg ronniesahlb...@gmail.com wrote: +#define

Re: [Qemu-devel] [PATCHv7 00/17] block: logical block provisioning enhancements

For better support for older versions of libiscsi I think it would be good to convert all the iscsi_unmap_task/iscsi_writesame*_task/iscsi_*_task functions with calls to the much more genric iscsi_scsi_command_sync(). iscsi_scsi_command_sync() and iscsi_scsi_command_async() have been available

Re: [Qemu-devel] [PATCHv7 00/17] block: logical block provisioning enhancements

It would mean that any version of libiscsi from 1.1 or later would work and there would not be the issues such as UNMAP is only available from 1.2 and forward, WRITESAME* is only availabel from 1.3. SANITIZE only being available from 1.9 ... On Fri, Nov 8, 2013 at 9:52 AM, ronnie sahlberg

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven p...@kamp.de wrote: On 19.07.2013 07:58, Paolo Bonzini wrote: Il 18/07/2013 21:28, Peter Lieven ha scritto: thanks for the details. I think to have optimal performance and best change for unmapping in qemu-img convert it might be best to export

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

On Thu, Jul 18, 2013 at 11:43 AM, Peter Lieven p...@kamp.de wrote: Am 18.07.2013 um 16:35 schrieb Paolo Bonzini pbonz...@redhat.com: Il 18/07/2013 16:32, Peter Lieven ha scritto: (Mis)alignment and granularity can be handled later. We can ignore them for now. Later, if we decide the best

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

On Fri, Jul 19, 2013 at 6:49 AM, Peter Lieven p...@kamp.de wrote: On 19.07.2013 15:25, ronnie sahlberg wrote: On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven p...@kamp.de wrote: On 19.07.2013 07:58, Paolo Bonzini wrote: Il 18/07/2013 21:28, Peter Lieven ha scritto: thanks for the details

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

On Thu, Jul 18, 2013 at 6:29 AM, Peter Lieven p...@kamp.de wrote: On 18.07.2013 14:31, Paolo Bonzini wrote: Il 18/07/2013 13:04, Peter Lieven ha scritto: But if you set BDRV_DISCARD_WRITE_ZEROES, then you always need a fallback to bdrv_write_zeroes. Why not just call bdrv_write_zeroes to

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

BlockLimitsVPD OptimalUnmapGranularity also applies to unmapping with writesame16 : An OPTIMAL UNMAP GRANULARITY field set to a non-zero value indicates the optimal granularity in logical blocks for unmap requests (e.g., an UNMAP command or a WRITE SAME (16) command with the UNMAP bit set to

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

need to check what LogicalBlocksPerPhysicalBlockExponent is. ) regards ronnie sahlberg

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

On Wed, Jul 17, 2013 at 9:27 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 17/07/2013 17:54, ronnie sahlberg ha scritto: I think it is reasonable to assume that IF LBPRZ==1 and IF it is an optimal unmap request then the blocks will become unmapped and they will read back as 0. Yes

Re: [Qemu-devel] [PATCH 4/4] qemu-img: conditionally discard target on convert

On Wed, Jul 17, 2013 at 10:02 AM, Peter Lieven p...@kamp.de wrote: For Disks we always use read/write16 so i think we Should also use writesame16. Or not? Sounds good. Von meinem iPhone gesendet Am 17.07.2013 um 18:31 schrieb ronnie sahlberg ronniesahlb...@gmail.com: On Wed, Jul 17

Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page

and sent a zero block. this would allow an optimization also if lbprz == 0. in this case i would not set the unmap bit. peter Am 05.07.2013 um 09:11 schrieb ronnie sahlberg ronniesahlb...@gmail.com: The device MIGHT map or anchor the blocks after the unmap but it may only do so

Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page

The device MIGHT map or anchor the blocks after the unmap but it may only do so if the blocks that become mapped are all zero. So I think you can safely assume that if lbprz==1 then it will always read back as zero no matter what happens internally in the target. Either the block becomes

Re: [Qemu-devel] [PATCHv2 02/11] iscsi: read unmap info from block limits vpd page

max_unmap : If the target does not return an explicit limit for max_unmap it will return 0x which means no limit. I think you should add a check for max_unmap and clamp it down to something sane. Maybe a maximum of 128M ? Same for bdc, that should also be checked and clamped down to

[Qemu-devel] [PATCH] iSCSI fix crash when using virtio and libiscsi V3

List, Please find a new version of the patch to fix the iSCSI crash when ioctl with iovector is sent. Updated to fix the commit message as per lerseks suggestion. Also added an explicit cast to suppress a compiler warning when we dont have iovector support available.

[Qemu-devel] [PATCH] Fix iSCSI crash on SG_IO with an iovector

Don't assume that SG_IO is always invoked with a simple buffer, check the iovec_count and if it is = 1 then we need to pass an array of iovectors to libiscsi instead of just a plain buffer. Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- block/iscsi.c | 56

Re: [Qemu-devel] [PATCH] iSCSI fix crash when using virtio and libiscsi

I can add the checks and resubmit. On Fri, Jun 21, 2013 at 12:38 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 21/06/2013 04:32, Ronnie Sahlberg ha scritto: Stefan, List Please find a patch that fixes the crashes for using virtio with libiscsi. The problem was that block/iscsi.c always

Re: [Qemu-devel] [PATCH 1/2] iscsi: add support for bdrv_co_is_allocated()

Should we really mix co-routines and AIO in the same backend? Would it not be better to instead add a new bdrb_aio_is_allocaed and use non-blocking async calls to libiscsi ? On Fri, Jun 21, 2013 at 2:18 AM, Kevin Wolf kw...@redhat.com wrote: Am 20.06.2013 um 20:20 hat Peter Lieven geschrieben:

Re: [Qemu-devel] [PATCH 1/2] iscsi: add support for bdrv_co_is_allocated()

On Fri, Jun 21, 2013 at 10:06 AM, Peter Lieven p...@kamp.de wrote: Am 21.06.2013 18:31, schrieb Paolo Bonzini: Il 21/06/2013 13:07, Kevin Wolf ha scritto: Note that you're blocking here. The preferred way would be something involving a yield from the coroutine and a reenter as soon as all

[Qemu-devel] [PATCH] iSCSI fix crash when using virtio and libiscsi V2

or not. If not we fall back to either lots of datain buffers or a serialization dataout buffer. regards ronnie sahlberg

[Qemu-devel] [PATCH] Fix iSCSI crash on SG_IO with an iovector

Don't assume that SG_IO is always invoked with a simple buffer, check the iovec_count and if it is 1 then we need to pass an array of iovectors to libiscsi instead of just a plain buffer. Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- block/iscsi.c | 56

Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio

comment out SG_IO in iscsi_ioctl then the crash does not happen (but the qemu does nto get serial number either) I will look more into it tonight. On Wed, Jun 19, 2013 at 2:17 AM, Laszlo Ersek ler...@redhat.com wrote: On 06/19/13 06:34, ronnie sahlberg wrote: I can reproduce with current QEMU

Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio

On Thu, Jun 20, 2013 at 7:47 AM, Laszlo Ersek ler...@redhat.com wrote: On 06/20/13 15:33, ronnie sahlberg wrote: http://pastebin.com/EuwZPna1 Last few thousand lines from the log with your patch. The crash happens immediately after qemu has called out to iscsi_ioctl with SG_IO to read

[Qemu-devel] [PATCH] iSCSI fix crash when using virtio and libiscsi

against a current libiscsi. I will send patches later to remove the current (LIBISCSI_FEATURE_IOVECTOR) checks in the rest of the file. regards ronnie sahlberg

[Qemu-devel] [PATCH] Fix iSCSI crash on SG_IO with an iovector

Don't assume that SG_IO is always invoked with a simple buffer, check the iovec_count and if it is 1 then we need to pass an array of iovectors to libiscsi instead of just a plain buffer. Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- block/iscsi.c | 31

Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio

I can reproduce with current QEMU. Ubuntu 13 crashes with if=virtio but if=ide is fine. But it seems dependent on the guest/kernel. For example Fedora-18-x86_64-Live-Desktop.iso installs and runs just fine, even with virtio But both ubuntu-12.04-desktop-amd64.iso or

Re: [Qemu-devel] snabbswitch integration with QEMU for userspace ethernet I/O

Julian, Stefan's concerns are valid. (Hopefully, kernel is harder to exploit and more carefully audited.) On Wed, May 29, 2013 at 9:02 AM, Julian Stecklina jstec...@os.inf.tu-dresden.de wrote: On 05/29/2013 04:21 PM, Stefan Hajnoczi wrote: The fact that a single switch process has shared

Re: [Qemu-devel] virtio-scsi WRITE_VERIFY crash

box with QEMU right now, but I would check if it is something similar to this patch : http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg04130.html regards ronnie sahlberg On Mon, Apr 8, 2013 at 8:53 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Apr 05, 2013 at 11:30:00AM -0700

Re: [Qemu-devel] [RFC] find_next_bit optimizations

Even more efficient might be to do bitwise instead of logical or if (tmp | d1 | d2 | d3) { that should remove 3 of the 4 conditional jumps and should become 3 bitwise ors and one conditional jump On Mon, Mar 11, 2013 at 8:58 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 11/03/2013

Re: [Qemu-devel] [RFC V4 00/30] QCOW2 deduplication

Do you really need to resolve the conflicts? It might be easier and sufficient to just flag those hashes where a conflict has been detected as : dont dedup this hash anymore, collissions have been seen. On Wed, Jan 2, 2013 at 10:40 AM, Benoît Canet benoit.ca...@irqsave.net wrote: Le Wednesday

Re: [Qemu-devel] [RFC V4 00/30] QCOW2 deduplication

On Wed, Jan 2, 2013 at 11:18 AM, Troy Benjegerdes ho...@hozed.org wrote: If you do get a hash collision, it's a rather exceptional event, so I'd say every effort should be made to log the event and the data that created it in multiple places. There are three questions I'd ask on a hash

Re: [Qemu-devel] [PATCH][RESEND] iscsi: add support for iSCSI NOPs

Acked-By: ronniesahlb...@gmail.com (Ronnie Sahlberg) This verified that the service is actually operational and is much more reliable than TCP-KEEPALIVES. This is the proper way to monitor that the iscsi target is alive. We should as a later patch add the ability to configure this via the qemu

Re: [Qemu-devel] [PATCH] iscsi: partly avoid iovec linearization in iscsi_aio_writev

On Mon, Nov 19, 2012 at 7:18 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 19/11/2012 15:58, Peter Lieven ha scritto: -/* XXX we should pass the iovec to write16 to avoid the extra copy */ -/* this will allow us to get rid of 'buf' completely */ size = nb_sectors *

Re: [Qemu-devel] [PATCH] iscsi: fix segfault in url parsing

Acked-By: ronniesahlb...@gmail.com On Thu, Nov 15, 2012 at 6:42 AM, Peter Lieven p...@dlhnet.de wrote: If an invalid URL is specified iscsi_get_error(iscsi) is called with iscsi == NULL. Signed-off-by: Peter Lieven p...@kamp.de --- block/iscsi.c |3 +-- 1 file changed, 1 insertion(+),

Re: [Qemu-devel] [PATCH] iscsi: fix deadlock during login

I dont know if we should switch to use synchronous code here. It is much nicer if all code is async. Is it possible to add a timeout instead that would break out if the connect/login has not completed within a certain amount of time? regards ronnie sahlberg On Thu, Nov 15, 2012 at 6:50 AM

Re: [Qemu-devel] [PATCH] iscsi: fix deadlock during login

On Thu, Nov 15, 2012 at 7:54 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 15/11/2012 15:57, ronnie sahlberg ha scritto: I dont know if we should switch to use synchronous code here. It is much nicer if all code is async. bdrv_open is generally synchronous, so I think Peter's patch is ok

Re: [Qemu-devel] Ubuntu/Debian Installer + Virtio-SCSI - Bad ram pointer

On Tue, Oct 30, 2012 at 10:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Oct 30, 2012 at 10:09 PM, ronnie sahlberg ronniesahlb...@gmail.com wrote: About half a year there was an issue where recent kernels had added support to start using new scsi opcodes, but the qemu functions

Re: [Qemu-devel] Ubuntu/Debian Installer + Virtio-SCSI - Bad ram pointer

this is something similar ? I.e. does the guest send an unusual scsi opcode just before the crash ? regards ronnie sahlberg On Tue, Oct 30, 2012 at 12:37 PM, Peter Lieven p...@dlhnet.de wrote: Am 30.10.2012 19:27, schrieb Stefan Hajnoczi: On Tue, Oct 30, 2012 at 4:56 PM, Peter Lieven p...@dlhnet.de wrote

Re: [Qemu-devel] qemu-img convert with block driver without .bdrv_create (like iscsi)

an already existing LUN. What about changing bdrv_create() so that IF there is no .bdrv_create method, then assume it might be a pre-existing file in which case we fallback to use .bdrv_open instead. regards ronnie sahlberg

Re: [Qemu-devel] qemu-img convert with block driver without .bdrv_create (like iscsi)

On Thu, Oct 25, 2012 at 6:58 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 25/10/2012 15:41, ronnie sahlberg ha scritto: On Thu, Oct 25, 2012 at 1:02 AM, Kevin Wolf kw...@redhat.com wrote: Am 25.10.2012 09:52, schrieb Paolo Bonzini: Il 25/10/2012 09:46, Kevin Wolf ha scritto: 1)add

[Qemu-devel] [PATCH] SCSI disk, set HISUP bit in INQ data

Paolo, List Please find a trivial patch that make SCSI-DISK set the HISUP bit in the INQ data. Since I think all LUN numbers are reported as SAM4 describes, we should set this bit. Its already sed in SCSI-BUS regards ronnie sahlberg

[Qemu-devel] [PATCH] SCSI: Standard INQUIRY data should report HiSup flag as set.

the scope of this standard. Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- hw/scsi-disk.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c index 1585683..52bc062 100644 --- a/hw/scsi-disk.c +++ b/hw/scsi-disk.c @@ -678,7 +678,7

Re: [Qemu-devel] [PATCH] iSCSI: We dont need to explicitely call qemu_notify_event() any more

Ping? On Thu, Aug 30, 2012 at 4:56 PM, Ronnie Sahlberg ronniesahlb...@gmail.com wrote: We no longer need to explicitely call qemu_notify_event() any more since this is now done automatically any time the filehandles we listen to change. Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com

Re: [Qemu-devel] [PATCH] iSCSI: We need to support SG_IO also from iscsi_ioctl()

ping? On Thu, Aug 30, 2012 at 5:28 PM, Ronnie Sahlberg ronniesahlb...@gmail.com wrote: We need to support SG_IO from the synchronous iscsi_ioctl() since scsi-block uses this to do an INQ to the device to discover its properties This patch makes scsi-block work with iscsi. Signed-off

Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend

path, or the volume path should be in the URI path, not both. The other part should be a URI parameter. I'd really expect us to use: gluster:///volname/image?transport=unixsockpath=/path/to/unix/sock +1 ronnie sahlberg

[Qemu-devel] [PATCH] iSCSI: remove the now obsolete call to qemu_notify_event()

Paolo, List Please find a trivial patch to iscsi that removes the call to qemu_notify_event() We do not need to call this any more since a recent patch that made qemu_aio_set_fd_handler() and friends invoke this call automatically when required. regards ronnie sahlberg

[Qemu-devel] [PATCH] iSCSI: We dont need to explicitely call qemu_notify_event() any more

We no longer need to explicitely call qemu_notify_event() any more since this is now done automatically any time the filehandles we listen to change. Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- block/iscsi.c |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff

[Qemu-devel] [PATCH] iSCSI: Add support for SG_IO to iscsi_ioctl()

Paolo, List Please find a small patch that adds support for SG_IO to the synchronous iscsi_ioctl() function. This is needed to make scsi-block work with iscsi. regards ronnie sahlberg

[Qemu-devel] [PATCH] iSCSI: We need to support SG_IO also from iscsi_ioctl()

We need to support SG_IO from the synchronous iscsi_ioctl() since scsi-block uses this to do an INQ to the device to discover its properties This patch makes scsi-block work with iscsi. Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- block/iscsi.c | 20 +++- 1 files

Re: [Qemu-devel] [PATCH v2 1/3] net: asynchronous send/receive infrastructure for net/socket.c

In net_socket_update_fd_handler() shouldnt you call qemu_notify_event() if any of the handlers have changed from NULL to non-NULL ? or else it might take a while before the change takes effect. regards ronnie sahlberg On Wed, Aug 22, 2012 at 1:52 AM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com

Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences / races between task completion and abort

On Mon, Aug 20, 2012 at 6:12 PM, Stefan Priebe - Profihost AG s.pri...@profihost.ag wrote: Hi Ronnie, Am 20.08.2012 10:08, schrieb Paolo Bonzini: That's because the big QEMU lock is held by the thread that called qemu_aio_cancel. and i also see no cancellation message in kernel log.

[Qemu-devel] [PATCH] iSCSI: Add support for SG_IO to bdrv_ioctl()/iscsi_ioctl()

. By adding support for SG_IO to iscsi_ioctl() this makes scsi-block and scsi-disk work too. Since scsi-block/scsi-disk never worked with iscsi, and only scsi-generic worked, this is not a new regression. So whether this should go in now or wait until post 1.2 is for your disgression. regards ronnie

[Qemu-devel] [PATCH] iSCSI: Add support for SG_IO in bdrv_ioctl()

We need to support SG_IO in the synchronous bdrv_ioctl() since this is used by scsi-block Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com --- block/iscsi.c | 109 - 1 files changed, 108 insertions(+), 1 deletions(-) diff --git

Re: [Qemu-devel] [PATCH 2/2] ISCSI: Force scsi-generic for MMC with blank disks

On Sun, Aug 19, 2012 at 7:58 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 17/08/2012 04:36, Ronnie Sahlberg ha scritto: There is no bdrv_* API for the commands for burning a blank MMC disk so when iSCSI LUNs are specified and the LUN is a MMC device with 0 available blocks. This is a blank

Re: [Qemu-devel] [PATCH 2/2] ISCSI: Force scsi-generic for MMC with blank disks

regards ronnie sahlberg On Sun, Aug 19, 2012 at 8:02 AM, ronnie sahlberg ronniesahlb...@gmail.com wrote: On Sun, Aug 19, 2012 at 7:58 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 17/08/2012 04:36, Ronnie Sahlberg ha scritto: There is no bdrv_* API for the commands for burning a blank MMC disk

Re: [Qemu-devel] [PATCH 1/2] ISCSI: Set number of blocks to 0 for blank CDROM devices

On Sun, Aug 19, 2012 at 7:57 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 17/08/2012 04:36, Ronnie Sahlberg ha scritto: The number of blocks of the device is used to compute the device size in bdrv_getlength()/iscsi_getlength(). For MMC devices, the ReturnedLogicalBlockAddress

  1   2   3   >