All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sander Eikelenboom <linux@eikelenboom.it>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Pasi Kärkkäinen" <pasik@iki.fi>,
	"Lars Kurth" <lars.kurth.xen@gmail.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.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: Wed, 9 Oct 2013 14:49:24 +0200	[thread overview]
Message-ID: <1043931136.20131009144924@eikelenboom.it> (raw)
In-Reply-To: <1381320002.7600.10.camel@kazak.uk.xensource.com>


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.

But getting these major transitions smeared out over several major and minor releases doesn't seem to be very desirable.
This will be enlarged since distro's like debian are going to stop packaging the xen-forks. But since they will be using a "stable" release for these
projects like qemu, i will take some time for xen patches to for instance qemu to trickle down into the qemu-upstream stable.

(BTW debian unstable already seems to be not packaging qemu-traditional anymore but rely on the upstream qemu package entirely,
leading to questions on IRC already )

KVM seems to have it's act quite together with their virtio drivers at the moment and i must say i'm getting
attracted to try to switch (although i generally like Xen so i'm still in denial :-) ).

Just my few cents and a call out as a user ..
(and perhaps a topic for the developer conference to address .. also in the light of the short discussion about a long term stable release
which in my opinion can't be done before both are resolved)

Don't know how Pasi thinks about this and if he has any comments, since he seems to be quite involved in (helping) the user community ..

--
Sander



> On Wed, 2013-10-09 at 00:09 +0200, Sander Eikelenboom wrote:
>> Hi,
>> 
>> While trying to get to the bottom of my passthrough problem with the rom bar,
>> i noticed that specifiying "xen_platform_pci=0" in the config file does not prevent
>> the platform device to appear in my HVM guest and consequently the disk and nic are taken over.
>> 
>> Running latest xen-unstable, together with upstream qemu and upstream seabios.
>> 
>> --
>> 
>> Sander
>> 

  parent reply	other threads:[~2013-10-09 12:49 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 [this message]
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
     [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=1043931136.20131009144924@eikelenboom.it \
    --to=linux@eikelenboom.it \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=lars.kurth.xen@gmail.com \
    --cc=pasik@iki.fi \
    --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.