qemu-devel
[Top][All Lists]
Advanced

[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: Halil Pasic
Subject: Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation
Date: Sun, 30 Oct 2016 21:00:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


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.

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. 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. 

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.

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.

I was testing with tcrypt mode=500 instead of cryptodev-linux but I
guess that should be irrelevant.

Looking forward to your answer.

Halil


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]