virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
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.

  parent reply	other threads:[~2011-11-03 13:30 UTC|newest]

Thread overview: 68+ 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 12:33   ` Sasha Levin
2011-11-01 12:42     ` Michael S. Tsirkin
2011-11-01 12:45       ` Sasha Levin
2011-11-02  1:09       ` Rusty Russell
     [not found]       ` <8739e7uy87.fsf@rustcorp.com.au>
2011-11-02  4:52         ` Sasha Levin
2011-11-02 22:07           ` Rusty Russell
2011-11-02 23:31         ` [PATCH RFC] virtio-pci: flexible configuration layout Michael S. Tsirkin
2011-11-03  0:19           ` Sasha Levin
2011-11-03 10:33             ` Michael S. Tsirkin
2011-11-03 11:09               ` Sasha Levin
2011-11-03 11:36                 ` Michael S. Tsirkin
2011-11-03 13:30                 ` Michael S. Tsirkin [this message]
2011-11-03 10:37           ` Avi Kivity
2011-11-03 12:11             ` Michael S. Tsirkin
2011-11-03 13:37               ` Avi Kivity
2011-11-03 13:53                 ` Michael S. Tsirkin
2011-11-03 14:59           ` Jesse Barnes
2011-11-08 21:40           ` [PATCH RFC] virtio-spec: " 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  9:55             ` Sasha Levin
     [not found]             ` <1320828366.31056.16.camel@lappy>
2011-11-09 10:13               ` Michael S. Tsirkin
2011-11-09 10:26                 ` Sasha Levin
2011-11-09 10:49                   ` Michael S. Tsirkin
2011-11-09 12:25                 ` Pekka Enberg
     [not found]                 ` <alpine.LFD.2.02.1111091421570.4936@tux.localdomain>
2011-11-09 12:28                   ` Sasha Levin
2011-11-09 12:36                     ` Pekka Enberg
     [not found]                     ` <alpine.LFD.2.02.1111091434230.4936@tux.localdomain>
2011-11-09 15:33                       ` Michael S. Tsirkin
2012-06-18 11:54                       ` Michael S. Tsirkin
2012-06-18 12:05                         ` Sasha Levin
     [not found]                         ` <1340021117.22848.3.camel@lappy>
2012-06-18 12:07                           ` Michael S. Tsirkin
2011-11-09 12:38               ` Avi Kivity
2011-11-09 12:48                 ` Sasha Levin
2011-11-09 15:19                   ` Michael S. Tsirkin
2011-11-09 15:51                   ` Michael S. Tsirkin
     [not found]                   ` <20111109151954.GA25329@redhat.com>
2011-11-13 14:07                     ` Ronen Hod
2011-11-13 20:40                 ` Vadim Rozenfeld
     [not found]             ` <1320832502.31056.22.camel@lappy>
2011-11-09 10:18               ` Michael S. Tsirkin
2011-11-09 10:20                 ` Sasha Levin
2011-11-09 10:47                   ` Pawel Moll
     [not found]                   ` <1320835653.3259.138.camel@hornet.cambridge.arm.com>
2011-11-09 10:55                     ` Sasha Levin
2011-11-09 11:06                       ` Pawel Moll
     [not found]                       ` <1320836793.3259.151.camel@hornet.cambridge.arm.com>
2011-11-09 11:39                         ` Peter Maydell
2011-11-09 12:07                         ` Sasha Levin
2011-11-09 19:59             ` [PATCHv2 " Michael S. Tsirkin
2011-11-09 20:00               ` Michael S. Tsirkin
2011-11-09 20:24               ` Sasha Levin
2011-11-09 20:52                 ` Michael S. Tsirkin
2011-11-09 20:57                   ` Sasha Levin
2011-11-09 21:14                     ` Michael S. Tsirkin
2011-11-09 21:13                       ` Sasha Levin
2011-11-10  8:55                         ` Michael S. Tsirkin
2011-11-11  4:24                     ` Rusty Russell
     [not found]                     ` <87aa83qoao.fsf@rustcorp.com.au>
2011-11-11  7:39                       ` Sasha Levin
2011-11-11 12:59                         ` Michael S. Tsirkin
2011-11-11 13:06                           ` Pawel Moll
2011-11-15 23:58                         ` Rusty Russell
2011-11-16  7:21                           ` Michael S. Tsirkin
2011-11-16  8:17                             ` Sasha Levin
2011-11-16  9:09                               ` Michael S. Tsirkin
2011-11-11 13:03                       ` Michael S. Tsirkin
2011-11-13 15:14                       ` Michael S. Tsirkin
2011-11-14  6:59                         ` Michael S. Tsirkin
2011-11-15 23:58                         ` Rusty Russell
2011-11-16  7:03                           ` Michael S. Tsirkin
2011-11-10 12:24               ` [PATCHv3 " Michael S. Tsirkin

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).