similar to: [PATCH] vhost: add vsock compat ioctl

On Tue, Apr 16, 2019 at 10:19:47PM +0200, Arnd Bergmann wrote: > Each of these drivers has a copy of the same trivial helper function to > convert the pointer argument and then call the native ioctl handler. > > We now have a generic implementation of that, so use it. > > Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> > Reviewed-by: Jarkko Sakkinen

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Signed-off-by: Arnd Bergmann <arnd at arndb.de> --- drivers/char/ppdev.c | 12 +--------- drivers/char/tpm/tpm_vtpm_proxy.c | 12 +--------- drivers/firewire/core-cdev.c | 12

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Acked-by: Michael S. Tsirkin <mst at redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com>

On Wed, Mar 14, 2018 at 02:36:25PM -0700, Sonny Rao wrote: > This will allow usage of vsock from 32-bit binaries on a 64-bit > kernel. > > Signed-off-by: Sonny Rao <sonnyrao at chromium.org> > --- > drivers/vhost/vsock.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> -------------- next part

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com>

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg at mellanox.com>

VM sockets vhost transport implementation. This module runs in host kernel. Signed-off-by: Asias He <asias at redhat.com> --- drivers/vhost/vsock.c | 534 ++++++++++++++++++++++++++++++++++++++++++++++++++ drivers/vhost/vsock.h | 4 + 2 files changed, 538 insertions(+) create mode 100644 drivers/vhost/vsock.c create mode 100644 drivers/vhost/vsock.h diff --git a/drivers/vhost/vsock.c

From: Asias He <asias at redhat.com> VM sockets vhost transport implementation. This module runs in host kernel. Signed-off-by: Asias He <asias at redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> --- v3: * Remove unneeded variable used to store return value (Fengguang Wu <fengguang.wu at intel.com> and Julia Lawall <julia.lawall at

Stefan Hajnoczi <stefanha at redhat.com> writes: > From: Asias He <asias at redhat.com> > > VM sockets vhost transport implementation. This module runs in host > kernel. As per previous checkpatch comments. > > Signed-off-by: Asias He <asias at redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> > --- > v3: > * Remove

Stefan Hajnoczi <stefanha at redhat.com> writes: > From: Asias He <asias at redhat.com> > > VM sockets vhost transport implementation. This module runs in host > kernel. As per previous checkpatch comments. > > Signed-off-by: Asias He <asias at redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> > --- > v3: > * Remove

On Thu, Jun 27, 2013 at 04:00:03PM +0800, Asias He wrote: > VM sockets vhost transport implementation. This module runs in host > kernel. > > Signed-off-by: Asias He <asias at redhat.com> Has any thought been given to how this affects migration? I don't see any API for an application to move to a different host and reconnect to a running vsock in guest. I think we could

On Thu, Jun 27, 2013 at 04:00:03PM +0800, Asias He wrote: > VM sockets vhost transport implementation. This module runs in host > kernel. > > Signed-off-by: Asias He <asias at redhat.com> Has any thought been given to how this affects migration? I don't see any API for an application to move to a different host and reconnect to a running vsock in guest. I think we could

On Sun, Mar 15, 2015 at 1:33 PM, Sonny Rajagopalan < sonny.rajagopalan at gmail.com> wrote: > Yes, I think the dial does get executed (sonny calling outbound > 202-555-1212): > > core set verbose 3 > Console verbose was OFF and is now 3. > -- Executing [912025551212 at from-internal:1] > Log("PJSIP/sonny-00000031", "NOTICE, Dialing out from

I have a working Asterisk 13.1.0 running, and I am trying to configure a SIP trunk for outbound and inbound calling, and a DID for the Asterisk server, which is used for incoming calls from PSTN. I configured my SIP.US trunks (showing one gateway, gw1, here for brevity, have two: gw1 & gw2, which are both configured on my end): [sonnyGW1] type=registration transport=transport-udp

On Sun, Mar 15, 2015 at 5:56 PM, Sonny Rajagopalan <sonny.rajagopalan at gmail.com> wrote: > George, > > I have the detailed log below. (Resending after trimming the email to 40KB.) > > The sequence below just repeats ad-nauseam. Is this a SIP trunk issue? > > Thanks! > I don't see anything obvious. The registration works though, right? You might want to compare

George, I have the detailed log below. (Resending after trimming the email to 40KB.) The sequence below just repeats ad-nauseam. Is this a SIP trunk issue? Thanks! --------------------- Transmitting SIP request (885 bytes) to UDP:65.254.44.194:5060 ---> INVITE sip:12025551212 at 65.254.44.194:5060 SIP/2.0 Via: SIP/2.0/UDP 18.18.19.123:5060

On Sun, Mar 15, 2015 at 10:34 AM, Sonny Rajagopalan < sonny.rajagopalan at gmail.com> wrote: > That was the issue, thanks. I now am able to get the caller ringing on an > outbound call, but an external phone number (E164) I am dialing does not > ring. > Any error messages? If you set 'core set verbose 3' and try it, does the Dial get executed? > > On Sun, Mar

Yes, I think the dial does get executed (sonny calling outbound 202-555-1212): core set verbose 3 Console verbose was OFF and is now 3. -- Executing [912025551212 at from-internal:1] Log("PJSIP/sonny-00000031", "NOTICE, Dialing out from "" <sonny> to 12025551212 through fromgw") in new stack [Mar 15 19:27:06] NOTICE[16648][C-00000022]: Ext. 912025551212:1 @

On Sun, Mar 15, 2015 at 8:32 AM, Sonny Rajagopalan < sonny.rajagopalan at gmail.com> wrote: > I have setup my Asterisk 13.1.0 server with PJSIP on AWS/EC2. My basic > configuration works, and I am connected to a SIP trunk using SIP.US, and > have set up my inbound calling which works correctly (when I call my PBX > DID, the call does come into my PBX network). > > The

On Wed, Feb 17, 2016 at 8:56 AM, Sonny Rajagopalan < sonny.rajagopalan at gmail.com> wrote: > I made some progress. The first thing I have realized is that it is my > Twilio configuration in pjsip_wizard.conf that was killing me. I have since > removed that entire file from /etc/asterisk and I am able to make > "from-internal" context calls (i.e., calls that do not