similar to: [PATCH RFC 1/3] virtio infrastructure

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

This is a subject that came up in the virtio BOF session at OLS. I decided to go forward and implement something that I like, based on the latest virtio proposal at the time, which was draft III. It's not a drop-in replacement, because it's missing a host implementation. I first started my own, which is not done yet, but wanted to do one for lguest and one for emulated PCI next. It's

On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote: > On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > [...] > > > and some > > > other call path is allocating while holding the lock. But you seem to be > > > right and > > > leak_balloon > > > tell_host >

On Mon, Oct 02, 2017 at 04:19:00PM +0200, Michal Hocko wrote: > On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > [...] > > > and some > > > other call path is allocating while holding the lock. But you seem to be > > > right and > > > leak_balloon > > > tell_host >

On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > On Mon 02-10-17 20:33:52, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > [Hmm, I do not see the original patch which this has been a reply to] > > > > urbl.hostedemail.com and b.barracudacentral.org blocked my IP address, > > and the rest are "Recipient address rejected: Greylisted" or

On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: > On Mon 02-10-17 20:33:52, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > [Hmm, I do not see the original patch which this has been a reply to] > > > > urbl.hostedemail.com and b.barracudacentral.org blocked my IP address, > > and the rest are "Recipient address rejected: Greylisted" or

On 04/14/2017 01:08 AM, Michael S. Tsirkin wrote: > On Thu, Apr 13, 2017 at 05:35:08PM +0800, Wei Wang wrote: >> Add a new vq, miscq, to handle miscellaneous requests between the device >> and the driver. >> >> This patch implemnts the VIRTIO_BALLOON_MISCQ_INQUIRE_UNUSED_PAGES > implements > >> request sent from the device. > Commands are sent from host

On Mon 02-10-17 17:11:55, Michael S. Tsirkin wrote: > On Mon, Oct 02, 2017 at 01:50:35PM +0200, Michal Hocko wrote: [...] > > and some > > other call path is allocating while holding the lock. But you seem to be > > right and > > leak_balloon > > tell_host > > virtqueue_add_outbuf > > virtqueue_add > > > > can do GFP_KERNEL

Hey Rusty, In this version: - Assume only one inbuf; no input buffering for ports - Remove the START/END delimiters for outgoing buffers - Remove the header that was sent along with each buffer - Remove unused buffers in the vqs at port remove time - Send a guest port open message to the host when a console port is attached - Remove cached buffers when ports are closed / disconnected - Send

Hey Rusty, In this version: - Assume only one inbuf; no input buffering for ports - Remove the START/END delimiters for outgoing buffers - Remove the header that was sent along with each buffer - Remove unused buffers in the vqs at port remove time - Send a guest port open message to the host when a console port is attached - Remove cached buffers when ports are closed / disconnected - Send

On Thu, Apr 27, 2017 at 02:33:44PM +0800, Wei Wang wrote: > On 04/14/2017 01:08 AM, Michael S. Tsirkin wrote: > > On Thu, Apr 13, 2017 at 05:35:08PM +0800, Wei Wang wrote: > > > Add a new vq, miscq, to handle miscellaneous requests between the device > > > and the driver. > > > > > > This patch implemnts the VIRTIO_BALLOON_MISCQ_INQUIRE_UNUSED_PAGES

On Thu, Apr 27, 2017 at 02:33:44PM +0800, Wei Wang wrote: > On 04/14/2017 01:08 AM, Michael S. Tsirkin wrote: > > On Thu, Apr 13, 2017 at 05:35:08PM +0800, Wei Wang wrote: > > > Add a new vq, miscq, to handle miscellaneous requests between the device > > > and the driver. > > > > > > This patch implemnts the VIRTIO_BALLOON_MISCQ_INQUIRE_UNUSED_PAGES

On Thu, Apr 13, 2017 at 05:35:08PM +0800, Wei Wang wrote: > Add a new vq, miscq, to handle miscellaneous requests between the device > and the driver. > > This patch implemnts the VIRTIO_BALLOON_MISCQ_INQUIRE_UNUSED_PAGES implements > request sent from the device. Commands are sent from host and handled on guest. In fact how is this so different from stats? How about reusing the

On Thu, Apr 13, 2017 at 05:35:08PM +0800, Wei Wang wrote: > Add a new vq, miscq, to handle miscellaneous requests between the device > and the driver. > > This patch implemnts the VIRTIO_BALLOON_MISCQ_INQUIRE_UNUSED_PAGES implements > request sent from the device. Commands are sent from host and handled on guest. In fact how is this so different from stats? How about reusing the

Hey Rusty, This is a respin of my patches on top of the series you posted. I've taken the liberty to modify your patches for style consistency and comments where needed, keeping the authorship info intact. I've had to update a few of your patches for functional changes, I've changed the authorship info on those patches. The (only) major functional change is to have a list for ports

Hey Rusty, This is a respin of my patches on top of the series you posted. I've taken the liberty to modify your patches for style consistency and comments where needed, keeping the authorship info intact. I've had to update a few of your patches for functional changes, I've changed the authorship info on those patches. The (only) major functional change is to have a list for ports

Hey Rusty, This series adds support for generic ports with each port getting two vqs: one for input and one for output. The host notifies us via the config space of the max. number of ports that can be added for a particular device. As a result of that change, the buffer management for find_readbufs and send_bufs is moved to the vqs. Only one outbuf per port is used so we bide away some time in