Hello Christoph!
On 10/10/2012 01:39 AM, Christoph Hellwig wrote:
>> +static int vhost_blk_req_submit(struct vhost_blk_req *req, struct file
>> *file)
>> +{
>> +
>> +struct inode *inode = file->f_mapping->host;
>> +struct block_device *bdev = inode->i_bdev;
>> +int ret;
>
> Please ju
Rusty Russell wrote:
> I don't think it'll be that bad; reset clears the device to unknown,
> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from
> unknown->modern mode, and anything else is bad (I prefer being strict so
> we catch bad implementations from the beginning).
Will that w
Hi,
>> Why use two bars for this? You can put them into one mmio bar, together
>> with the msi-x vector table and PBA. Of course a pci capability
>> describing the location is helpful for that ;)
>
> You don't need a capability. You can also just add a "config offset"
> field to the register
> +static int vhost_blk_req_submit(struct vhost_blk_req *req, struct file *file)
> +{
> +
> + struct inode *inode = file->f_mapping->host;
> + struct block_device *bdev = inode->i_bdev;
> + int ret;
Please just pass the block_device directly instead of a file struct.
> +
> + ret =
Gerd Hoffmann writes:
> Hi,
>
>>> Well, we also want to clean up the registers, so how about:
>>>
>>> BAR0: legacy, as is. If you access this, don't use the others.
>
> Ok.
>
>>> BAR1: new format virtio-pci layout. If you use this, don't use BAR0.
>>> BAR2: virtio-cfg. If you use this, don't
On Thu, 27 Sep 2012 09:59:33 +0930
Rusty Russell wrote:
> Hi all,
>
> I've had several requests for a more formal approach to the
> virtio draft spec, and (after some soul-searching) I'd like to try that.
>
> The proposal is to use OASIS as the standards body, as it's
> fairly light
Avi Kivity writes:
> On 10/09/2012 05:16 AM, Rusty Russell wrote:
>> Anthony Liguori writes:
>>> We'll never remove legacy so we shouldn't plan on it. There are
>>> literally hundreds of thousands of VMs out there with the current virtio
>>> drivers installed in them. We'll be supporting them
Rusty Russell writes:
> Anthony Liguori writes:
>> We'll never remove legacy so we shouldn't plan on it. There are
>> literally hundreds of thousands of VMs out there with the current virtio
>> drivers installed in them. We'll be supporting them for a very, very
>> long time :-)
>
> You will b
On 10/09/2012 05:16 AM, Rusty Russell wrote:
> Anthony Liguori writes:
>> We'll never remove legacy so we shouldn't plan on it. There are
>> literally hundreds of thousands of VMs out there with the current virtio
>> drivers installed in them. We'll be supporting them for a very, very
>> long ti
vhost-blk is an in-kernel virito-blk device accelerator.
Due to lack of proper in-kernel AIO interface, this version converts
guest's I/O request to bio and use submit_bio() to submit I/O directly.
So this version any supports raw block device as guest's disk image,
e.g. /dev/sda, /dev/ram0. We ca
Il 09/10/2012 06:59, Rusty Russell ha scritto:
> Paolo Bonzini writes:
>> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
>>> said to Anthony, the best rules are "always" and "never", so I'd really
>>> rather not have to gra
11 matches
Mail list logo
