[PATCH 1/2] virtio_pci_modern: fix complaint by sparse

drivers/virtio/virtio_pci_modern.c:66:40: warning: incorrect type in argument 2 (different base types) drivers/virtio/virtio_pci_modern.c:66:40:expected unsigned int [noderef] [usertype] *addr drivers/virtio/virtio_pci_modern.c:66:40:got restricted __le32 [noderef] [usertype] *lo

[PATCH 0/2] virtio: fix complaint by sparse

I found some warnings reported by sparse in the virtio code when I checked virtio-crypto's driver stuff. Let's fix them. Gonglei (2): virtio_pci_modern: fix complaint by sparse virtio_ring: fix complaint by sparse drivers/virtio/virtio_pci_modern.c | 8 drivers/virtio/virtio_ring.c

[PATCH 2/2] virtio_ring: fix complaint by sparse

# make C=2 CF="-D__CHECK_ENDIAN__" ./drivers/virtio/ drivers/virtio/virtio_ring.c:423:19: warning: incorrect type in assignment (different base types) drivers/virtio/virtio_ring.c:423:19:expected unsigned int [unsigned] [assigned] i drivers/virtio/virtio_ring.c:423:19:got restricted

[RFC LINUX PATCH 1/2] virtio_ring: Do not call dma_map_page if sg is already mapped.

If sg is already dma mapped, do not call dma_map_page() in vring_map_one_sg(). In case of rpmsg, rpmsg uses dma_alloc_coherent() to allocate memory to share with the remote. There is no pages setup in dma_alloc_coherent(). In this case, we cannot convert the virtual address back to the physical

[RFC LINUX PATCH 2/2] rpmsg: DMA map sgs passed to virtio

From: "Edgar E. Iglesias" As rpmsg uses dma_alloc_coherent() to allocate memory to shared with the remote. Virtio ring requires the shared buffers to be passed as sg struct. As the memory has already been mapped, and we cannot convert the virtual address got from

[RFC LINUX PATCH 0/2] Virtio ring works with DMA coherent memory

RPMsg uses dma_alloc_coherent() to allocate memory to shared with the remote. In this case, as there is no pages setup in the dma_alloc_coherent(), we cannot get the physical address back from the virtual address, and thus, we can set the sg_dma_addr to store the DMA address and mark it already

Re: [PATCH 1/1] sched: provide common cpu_relax_yield definition

On Wed, Nov 16, 2016 at 01:23:05PM +0100, Christian Borntraeger wrote: > No need to duplicate the same define everywhere. Since > the only user is stop-machine and the only provider is > s390, we can use a default implementation of cpu_relax_yield > in sched.h. > > Suggested-by: Russell King

Re: [PATCH] crypto: add virtio-crypto driver

on 2016/11/17 23:55, Benedetto, Salvatore wrote: > Hi Gonglei, > > ... >> + >> +static int virtio_crypto_alg_ablkcipher_init_session( >> +struct virtio_crypto_ablkcipher_ctx *ctx, >> +int alg, const uint8_t *key, >> +unsigned int keylen, >> +int

RE: [PATCH] crypto: add virtio-crypto driver

Hi Gonglei, ... > + > +static int virtio_crypto_alg_ablkcipher_init_session( > + struct virtio_crypto_ablkcipher_ctx *ctx, > + int alg, const uint8_t *key, > + unsigned int keylen, > + int encrypt) > +{ > + struct scatterlist outhdr, key_sg,

Re: [GIT PULL v2 1/5] processor.h: introduce cpu_relax_yield

On Tue, Nov 15, 2016 at 02:19:53PM +0100, Christian Borntraeger wrote: > On 11/15/2016 01:30 PM, Russell King - ARM Linux wrote: > > On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote: > >> For spinning loops people do often use barrier() or cpu_relax(). > >> For most

RE: [PATCH] crypto: add virtio-crypto driver

Hi Michael, May I should convert all __virtio32/64 to le32/64 in virtio_crypto.h ? > +#define VIRTIO_CRYPTO_OPCODE(service, op) (((service) << 8) | (op)) > + > +struct virtio_crypto_ctrl_header { > +#define VIRTIO_CRYPTO_CIPHER_CREATE_SESSION \ > +

[PATCH] crypto: add virtio-crypto driver

This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by

Re: [GIT PULL v2 1/5] processor.h: introduce cpu_relax_yield

On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote: > For spinning loops people do often use barrier() or cpu_relax(). > For most architectures cpu_relax and barrier are the same, but on > some architectures cpu_relax can add some latency. > For example on power,sparc64 and arc,

Re: [PATCH v2 34/37] docs: fix locations of several documents that got moved

On 11/02/2016 05:31 AM, Pavel Machek wrote: > Hi! > >>> Dunno, but kernel-parameters.txt was already quite long... for a file >>> that is referenced quite often. Adding admin-guide/ into the path does >>> not really help. >> >> The big string name starts with Documentation/ :) There are some

SR-PCIM support in Xen

Hi All, Is there any support for software mailbox communication between PF and VF driver in Xen ? As per the following link: http://www-archive.xenproject.org/files/xensummitboston08/Xen-SR-IOV.pdf It says that for software based virtual mailbox we require SR-PCIM support. So for this purpose