From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
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>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
virtualization@lists.linux-foundation.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Amit Shah <amit.shah@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH RFC] virtio-pci: flexible configuration layout
Date: Thu, 3 Nov 2011 15:30:16 +0200 [thread overview]
Message-ID: <20111103133015.GL18296@redhat.com> (raw)
In-Reply-To: <1320318591.29407.17.camel@lappy>
> 2. Move device specific features into the device specific region.
> Currently the features field is a mix between virtio-pci and device
> specific features.
A single feature field with bits partitioned to transport
specific and device specific fields is a generic virtio
thing. So there's relatively little to be gained from
moving the device bits out.
> I did more similar things in the spec suggestion I've sent,
What lacked there is the motivation.
I am aware of several issues that need to be addressed,
as they block extending virtio going forward:
- There's no place to put more transport registers.
For MSIX I hacked around that with moving device config when a feature
bit is set, but in hindsight this setup is fragile
and is panful to extend any further.
Splitting out device and transport helps.
- PIO space is limited. We are wasting it on non data path
configuration. There might also be a wish to have largish data
in configuration space, like a 1024 byte ID field.
- PIO is faster than MMIO on x86 KVM so we need to keep
using it for data path on that architecture
- Support architectures which have host/guest at different
endian-ness.
I addressed the first 3 and added capability infrastructure
which we can use in the future to support the last one
(by nature of using little endian format for capabilities).
> could you
> look at the second part for more ideas please?
I saw the per-queue features - but I don't see how it will work really
or what is the issue they solve.
Any more ideas I missed?
> --
>
> Sasha.
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Linus Torvalds <torvalds@linux-foundation.org>,
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>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [PATCH RFC] virtio-pci: flexible configuration layout
Date: Thu, 3 Nov 2011 15:30:16 +0200 [thread overview]
Message-ID: <20111103133015.GL18296@redhat.com> (raw)
In-Reply-To: <1320318591.29407.17.camel@lappy>
> 2. Move device specific features into the device specific region.
> Currently the features field is a mix between virtio-pci and device
> specific features.
A single feature field with bits partitioned to transport
specific and device specific fields is a generic virtio
thing. So there's relatively little to be gained from
moving the device bits out.
> I did more similar things in the spec suggestion I've sent,
What lacked there is the motivation.
I am aware of several issues that need to be addressed,
as they block extending virtio going forward:
- There's no place to put more transport registers.
For MSIX I hacked around that with moving device config when a feature
bit is set, but in hindsight this setup is fragile
and is panful to extend any further.
Splitting out device and transport helps.
- PIO space is limited. We are wasting it on non data path
configuration. There might also be a wish to have largish data
in configuration space, like a 1024 byte ID field.
- PIO is faster than MMIO on x86 KVM so we need to keep
using it for data path on that architecture
- Support architectures which have host/guest at different
endian-ness.
I addressed the first 3 and added capability infrastructure
which we can use in the future to support the last one
(by nature of using little endian format for capabilities).
> could you
> look at the second part for more ideas please?
I saw the per-queue features - but I don't see how it will work really
or what is the issue they solve.
Any more ideas I missed?
> --
>
> Sasha.
next prev parent reply other threads:[~2011-11-03 13:30 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87wrbkvh3v.fsf@rustcorp.com.au>
2011-11-01 11:45 ` [PULL] virtio Michael S. Tsirkin
2011-11-01 11:45 ` Michael S. Tsirkin
2011-11-01 12:33 ` Sasha Levin
2011-11-01 12:33 ` Sasha Levin
2011-11-01 12:42 ` Michael S. Tsirkin
2011-11-01 12:42 ` Michael S. Tsirkin
2011-11-01 12:45 ` Sasha Levin
2011-11-01 12:45 ` Sasha Levin
2011-11-02 1:09 ` Rusty Russell
2011-11-02 4:52 ` Sasha Levin
2011-11-02 4:52 ` Sasha Levin
2011-11-02 22:07 ` Rusty Russell
2011-11-02 22:07 ` Rusty Russell
2011-11-02 23:31 ` [PATCH RFC] virtio-pci: flexible configuration layout Michael S. Tsirkin
2011-11-02 23:31 ` Michael S. Tsirkin
2011-11-03 0:19 ` Sasha Levin
2011-11-03 0:19 ` Sasha Levin
2011-11-03 10:33 ` Michael S. Tsirkin
2011-11-03 10:33 ` Michael S. Tsirkin
2011-11-03 11:09 ` Sasha Levin
2011-11-03 11:09 ` Sasha Levin
2011-11-03 11:36 ` Michael S. Tsirkin
2011-11-03 11:36 ` Michael S. Tsirkin
2011-11-03 13:30 ` Michael S. Tsirkin [this message]
2011-11-03 13:30 ` Michael S. Tsirkin
2011-11-03 10:37 ` Avi Kivity
2011-11-03 10:37 ` Avi Kivity
2011-11-03 12:11 ` Michael S. Tsirkin
2011-11-03 12:11 ` Michael S. Tsirkin
2011-11-03 13:37 ` Avi Kivity
2011-11-03 13:37 ` Avi Kivity
2011-11-03 13:53 ` Michael S. Tsirkin
2011-11-03 13:53 ` Michael S. Tsirkin
2011-11-03 14:59 ` Jesse Barnes
2011-11-03 14:59 ` Jesse Barnes
2011-11-08 21:40 ` [PATCH RFC] virtio-spec: " Michael S. Tsirkin
2011-11-08 21:40 ` Michael S. Tsirkin
2011-11-08 21:41 ` Michael S. Tsirkin
2011-11-09 10:21 ` Avi Kivity
2011-11-09 8:46 ` Sasha Levin
2011-11-09 10:13 ` Michael S. Tsirkin
2011-11-09 10:13 ` Michael S. Tsirkin
2011-11-09 10:26 ` Sasha Levin
2011-11-09 10:26 ` Sasha Levin
2011-11-09 10:49 ` Michael S. Tsirkin
2011-11-09 10:49 ` Michael S. Tsirkin
2011-11-09 12:25 ` Pekka Enberg
2011-11-09 12:28 ` Sasha Levin
2011-11-09 12:28 ` Sasha Levin
2011-11-09 12:36 ` Pekka Enberg
2011-11-09 12:36 ` Pekka Enberg
2011-11-09 15:33 ` Michael S. Tsirkin
2011-11-09 15:33 ` Michael S. Tsirkin
2012-06-18 11:54 ` Michael S. Tsirkin
2012-06-18 11:54 ` Michael S. Tsirkin
2012-06-18 12:05 ` Sasha Levin
2012-06-18 12:05 ` Sasha Levin
2012-06-18 12:07 ` Michael S. Tsirkin
2012-06-18 12:07 ` Michael S. Tsirkin
2011-11-09 12:25 ` Pekka Enberg
2011-11-09 12:38 ` Avi Kivity
2011-11-09 12:38 ` Avi Kivity
2011-11-09 12:48 ` Sasha Levin
2011-11-09 12:48 ` Sasha Levin
2011-11-09 15:19 ` Michael S. Tsirkin
2011-11-09 15:19 ` Michael S. Tsirkin
2011-11-13 14:07 ` Ronen Hod
2011-11-13 14:07 ` Ronen Hod
2011-11-09 15:51 ` Michael S. Tsirkin
2011-11-09 15:51 ` Michael S. Tsirkin
2011-11-13 20:40 ` Vadim Rozenfeld
2011-11-13 20:40 ` Vadim Rozenfeld
2011-11-09 8:46 ` Sasha Levin
2011-11-09 9:55 ` Sasha Levin
2011-11-09 10:18 ` Michael S. Tsirkin
2011-11-09 10:18 ` Michael S. Tsirkin
2011-11-09 10:20 ` Sasha Levin
2011-11-09 10:20 ` Sasha Levin
2011-11-09 10:20 ` Sasha Levin
2011-11-09 10:47 ` Pawel Moll
2011-11-09 10:47 ` Pawel Moll
2011-11-09 10:55 ` Sasha Levin
2011-11-09 10:55 ` Sasha Levin
2011-11-09 11:06 ` Pawel Moll
2011-11-09 11:06 ` Pawel Moll
2011-11-09 11:39 ` Peter Maydell
2011-11-09 11:39 ` Peter Maydell
2011-11-09 12:07 ` Sasha Levin
2011-11-09 12:07 ` Sasha Levin
2011-11-09 9:55 ` Sasha Levin
2011-11-09 19:59 ` [PATCHv2 " Michael S. Tsirkin
2011-11-09 19:59 ` Michael S. Tsirkin
2011-11-09 20:00 ` Michael S. Tsirkin
2011-11-09 20:24 ` Sasha Levin
2011-11-09 20:24 ` Sasha Levin
2011-11-09 20:52 ` Michael S. Tsirkin
2011-11-09 20:52 ` Michael S. Tsirkin
2011-11-09 20:57 ` Sasha Levin
2011-11-09 20:57 ` Sasha Levin
2011-11-09 21:14 ` Michael S. Tsirkin
2011-11-09 21:14 ` Michael S. Tsirkin
2011-11-09 21:13 ` Sasha Levin
2011-11-09 21:13 ` Sasha Levin
2011-11-10 8:55 ` Michael S. Tsirkin
2011-11-10 8:55 ` Michael S. Tsirkin
2011-11-11 4:24 ` Rusty Russell
2011-11-11 4:24 ` Rusty Russell
2011-11-11 7:39 ` Sasha Levin
2011-11-11 7:39 ` Sasha Levin
2011-11-11 12:59 ` Michael S. Tsirkin
2011-11-11 12:59 ` Michael S. Tsirkin
2011-11-11 13:06 ` Pawel Moll
2011-11-11 13:06 ` Pawel Moll
2011-11-15 23:58 ` Rusty Russell
2011-11-15 23:58 ` Rusty Russell
2011-11-16 7:21 ` Michael S. Tsirkin
2011-11-16 7:21 ` Michael S. Tsirkin
2011-11-16 8:17 ` Sasha Levin
2011-11-16 8:17 ` Sasha Levin
2011-11-16 9:09 ` Michael S. Tsirkin
2011-11-16 9:09 ` Michael S. Tsirkin
2011-11-11 13:03 ` Michael S. Tsirkin
2011-11-11 13:03 ` Michael S. Tsirkin
2011-11-13 15:14 ` Michael S. Tsirkin
2011-11-13 15:14 ` Michael S. Tsirkin
2011-11-14 6:59 ` Michael S. Tsirkin
2011-11-14 6:59 ` Michael S. Tsirkin
2011-11-15 23:58 ` Rusty Russell
2011-11-15 23:58 ` Rusty Russell
2011-11-16 7:03 ` Michael S. Tsirkin
2011-11-16 7:03 ` Michael S. Tsirkin
2011-11-10 12:24 ` [PATCHv3 " Michael S. Tsirkin
2011-11-10 12:24 ` Michael S. Tsirkin
2011-11-02 1:09 ` [PULL] virtio Rusty Russell
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=20111103133015.GL18296@redhat.com \
--to=mst@redhat.com \
--cc=aik@ozlabs.ru \
--cc=amit.shah@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=jbarnes@virtuousgeek.org \
--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=shhuiw@gmail.com \
--cc=torvalds@linux-foundation.org \
--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.