All of lore.kernel.org
 help / color / mirror / Atom feed
From: Asias He <asias@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] vhost-blk: Add vhost-blk support v2
Date: Wed, 24 Oct 2012 11:08:38 +0800	[thread overview]
Message-ID: <50875BB6.90809@redhat.com> (raw)
In-Reply-To: <87mwzehwzi.fsf@rustcorp.com.au>

On 10/23/2012 08:07 AM, Rusty Russell wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>> On Thu, Oct 18, 2012 at 02:50:56PM +1030, Rusty Russell wrote:
>>> Asias He <asias@redhat.com> writes:
>>>>>> +#define BLK_HDR	0
>>>>>
>>>>> What's this for, exactly? Please add a comment.
>>>>
>>>> The block headr is in the first and separate buffer.
>>>
>>> Please don't assume this!  We're trying to fix all the assumptions in
>>> qemu at the moment.
>>>
>>> vhost_net handles this correctly, taking bytes off the descriptor chain
>>> as required.
>>>
>>> Thanks,
>>> Rusty.
>>
>> BTW are we agreed on the spec update that makes cmd 32 bytes?
> 
> vhost-blk doesn't handle scsi requests, does it?

No, it doesn't handle scsi requests currently.

> 
> But since we're forced to use a feature bit, we could just put the cmd
> size in explicitly.  Though Paulo seems convinced that 32 is always
> sufficient.  Whoever implements it gets to decide...
> 
> Here's my TODO list:
> 1) Create qemu helpers to efficiently handle iovecs.
> 2) Switch all the qemu devices to use them.
> 3) ... except a special hack for virtio-blk in old-layout mode.
> 4) Implement pci capability layout RFC for qemu.
>    - Detect whether guest uses capabilities.
>    - Device config in new mode is le.
>    - Add strict checking mode for extra compliance checks?
> 5) Add explicit size-based accessors to virtio_config in kernel.
> 6) Update pci capability RFC patches for linux to match.
>    - Use explicit accessors to allow for endian conversion.
> 6) Push virtio torture patch to test variable boundaries.
> 7) Update spec.
> 
> That should keep me amused for a while...
> 
> Cheers,
> Rusty.
> 


-- 
Asias

  reply	other threads:[~2012-10-24  3:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09  8:05 [PATCH] vhost-blk: Add vhost-blk support v2 Asias He
2012-10-09 17:39 ` Christoph Hellwig
2012-10-09 17:39 ` Christoph Hellwig
2012-10-10  2:27   ` Asias He
2012-10-11 12:41 ` Michael S. Tsirkin
2012-10-12 13:18   ` Asias He
2012-10-13 22:58     ` Michael S. Tsirkin
2012-10-18  4:20     ` Rusty Russell
2012-10-18  6:30       ` Michael S. Tsirkin
2012-10-23  0:07         ` Rusty Russell
2012-10-24  3:08           ` Asias He [this message]
2012-10-19  6:44       ` Asias He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50875BB6.90809@redhat.com \
    --to=asias@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.