On Thu, Aug 20, 2009 at 04:38:17PM +0300, Michael S. Tsirkin wrote:
On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote:
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 19, 2009 at 05:27:07PM +0200, Arnd Bergmann wrote:
On Wednesday 19 August 2009, Michael S.
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 19, 2009 at 05:27:07PM +0200, Arnd Bergmann wrote:
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote:
On Wednesday 19 August 2009, Michael S. Tsirkin
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote:
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
It doesn't matter that I don't want this: allowing 1 process corrupt
another's memory is a security issue. Once you get
On Thu, Aug 20, 2009 at 04:31:36PM +0200, Arnd Bergmann wrote:
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote:
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
It doesn't matter that I don't want this: allowing 1
On Thursday 20 August 2009, Michael S. Tsirkin wrote:
The errors from the socket (or chardev, as that was the
start of the argument) should still fit into the categories
that I mentioned, either they can be handled by the host
kernel, or they are fatal.
Hmm, are you sure? Imagine a
On Sunday 16 August 2009, Michael S. Tsirkin wrote:
On Fri, Aug 14, 2009 at 01:40:36PM +0200, Arnd Bergmann wrote:
* most of the transports are sockets, tap uses a character device.
This could be dealt with by having both a struct socket * in
struct vhost_net *and* a struct file *,
On Wed, Aug 19, 2009 at 11:04:50AM +0200, Arnd Bergmann wrote:
On Sunday 16 August 2009, Michael S. Tsirkin wrote:
On Fri, Aug 14, 2009 at 01:40:36PM +0200, Arnd Bergmann wrote:
* most of the transports are sockets, tap uses a character device.
This could be dealt with by having
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
Maybe we could instead extend the 'splice' system call to work on a
vhost_net file descriptor. If we do that, we can put the access back
into a user thread (or two) that stays in splice indefinetely
An issue with exposing internal
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote:
On Wednesday 19 August 2009, Michael S. Tsirkin wrote:
Leaving that aside for now, you could replace VHOST_NET_SET_SOCKET,
VHOST_SET_OWNER, VHOST_RESET_OWNER
SET/RESET
On Fri, Aug 14, 2009 at 01:40:36PM +0200, Arnd Bergmann wrote:
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest
On Thursday 13 August 2009, Michael S. Tsirkin wrote:
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
AFAICT, you have addressed all my comments,
What it is: vhost net is a character device that can be used to reduce
the number of system calls involved in virtio networking.
Existing virtio net code is used in the guest without modification.
There's similarity with vringfd, with some differences and reduced scope
- uses eventfd for
12 matches
Mail list logo
