[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-virtualization
Subject:    [kvm-devel] [PATCH RFC 3/3] virtio infrastructure: example
From:       rusty () rustcorp ! com ! au (Rusty Russell)
Date:       2007-05-31 16:39:37
Message-ID: 1180654765.10999.6.camel () localhost ! localdomain
[Download RAW message or body]

On Thu, 2007-05-31 at 14:57 +0200, Carsten Otte wrote:
> Rusty Russell wrote:
> > Example block driver using virtio.
> > 
> > The block driver uses outbufs with sg[0] being the request information
> > (struct virtio_blk_outhdr) with the type, sector and inbuf id.  For a
> > write, the rest of the sg will contain the data to be written.
> > 
> > The first segment of the inbuf is a result code (struct
> > virtio_blk_inhdr).  For a read, the rest of the sg points to the input
> > buffer.
> > 
> > TODO:
> > 	1) Ordered tag support.
> Implementing a do_request function has quite a few disadvantages over 
> hooking into q->make_request_fn. This way, we have the device plug 
> (latency), request merging, and I/O scheduling inside the guest.

Now my lack of block-layer knowledge is showing.  I would have thought
that if we want to do things like ionice(1) to work, we have to do some
guest scheduling or pass that information down to the host.

> It seems preferable to do that in the host, especially when requests 
> of multiple guests end up on the same physical media (shared access, 
> or partitioned).

What's the overhead in doing both?

Rusty.

[prev in list] [next in list] [prev in thread] [next in thread]