From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini 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 16:03:56 +0100 Message-ID: References: <1571692646.20131009000945@eikelenboom.it> <1381320002.7600.10.camel@kazak.uk.xensource.com> <1043931136.20131009144924@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1043931136.20131009144924@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: Ian Campbell , Stefano Stabellini , George Dunlap , "xen-devel@lists.xen.org" , Lars Kurth , Anthony Perard List-Id: xen-devel@lists.xenproject.org On Wed, 9 Oct 2013, Sander Eikelenboom 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 > > 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 .. Thank you for the feedback. We need constructive criticism like this to improve the project and the way we handle things. Let me tell you where I stand. In the case of xl, we really thought that we filled all the gaps. Just when we were about to remove xend for good, people stepped up telling us to wait because actually we missed something. I don't think we could have done anything better, given the circumstances. If we don't know that we have a bug or a missing feature, we can't do anything about it. In the case of QEMU, we could probably have done a better job at tracking missing features. However in general once we know that we have an issue, we usually resolve it in a timely manner. Anthony wrote a blog post (http://blog.xen.org/index.php/2013/09/20/qemu-vs-qemu-traditional-update/) on this, but having a detailed well formatted wiki page listing everything we know is missing in upstream QEMU would go a long way toward avoiding situations like this in the future. The other thing that could help is better testing. OSSTests doesn't cover the xen_platform_pci option, otherwise we would have found and fixed the issues months ago. Anybody can write a new OSSTest, not just developers. Give a look at Wei's recent blog post: http://blog.xen.org/index.php/2013/09/30/osstest-standalone-mode-step-by-step/ Do you care about a particular feature? Do you want to make sure it doesn't break in xen-unstable? Write an OSSTest for it!