On 06/02/2011 02:56 PM, Michael S. Tsirkin wrote:
> >
> >Right. If there are two buffers of variable length there
> >should be two add_buf calls.
>
> No. The guest should be free to use one large continuous buffer of
> size N, of N buffers of size 1.
That's exactly what I was saying.
I'm
On Thu, Jun 02, 2011 at 02:02:52PM +0200, Paolo Bonzini wrote:
> On 06/02/2011 01:41 PM, Michael S. Tsirkin wrote:
> >Now to our problem:
> >As far as I can tell there are two input buffers in each request: sense
> >and data. Right?
> >
> >If sense is fixed length, we can simply put it first, have
On Thu, Jun 02, 2011 at 02:42:51PM +0300, Avi Kivity wrote:
> On 06/02/2011 01:42 PM, Michael S. Tsirkin wrote:
> >On Wed, Jun 01, 2011 at 05:51:54PM +0300, Avi Kivity wrote:
> >> On 06/01/2011 05:36 PM, Michael S. Tsirkin wrote:
> >> >>
> >> >> So, if I am going to give this liberty with buff
On 06/02/2011 01:41 PM, Michael S. Tsirkin wrote:
Now to our problem:
As far as I can tell there are two input buffers in each request: sense
and data. Right?
If sense is fixed length, we can simply put it first, have device write
sense then data. This does not seem too limiting, if you want a
On 06/02/2011 01:42 PM, Michael S. Tsirkin wrote:
On Wed, Jun 01, 2011 at 05:51:54PM +0300, Avi Kivity wrote:
> On 06/01/2011 05:36 PM, Michael S. Tsirkin wrote:
> >>
> >> So, if I am going to give this liberty with buffers to the driver, I
> >> _have_ to keep the size information. Other
BTW, I think Cc the virtio mailing list
in the next version is a good idea.
On Wed, Jun 01, 2011 at 05:59:28PM +0200, Paolo Bonzini wrote:
> On 06/01/2011 04:36 PM, Michael S. Tsirkin wrote:
> >Ah, I think I understand now. Both sense and data have in
> >fields that might only be used partially?
>
On Wed, Jun 01, 2011 at 05:51:54PM +0300, Avi Kivity wrote:
> On 06/01/2011 05:36 PM, Michael S. Tsirkin wrote:
> >>
> >> So, if I am going to give this liberty with buffers to the driver, I
> >> _have_ to keep the size information. Otherwise, I agree that it is
> >> redundant and I will remove
On 06/01/2011 04:36 PM, Michael S. Tsirkin wrote:
Ah, I think I understand now. Both sense and data have in
fields that might only be used partially?
In that case I think I agree: it's best to require the use of separate
buffers for them, in this way used len will give you useful information
and
On 06/01/2011 07:25 PM, Paolo Bonzini wrote:
On 06/01/2011 03:46 PM, Avi Kivity wrote:
Virtqueues
0:control transmitq
1:control receiveq
2:requestq
Shouldn't we plan multiqueue for this from day 1?
How would you do multiqueue? Just provide N queues, and the device
can pla
On 06/01/2011 03:46 PM, Avi Kivity wrote:
Virtqueues
0:control transmitq
1:control receiveq
2:requestq
Shouldn't we plan multiqueue for this from day 1?
How would you do multiqueue? Just provide N queues, and the device can
place requests for any LUN on any queue?
If tha
On 05/20/2011 11:21 AM, Paolo Bonzini wrote:
Hi all,
here is the second version of the spec. In the end I took the advice
of merging all requestq's into one. The reason for this is that I
took a look at the vSCSI device and liked its approach of using SAM
8-byte LUNs directly. While it _is
On 06/01/2011 05:36 PM, Michael S. Tsirkin wrote:
>
> So, if I am going to give this liberty with buffers to the driver, I
> _have_ to keep the size information. Otherwise, I agree that it is
> redundant and I will remove it. What poison do you prefer?
>
Ah, I think I understand now. Both s
On Wed, Jun 01, 2011 at 03:31:42PM +0200, Paolo Bonzini wrote:
> On 06/01/2011 02:51 PM, Michael S. Tsirkin wrote:
> The cdb, data and sense fields must reside in separate buffers.
> The cdb field is always read-only. The data buffers may be either
> read-only or write-o
On 06/01/2011 02:51 PM, Michael S. Tsirkin wrote:
The cdb, data and sense fields must reside in separate buffers.
The cdb field is always read-only. The data buffers may be either
read-only or write-only, depending on the request, with the read-only
buffers coming first. The
On Wed, Jun 01, 2011 at 01:59:14PM +0200, Paolo Bonzini wrote:
> >>Device initialization
> >>-
> >>
> >>The initialization routine should first of all discover the device's
> >>control virtqueues.
> >>
> >>The driver should then place at least a buffer in the control receiveq.
>
Device initialization
-
The initialization routine should first of all discover the device's
control virtqueues.
The driver should then place at least a buffer in the control receiveq.
Size of the buffer?
Good catch. I'll add this to the configuration information.
On Fri, May 20, 2011 at 10:21:03AM +0200, Paolo Bonzini wrote:
> Hi all,
>
> here is the second version of the spec. In the end I took the
> advice of merging all requestq's into one. The reason for this is
> that I took a look at the vSCSI device and liked its approach of
> using SAM 8-byte LUN
On Mon, May 30, 2011 at 10:22 AM, Paolo Bonzini wrote:
> On 05/28/2011 09:33 PM, Stefan Hajnoczi wrote:
>>> Requests have the following format:
>>>
>>> struct virtio_scsi_req_cmd {
>>> u8 lun[8];
>>> u64 id;
>>> u8 task_attr;
>>> u8 prio;
>>> u8 crn;
>>>
On 05/28/2011 09:33 PM, Stefan Hajnoczi wrote:
Virtqueues
0:control transmitq
1:control receiveq
I find these names weird because control commands are actually processed
and completed on the transmitq. The receiveq is only for receiving
asynchronous notifications.
0:control commandq
On Fri, May 20, 2011 at 10:21:03AM +0200, Paolo Bonzini wrote:
> Configuration
> -
>
> Subsystem Device ID
> TBD
>
> Virtqueues
> 0:control transmitq
> 1:control receiveq
I find these names weird because control commands are actually processed
and completed on the transmi
Hi all,
here is the second version of the spec. In the end I took the advice of
merging all requestq's into one. The reason for this is that I took a
look at the vSCSI device and liked its approach of using SAM 8-byte LUNs
directly. While it _is_ complex (and not yet done right by QEMU---wi
21 matches
Mail list logo
