RE: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework and device emulation

["Gonglei (Arei)" <arei.gonglei@huawei.com>]

> -----Original Message-----
> From: Halil Pasic [mailto:pasic@linux.vnet.ibm.com]
> Sent: Thursday, November 03, 2016 1:35 AM
> Subject: Re: [Qemu-devel] [PATCH v9 00/12] virtio-crypto: introduce framework
> and device emulation
> 
> 
> 
> On 10/31/2016 03:52 AM, Gonglei (Arei) wrote:
> >> > 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.
> >
> 
> That is fine and the QEMU stuff does look good :). I'm still curious
> about your road map that is what should I expect on the kernel side
> and when? You could also cc me ;) when sending to the list.
> 
Currently a project of my company eats my time, I'll address it in the
following two weeks I guess. 

Sure, I'll cc you when I sending to the mailing list. :)

> >> > 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.
> >
> 
> For the sake of the experiment I have reworked
> virtio_crypto_alg_ablkcipher_init_session so that id does care
> about the endianness of the guest. With that the functions seems
> to work on s390x (but of course the next byte order problem warrants
> that encryption/decryption does not work yet). It is not beautiful
> but I can give you a patch if you want.
> 
Sure, Pls. I can merge it with your sign.


Thanks,
-Gonglei

> >> > 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.
> >
> 
> I did not say previously but I have checked and the gpa is good, that
> is it has a correct offset in respect to ctrl's gpa (the next variable
> on stack, which is the previous desc.addr used read only) which is good.
> Furthermore the issue seems to be platform dependent as I do not see this
> on s390x.
> 
> >> > 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 ;)
> >
> 
> Yeah, as I said, can't say (that is my understanding too shallow).
> 
> Cheers,
> Halil