From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Krishna Kumar <krkumar2@in.ibm.com>,
kvm@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
Wang Sheng-Hui <shhuiw@gmail.com>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
virtualization@lists.linux-foundation.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Sasha Levin <levinsasha928@gmail.com>,
Amit Shah <amit.shah@redhat.com>
Subject: Re: [PATCHv3 RFC] virtio-pci: flexible configuration layout
Date: Mon, 28 Nov 2011 10:41:51 +0200 [thread overview]
Message-ID: <20111128084009.GB20084@redhat.com> (raw)
In-Reply-To: <87vcq5t69c.fsf@rustcorp.com.au>
On Mon, Nov 28, 2011 at 11:25:43AM +1030, Rusty Russell wrote:
> > > But I'm *terrified* of making the spec more complex;
> >
> > All you do is move stuff around. Why do you think it simplifies the spec
> > so much?
>
> No, but it reduces the yuk factor. Which has been important to adoption.
Sorry if I'm dense. Could you please clarify: do you think we can live
with the slightly higher yuk factor assuming the spec moves the
legacy mode into an appendix as you explain below and driver has a
single 'legacy' switch?
> And that's *not* all I do: reducing the number of options definitely
> simplifies the spec. For example, the spec should currently say
> (looking at your implementation):
>
> Notifying the device
> ====================
> If you find a valid VIRTIO_PCI_CAP_NOTIFY_CFG capability, and you can
> map 2 bytes within it, those two bytes should be used to notify the
> device of new descriptors in its virtqueues, by writing the index of the
> virtqueue to that mapping.
>
> If the capability is missing or malformed or you cannot map it, the
> virtqueue index should be written to the VIRTIO_PCI_QUEUE_NOTIFY offset
> of the legacy bar.
>
> Vs:
>
> Notifying the device
> ====================
> The index of the virtqueue containing new descriptors should be written
> to the location specified by the VIRTIO_PCI_CAP_NOTIFY_CFG capability.
> (Unless the device is in legacy mode, see Appendix Y: Legacy Mode).
Yes, I agree, this is better.
...
> Look, I try to be more inclusive and polite than Linus, but at some
> point more verbiage is wasted.
> We will have single Legacy Mode switch.
Sorry, I'm adding more verbiage :(
When you say a single Legacy Mode switch, you mean that the driver will
assume either legacy layout or the new one, correct?
> Accept it, or fork the standard.
>
> If you want to reuse the same structure, we're going to need to figure
> out how to specify the virtqueue address without a fixed alignment, and
> how to specify the alignment itself.
I think I see a way to do that in a relatively painless way.
Do you prefer seeing driver patches or spec? Or are you not interested
in reusing the same structure at all?
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Sasha Levin <levinsasha928@gmail.com>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexey Kardashevskiy <aik@ozlabs.ru>,
Amit Shah <amit.shah@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Krishna Kumar <krkumar2@in.ibm.com>,
Pawel Moll <pawel.moll@arm.com>,
Wang Sheng-Hui <shhuiw@gmail.com>,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [PATCHv3 RFC] virtio-pci: flexible configuration layout
Date: Mon, 28 Nov 2011 10:41:51 +0200 [thread overview]
Message-ID: <20111128084009.GB20084@redhat.com> (raw)
In-Reply-To: <87vcq5t69c.fsf@rustcorp.com.au>
On Mon, Nov 28, 2011 at 11:25:43AM +1030, Rusty Russell wrote:
> > > But I'm *terrified* of making the spec more complex;
> >
> > All you do is move stuff around. Why do you think it simplifies the spec
> > so much?
>
> No, but it reduces the yuk factor. Which has been important to adoption.
Sorry if I'm dense. Could you please clarify: do you think we can live
with the slightly higher yuk factor assuming the spec moves the
legacy mode into an appendix as you explain below and driver has a
single 'legacy' switch?
> And that's *not* all I do: reducing the number of options definitely
> simplifies the spec. For example, the spec should currently say
> (looking at your implementation):
>
> Notifying the device
> ====================
> If you find a valid VIRTIO_PCI_CAP_NOTIFY_CFG capability, and you can
> map 2 bytes within it, those two bytes should be used to notify the
> device of new descriptors in its virtqueues, by writing the index of the
> virtqueue to that mapping.
>
> If the capability is missing or malformed or you cannot map it, the
> virtqueue index should be written to the VIRTIO_PCI_QUEUE_NOTIFY offset
> of the legacy bar.
>
> Vs:
>
> Notifying the device
> ====================
> The index of the virtqueue containing new descriptors should be written
> to the location specified by the VIRTIO_PCI_CAP_NOTIFY_CFG capability.
> (Unless the device is in legacy mode, see Appendix Y: Legacy Mode).
Yes, I agree, this is better.
...
> Look, I try to be more inclusive and polite than Linus, but at some
> point more verbiage is wasted.
> We will have single Legacy Mode switch.
Sorry, I'm adding more verbiage :(
When you say a single Legacy Mode switch, you mean that the driver will
assume either legacy layout or the new one, correct?
> Accept it, or fork the standard.
>
> If you want to reuse the same structure, we're going to need to figure
> out how to specify the virtqueue address without a fixed alignment, and
> how to specify the alignment itself.
I think I see a way to do that in a relatively painless way.
Do you prefer seeing driver patches or spec? Or are you not interested
in reusing the same structure at all?
--
MST
next prev parent reply other threads:[~2011-11-28 8:41 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-22 18:36 [PATCHv3 RFC] virtio-pci: flexible configuration layout Michael S. Tsirkin
2011-11-22 18:36 ` Michael S. Tsirkin
2011-11-23 2:32 ` Rusty Russell
2011-11-23 2:32 ` Rusty Russell
2011-11-23 8:46 ` Michael S. Tsirkin
2011-11-23 8:46 ` Michael S. Tsirkin
2011-11-23 15:34 ` Michael S. Tsirkin
2011-11-23 15:34 ` Michael S. Tsirkin
2011-11-24 0:36 ` Rusty Russell
2011-11-24 0:36 ` Rusty Russell
2011-11-24 6:24 ` Michael S. Tsirkin
2011-11-24 6:24 ` Michael S. Tsirkin
2011-11-24 7:11 ` Michael S. Tsirkin
2011-11-24 7:11 ` Michael S. Tsirkin
2011-11-28 0:55 ` Rusty Russell
2011-11-28 0:55 ` Rusty Russell
2011-11-28 8:41 ` Michael S. Tsirkin [this message]
2011-11-28 8:41 ` Michael S. Tsirkin
2011-11-29 23:28 ` Rusty Russell
2011-11-29 23:28 ` Rusty Russell
2011-11-30 7:18 ` Michael S. Tsirkin
2011-11-30 7:18 ` Michael S. Tsirkin
2011-11-28 9:15 ` Sasha Levin
2011-11-28 9:15 ` Sasha Levin
2011-11-29 23:40 ` Rusty Russell
2011-11-29 23:40 ` Rusty Russell
2011-11-30 8:14 ` Michael S. Tsirkin
2011-11-30 8:14 ` Michael S. Tsirkin
2011-11-30 13:12 ` Sasha Levin
2011-11-30 13:12 ` Sasha Levin
2011-12-01 2:42 ` Rusty Russell
2011-12-01 2:42 ` Rusty Russell
2011-11-23 8:49 ` Michael S. Tsirkin
2011-11-23 8:49 ` Michael S. Tsirkin
2011-11-23 9:38 ` Sasha Levin
2011-11-23 9:38 ` Sasha Levin
2011-11-24 1:07 ` Rusty Russell
2011-11-24 1:07 ` Rusty Russell
2011-11-23 9:44 ` Sasha Levin
2011-11-23 9:44 ` Sasha Levin
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=20111128084009.GB20084@redhat.com \
--to=mst@redhat.com \
--cc=aik@ozlabs.ru \
--cc=amit.shah@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=krkumar2@in.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pawel.moll@arm.com \
--cc=rusty@rustcorp.com.au \
--cc=shhuiw@gmail.com \
--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.