Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR

Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR

[Michael S. Tsirkin]

On Thu, Nov 03, 2011 at 08:49:31AM -0500, Anthony Liguori wrote:
> On 11/03/2011 08:45 AM, Avi Kivity wrote:
> >On 11/03/2011 03:38 PM, Anthony Liguori wrote:
> >>>
> >>>>We could use a better agreement on the processor for making virtio
> >>>>changes. Should it go (1) virtio spec (2) kernel (3) qemu, or should
> >>>>it go (2), (1), (3)?
> >>>
> >>>1. Informal discussion
> >>
> >>
> >>Where?  Is this lkml?  There were a number of virtio changes recently
> >>that never involved qemu-devel.
> >
> >Theoretically, virtualization@lists.linux-foundation.org, if it still
> >exists.  Maybe we need a virtio list. qemu-devel@, kvm@, lkml could be
> >copied.
> 
> Perhaps it's time to create a virtio@vger?  Just have a simple
> process that all spec changes to there the appropriate kernel, QEMU,
> virtio-win, or NKT maintainers can require any virtio change to also
> have a committed spec change first.

Historically virtualization@lists.linux-foundation.org was used,
that is still low enough volume. It was down but seems to be
up now. It's easy enough for me to subscribe to yet
another list but my concern is that if we move we might loose some
people that don't notice the change.

Anything wrong with just using the old list?
It's on the MAINTAINERS file, I'm not sure why it was bypassed in this case.
Maybe linux-foundation.org was still down when the patch was posted?

> >The point is that we can't drive virtio from either qemu or the kernel
> >any more.  The spec represents the "virtual hardware manufacturer",
> >which qemu and linux/vhost (and others) emulate, and which linux (and
> >others) write drivers for.
> 
> Yup.  We need to be more rigorous about using the spec for that as
> we've not done a great job historically here.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >>
> >>>2. Proposed spec patch, kernel change, qemu change
> >>>3. Buy-ins from spec maintainer, kernel driver maintainer, qemu device
> >>>maintainer (only regarding the ABI, not the code)
> >>
> >>I don't think this is how it's working today.  I would be happy with a
> >>flow like this.
> >
> >If Michael and Rusty agree, we can adopt it immediately.
> >

If I understand the proposal, what is suggested is that
all of spec, kvm and virtio patches are posted on list and
acked before merging any one of them?

Sure, this makes sense.

-- 
MST

Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR

[Anthony Liguori]

On 11/03/2011 09:31 AM, Michael S. Tsirkin wrote:
> On Thu, Nov 03, 2011 at 08:49:31AM -0500, Anthony Liguori wrote:
>> On 11/03/2011 08:45 AM, Avi Kivity wrote:
>>> On 11/03/2011 03:38 PM, Anthony Liguori wrote:
>>>>>
>>>>>> We could use a better agreement on the processor for making virtio
>>>>>> changes. Should it go (1) virtio spec (2) kernel (3) qemu, or should
>>>>>> it go (2), (1), (3)?
>>>>>
>>>>> 1. Informal discussion
>>>>
>>>>
>>>> Where?  Is this lkml?  There were a number of virtio changes recently
>>>> that never involved qemu-devel.
>>>
>>> Theoretically, virtualization@lists.linux-foundation.org, if it still
>>> exists.  Maybe we need a virtio list. qemu-devel@, kvm@, lkml could be
>>> copied.
>>
>> Perhaps it's time to create a virtio@vger?  Just have a simple
>> process that all spec changes to there the appropriate kernel, QEMU,
>> virtio-win, or NKT maintainers can require any virtio change to also
>> have a committed spec change first.
>
> Historically virtualization@lists.linux-foundation.org was used,
> that is still low enough volume. It was down but seems to be
> up now. It's easy enough for me to subscribe to yet
> another list but my concern is that if we move we might loose some
> people that don't notice the change.
>
> Anything wrong with just using the old list?

No, but it's so old, I have no idea who admin's it these days.

> It's on the MAINTAINERS file, I'm not sure why it was bypassed in this case.
> Maybe linux-foundation.org was still down when the patch was posted?

The list has been down for a while.

>>>>> 2. Proposed spec patch, kernel change, qemu change
>>>>> 3. Buy-ins from spec maintainer, kernel driver maintainer, qemu device
>>>>> maintainer (only regarding the ABI, not the code)
>>>>
>>>> I don't think this is how it's working today.  I would be happy with a
>>>> flow like this.
>>>
>>> If Michael and Rusty agree, we can adopt it immediately.
>>>
>
> If I understand the proposal, what is suggested is that
> all of spec, kvm and virtio patches are posted on list and
> acked before merging any one of them?
>
> Sure, this makes sense.

Well, what's needed before the spec is changed is an interesting question, but I 
think the main thing is, don't commit any virtio ABI changes to vhost, QEMU, 
NKT, or the kernel until the spec for the change has been committed.

It would be nice to have a working implementation before committing a spec 
change.  Even nicer would be to have Acked-by's a maintainer in each area affected.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] virtio: Add PCI memory BAR in addition to PIO BAR

[Avi Kivity]

On 11/03/2011 04:37 PM, Anthony Liguori wrote:
>
>>>>>> 2. Proposed spec patch, kernel change, qemu change
>>>>>> 3. Buy-ins from spec maintainer, kernel driver maintainer, qemu
>>>>>> device
>>>>>> maintainer (only regarding the ABI, not the code)
>>>>>
>>>>> I don't think this is how it's working today.  I would be happy
>>>>> with a
>>>>> flow like this.
>>>>
>>>> If Michael and Rusty agree, we can adopt it immediately.
>>>>
>>
>> If I understand the proposal, what is suggested is that
>> all of spec, kvm and virtio patches are posted on list and
>> acked before merging any one of them?
>>
>> Sure, this makes sense.
>
> Well, what's needed before the spec is changed is an interesting
> question, but I think the main thing is, don't commit any virtio ABI
> changes to vhost, QEMU, NKT, or the kernel until the spec for the
> change has been committed.
>
> It would be nice to have a working implementation before committing a
> spec change.  Even nicer would be to have Acked-by's a maintainer in
> each area affected.
>

Those are steps 2 and 3 of the proposed process.

-- 
error compiling committee.c: too many arguments to function