[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and
From: |
Gonglei (Arei) |
Subject: |
Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation |
Date: |
Mon, 31 Oct 2016 02:52:32 +0000 |
> From: Halil Pasic [mailto:address@hidden
> 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>,
> address@hidden <address_space_memory>,
> address@hidden, address@hidden,
> address@hidden, address@hidden)
> 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
- [Qemu-devel] [PATCH v9 12/12] virtio-crypto: add myself as virtio-crypto and cryptodev backends maintainer, (continued)
- [Qemu-devel] [PATCH v9 12/12] virtio-crypto: add myself as virtio-crypto and cryptodev backends maintainer, Gonglei, 2016/10/20
- [Qemu-devel] [PATCH v9 10/12] cryptodev: introduce an unified wrapper for crypto operation, Gonglei, 2016/10/20
- [Qemu-devel] [PATCH v9 05/12] virtio-crypto: add virtio crypto device emulation, Gonglei, 2016/10/20
- Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation, no-reply, 2016/10/20
- Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation, Gonglei (Arei), 2016/10/25
- Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation, Halil Pasic, 2016/10/30
- Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation,
Gonglei (Arei) <=