On Mon, 5 Feb 2018 20:21:12 +0200
"Michael S. Tsirkin" wrote:
> On Mon, Feb 05, 2018 at 07:16:54PM +0100, Cornelia Huck wrote:
> > > I agree that this doesn't seem optimal. This is a much bigger change
> > > than anything between virtio 0.9 and in virtio 1.0, because it affects
> > > the data pa
On Mon, Feb 05, 2018 at 07:16:54PM +0100, Cornelia Huck wrote:
> > I agree that this doesn't seem optimal. This is a much bigger change
> > than anything between virtio 0.9 and in virtio 1.0, because it affects
> > the data path directly.
>
> Nod. It looks in pretty good shape to me, once we fixe
On Mon, 5 Feb 2018 18:00:07 +0100
Paolo Bonzini wrote:
> On 05/02/2018 17:57, Halil Pasic wrote:
> >> This is certainly not how we did it for v1.0, and not how
> >> oasis process works generally. Implementations are required
> >> to move to an oasis standard change. We are working on
> >> a commi
On Mon, Feb 05, 2018 at 05:57:26PM +0100, Halil Pasic wrote:
> I think it's much simpler if we get as much as possible right from
> the beginning (that is release). But that's only my very own opinion.
I agree here. If nothing else, if we can avoid making material changes
after the first public re
On 05/02/2018 17:57, Halil Pasic wrote:
>> This is certainly not how we did it for v1.0, and not how
>> oasis process works generally. Implementations are required
>> to move to an oasis standard change. We are working on
>> a committee standard deliverables.
>>
>> I don't yet plan to work on an im
On 02/05/2018 03:33 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 05, 2018 at 12:54:41PM +0100, Halil Pasic wrote:
>>
>>
>> On 01/30/2018 02:50 PM, Cornelia Huck wrote:
>>> On Tue, 23 Jan 2018 02:01:07 +0200
>>> "Michael S. Tsirkin" wrote:
>>>
Performance analysis of this is in my kvm forum 2
On Mon, Feb 05, 2018 at 12:54:41PM +0100, Halil Pasic wrote:
>
>
> On 01/30/2018 02:50 PM, Cornelia Huck wrote:
> > On Tue, 23 Jan 2018 02:01:07 +0200
> > "Michael S. Tsirkin" wrote:
> >
> >> Performance analysis of this is in my kvm forum 2016 presentation. The
> >> idea is to have a r/w desc
On 01/30/2018 02:50 PM, Cornelia Huck wrote:
> On Tue, 23 Jan 2018 02:01:07 +0200
> "Michael S. Tsirkin" wrote:
>
>> Performance analysis of this is in my kvm forum 2016 presentation. The
>> idea is to have a r/w descriptor in a ring structure, replacing the used
>> and available ring, index a
On Thu, Feb 01, 2018 at 11:11:28AM +0100, Cornelia Huck wrote:
> On Thu, 1 Feb 2018 11:05:35 +0800
> Tiwei Bie wrote:
>
> > On Tue, Jan 30, 2018 at 09:40:35PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jan 30, 2018 at 02:50:44PM +0100, Cornelia Huck wrote:
> > > > On Tue, 23 Jan 2018 02:01:
On Thu, 1 Feb 2018 11:05:35 +0800
Tiwei Bie wrote:
> On Tue, Jan 30, 2018 at 09:40:35PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jan 30, 2018 at 02:50:44PM +0100, Cornelia Huck wrote:
> > > On Tue, 23 Jan 2018 02:01:07 +0200
> > > "Michael S. Tsirkin" wrote:
> > > > +\subsubsection{Driver
On Tue, Jan 30, 2018 at 09:40:35PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 30, 2018 at 02:50:44PM +0100, Cornelia Huck wrote:
> > On Tue, 23 Jan 2018 02:01:07 +0200
> > "Michael S. Tsirkin" wrote:
> >
> > > Performance analysis of this is in my kvm forum 2016 presentation. The
> > > idea
On Tue, Jan 30, 2018 at 02:50:44PM +0100, Cornelia Huck wrote:
> On Tue, 23 Jan 2018 02:01:07 +0200
> "Michael S. Tsirkin" wrote:
>
> > Performance analysis of this is in my kvm forum 2016 presentation. The
> > idea is to have a r/w descriptor in a ring structure, replacing the used
> > and avai
On Tue, 23 Jan 2018 02:01:07 +0200
"Michael S. Tsirkin" wrote:
> Performance analysis of this is in my kvm forum 2016 presentation. 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 also easier for devic
13 matches
Mail list logo
