All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Lars Kurth <lars.kurth.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [HVM} xen_platform_pci=0 doesn't prevent platform device creation and disk and nic take over by PV drivers.
Date: Thu, 10 Oct 2013 11:03:34 +0100	[thread overview]
Message-ID: <CAFLBxZY5qN+e0J9j0ttQLb4aci08fbMvPE3TC73adC8enZf3Uw@mail.gmail.com> (raw)
In-Reply-To: <1043931136.20131009144924@eikelenboom.it>

On Wed, Oct 9, 2013 at 1:49 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>
> Wednesday, October 9, 2013, 2:00:02 PM, you wrote:
>
>> create ^
>> title it xen_platform_pci=0 doesn't work with qemu-xen
>> owner it Anthony Perard <anthony.perard@citrix.com>
>> thanks
>
> Perhaps in general looking at the libxl and xend .. and .. qemu-xen and qemu-xen-traditonal compatibility shoud be added too.
>
> Perhaps i'm a bit blunt ..
> but for users it's quite a mess and PITA now for quite some time, the transition of both is now smeared out over quite some major and minor releases.
>
> With some features not working since .. some features are working again but have a gap of not working,
> since old features becoming usable again are (understandably) not backported.
>
> This seems to be at a level that it is even undocumentable ... you would need a spreadsheet
> with every minor version to try to document that ... it seems to be leading to a lot of user questions as well.
>
> I'm not blaming any one personally or anything like that .. just expressing my worries and the threat i see for Xen as a project in general.
> Namely users sop
>
> I understand that new features like the arm port are interesting .. but i think that has the cost of both
> IanC and Stefano time to work on libxl and qemu-upstream seems to be quite limited, and perhaps developer time in general is.

FWIW, the ARM stuff isn't just "interesting" -- it was a critical
strategic opportunity for the future of the Xen project.  The work
that was done, particularly the political stuff done by Stefano to get
Xen into Linaro, was a major achievement at just the right time.  A
delay of even a few months may have meant that Xen had basically no
presence in ARM server space, which would in turn have had an impact
on the commercial viability of the Xen project as a whole.  The vast
majority of the money used to support Xen comes from the server
market.  Growing this market means more commercial interest in Xen,
which means more developers; missing this market could have knock-on
effects in the x86 space, which would have had a much bigger impact on
PCI pass-through in the long term.

 -George

  parent reply	other threads:[~2013-10-10 10:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1571692646.20131009000945@eikelenboom.it>
     [not found] ` <1381320002.7600.10.camel@kazak.uk.xensource.com>
2013-10-09 12:15   ` Processed: Re: [HVM} xen_platform_pci=0 doesn't prevent platform device creation and disk and nic take over by PV drivers xen
2013-10-11 15:04     ` Ian Campbell
2013-10-11 15:22       ` Sander Eikelenboom
2013-10-11 16:53         ` Anthony PERARD
2013-10-11 17:10           ` George Dunlap
2013-10-11 17:31             ` Anthony PERARD
     [not found]     ` <1381505587.24708.59.camel@kazak.uk.xensource.com>
2013-10-11 15:45       ` Processed: " xen
2013-10-09 12:49   ` Sander Eikelenboom
2013-10-09 15:03     ` Stefano Stabellini
2013-10-09 16:56       ` Sander Eikelenboom
2013-10-09 15:32     ` George Dunlap
2013-10-09 17:39       ` Sander Eikelenboom
2013-10-10 10:03     ` George Dunlap [this message]
     [not found] ` <alpine.DEB.2.02.1310091235150.26077@kaball.uk.xensource.com>
     [not found]   ` <1869834341.20131009135452@eikelenboom.it>
2013-10-09 14:16     ` Sander Eikelenboom

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=CAFLBxZY5qN+e0J9j0ttQLb4aci08fbMvPE3TC73adC8enZf3Uw@mail.gmail.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=lars.kurth.xen@gmail.com \
    --cc=linux@eikelenboom.it \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.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.