> From: Halil Pasic [mailto:pa...@linux.vnet.ibm.com] > Sent: Monday, October 31, 2016 4:00 AM > Subject: Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework > and device emulation > > > > On 10/20/2016 01:45 PM, Gonglei wrote: > > The front-end linux kernel driver (Experimental at present) is publicly > accessible from: > > > > https://github.com/gongleiarei/virtio-crypto-linux-driver.git > > Hi! > > I'm very interested in making sure this work for the s390x architecture > too. So to familiarize with the stuff I wanted to give it a spin on > x86_64 and then transit to s390x and look for possible issues. > Cool.
> Unfortunately I encountered a problem already on x86_64, more precisely > the guest hangs in virtio_crypto_alg_ablkcipher_init_session after the > kick. But before I start explaining in detail let me ask you: what are > your plans for the linux kernel driver? I used the most current version > from your github, but also tried to look for patches on mailing lists > and I have found none. I haven't submit the virtio-crypto driver to the mailing list yet cause I wanted to the patches on the QEMU side can be merged firstly, and then focus to the frontend driver. > IMHO the problem causing my hang is in the kernel > module. But I do not know here am I supposed to comment on it -- so I'm > commenting here. Furthermore your kernel module currently do not seem to > care about endianness which is bad for s390x. > That's true. > The hangs basically boils down to the following: after the kick in > virtio_crypto_alg_ablkcipher_init_session we reach the point (in QEMU) > where we want to translate the address for the third descriptor, the one > which designates a buffer for the virtio_crypto_session_input. My > backtrace looks like this: > > > #0 address_space_translate (as=<optimized out>, > as@entry=0x55555607d700 <address_space_memory>, > addr=addr@entry=71468256835928, xlat=xlat@entry=0x7fffef4dc1a0, > plen=plen@entry=0x7fffef4dc198, is_write=is_write@entry=true) > at /home/pasic/devel/qemu/exec.c:481 > #1 0x000055555575ef19 in address_space_map (as=0x55555607d700 > <address_space_memory>, addr=71468256835928, plen=<optimized out>, > is_write=<optimized out>) at /home/pasic/devel/qemu/exec.c:2927 > #2 0x00005555557e5d00 in virtqueue_map_desc (vdev=0x555557d80de0, > p_num_sg=0x7fffef4dc2bc, addr=0x7fffef4dc2f0, iov=0x7fffef4de300, > max_num_sg=1022, is_write=true, pa=71468256835928, sz=16) > at /home/pasic/devel/qemu/hw/virtio/virtio.c:558 > #3 0x00005555557e5f86 in virtqueue_pop (vq=0x7fffef4dc2c0, > sz=93825003936576) at /home/pasic/devel/qemu/hw/virtio/virtio.c:717 > #4 0x00005555557ed80b in virtio_crypto_handle_ctrl (vdev=<optimized out>, > vq=0x7fffeec3e090) at /home/pasic/devel/qemu/hw/virtio/virtio-crypto.c:218 > > Now the first suspicious thing I see is that address_space_translate > returns a pointer to the memory region io_mem_unassigned. Next thing > happening is that we take the !memory_access_is_direct(mr, is_write) > branch in address_space_map and return NULL at line 2932 which however > makes virtqueue_map_desc report "qemu-system-x86_64: virtio: bogus > descriptor or out of resources" and return with false. Then pop returns > null too and spins virtio_crypto_alg_ablkcipher_init_session till the > end of time waiting for the answer. > It seems that the frontend driver passed a invalid gpa to the QEMU side, The Qemu side will invokes virtio_error() to notify the guest to reset the device. > Now if I change the code so that the virtio_crypto_session_input > instance's backing memory is allocated with kzalloc(sizeof(*input), > GFP_DMA|GFP_NOIO) of allocating the on the stack things start working > for me. I'm not too deep into this yet, so please forgive me if > I'm a bit vague. > Good, maybe you find a bug of the frontend driver. Using stack memory might not be a good idea ;) > I was testing with tcrypt mode=500 instead of cryptodev-linux but I > guess that should be irrelevant. > I think so as well. > Looking forward to your answer. > > Halil > Regards, -Gonglei --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
