Bitfields are a useful and familiar way to specify sub-byte structure
layout. The only issue is that bitfield order isn't portable across
architectures. Document that we list bitfields from least to
most significant one, and warn about portability issues.
Signed-off-by: Michael S. Tsirkin
Document buffer used len and use that terminology everywhere in the
generic section.
Further, drop the 'used ring' terminology and just say virtqueue.
Reviewed-by: Cornelia Huck
Signed-off-by: Michael S. Tsirkin
---
content.tex | 39
virtqueue operation description is specific to the virtqueue
format. Move it out to split-ring.tex and update all
references.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
conformance.tex | 4 +-
content.tex | 171
Will be easier to manage this way.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
content.tex| 499 +
split-ring.tex | 498
Support in-order requests for packed rings.
This allows selective write-out of used descriptors.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
Reviewed-by: Stefan Hajnoczi
---
packed-ring.tex | 24
Update generic text to talk about available/used buffers, not rings.
Move some split-ring specific text to the correct section.
Update conformance section with link to the new conformance clause.
Signed-off-by: Michael S. Tsirkin
---
conformance.tex | 1 +
content.tex |
For a split ring, require that drivers use descriptors in order too.
This allows devices to skip reading the available ring.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
Reviewed-by: Stefan Hajnoczi
---
split-ring.tex |
Using descriptors in-order is sometimes beneficial. Add an option for
that - per-format detail allowing more optimizations will be added by
follow-up patches.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
Reviewed-by: Stefan Hajnoczi
This is a proposal to implement an alternative ring layout. The
idea is to have a r/w descriptor in a ring structure, replacing
the used and available ring, index and descriptor buffer.
This is more efficient and easier for devices to implement than
the 1.0 layout.
Additionally, a new feature
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
content.tex | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/content.tex b/content.tex
index c7ef7fd..4483a4b 100644
--- a/content.tex
+++
On Wed, Mar 07, 2018 at 12:00:48PM +0100, Cornelia Huck wrote:
> On Thu, 1 Mar 2018 01:31:33 +0200
> "Michael S. Tsirkin" wrote:
>
> > Update generic text to talk about available/used buffers, not rings.
> > Move some split-ring specific text to the correct section.
> >
> >
On Thu, Feb 22, 2018 at 01:50:52PM +0100, Tomáš Golembiovský wrote:
> Linux kernel provides some balloon memory statistics that were not
> included in the specs. Include them to avoid any ID clashes in the
> future.
>
> Signed-off-by: Tomáš Golembiovský
No comments on this
On 03/08/2018 05:19 PM, Michael S. Tsirkin wrote:
> On Thu, Mar 08, 2018 at 02:03:31PM +0100, Halil Pasic wrote:
>> One stray idea was something like
>>
>> be32 (A:16;B:15;C:1);
>>
>> With
>> * A occupying bits 0-15
>> * B occupying bits 16-30
>> * C occupying bit 30
>>
>> And bit n of B (n \in
On Thu, 8 Mar 2018 18:19:39 +0200
"Michael S. Tsirkin" wrote:
> On Thu, Mar 08, 2018 at 02:03:31PM +0100, Halil Pasic wrote:
> > One stray idea was something like
> >
> > be32 (A:16;B:15;C:1);
> >
> > With
> > * A occupying bits 0-15
> > * B occupying bits 16-30
> > * C
On Fri, Mar 09, 2018 at 10:44:23AM +0800, Changpeng Liu wrote:
> Existing virtio-blk protocol doesn't have DISCARD/WRITE ZEROES support,
> this will impact the performance when using SSD backend over file systems.
>
> Here is the proposal to extend existing virtio-blk protocol to support
>
On Fri, Mar 09, 2018 at 01:25:11PM +0100, Halil Pasic wrote:
>
>
> On 03/08/2018 05:19 PM, Michael S. Tsirkin wrote:
> > On Thu, Mar 08, 2018 at 02:03:31PM +0100, Halil Pasic wrote:
> >> One stray idea was something like
> >>
> >> be32 (A:16;B:15;C:1);
> >>
> >> With
> >> * A occupying bits
On Thu, Mar 01, 2018 at 01:31:18AM +0200, Michael S. Tsirkin wrote:
> This addresses comments on v8.
>
> Thanks a lot to all reviewers of v8 - I hope we are
> finally there or almost there.
FYI the last round of comments was mostly about formatting,
so I plan to post v10 and start voting
17 matches
Mail list logo