From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: How many patches are missing in upstream Linux? Date: Mon, 10 Mar 2014 13:55:57 -0700 Message-ID: <531E26DD.5030807@goop.org> References: <53185E4D0200007800121725@nat28.tlf.novell.com> <20140306192610.GI9852@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WN7Ew-0003Tg-IY for xen-devel@lists.xenproject.org; Mon, 10 Mar 2014 20:56:05 +0000 In-Reply-To: <20140306192610.GI9852@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Jan Beulich , david.vrabel@citrix.com, boris.ostrovsky@oracle.com, daniel.kiper@oracle.com Cc: Yang Z Zhang , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org On 03/06/2014 11:26 AM, Konrad Rzeszutek Wilk wrote: > Being worked on are: > - EFI (Daniel Kiper, CC-ed) This has been a blocker for me. My new laptop is EFI booting, so I haven't been running Xen on it for the last few months. I don't have much time for deep work on it, but I'm happy to be a test subject. > - perf (Boris Ostrovsky, CC-ed). > - user mode accessible PV clock (Boris or me) I did have some work on this, but I don't remember how far it got. I think it stumbled on having a mechanism to allow usermode to detect it had switched physical cpus. Is this a continuation of my patches or a new attempt? > The maintainer is being : > - runtime microcode. What I had been told was to use the 'early > microcode' mechanism - which is now implemented and Xen can also scan > the initramfs to extract the microcode payload and apply it. I've never got that to work, but ucode=-1 with a microcode.dat multiboot modules works pretty well. > But it misses the important part of server longevity in that the > host might be running for years and the microcode might need to be > updated during that time. bpetkov wasn't too thrilled about the > runtime microcode and I hadn't come back to this yet to figure out > what are his exact technical misgivings. I think, in the end, he (and Ingo) were advocating just doing a full emulation of the Intel/AMD update mechanism in the set/getmsr PV callbacks. Which is doable but... well, not pretty. Maybe a new attempt with get a new reception. J > > > > MSI-X - I presume you are referring to > http://comments.gmane.org/gmane.comp.emulators.xen.devel/170534 > > That had been taking me through so many twists and turns. The only > machine I had which manifested this was an Intel SandyBridge Desktop. But of > course the BIOS does not do SR-IOV. But no worry - I implemented the > 'assign-busses' mechanism to do what the BIOS couldn't do (expand the > bus numbers). Great, now I do finally see the issue. And the patch > I had posted for Linux (which is in Linux 3.14) solves the problem > part-way. I had been mulling this a bit but don't have yet a good > solution. > > So many things, so little time. Zhang are you able to help with some of > these? >>> that information? >> A few more that I know of: >> >> - EFI >> - user mode accessible PV clock >> - runtime microcode loading >> - support for running with more than 1Tb (XEN_ELFNOTE_INIT_P2M) >> (but afaict there are also shortcomings needing fixing in the tools >> when going beyond 512Gb) >> - support for using huge initrd (XEN_ELFNOTE_MOD_START_PFN) >> - blktap (or a suitable replacement thereof) >> - pvSCSI >> - pvUSB >> - perf/oprof >> >> Plus various smaller items where e.g. certain special drivers need >> adjustments to work right in dom0 (dcdbas, dell_rbu, coretemp, >> via-cputemp, msr). >> >> Also I'm not certain whether the MSI-X issue that was found a while >> ago is meanwhile fully fixed. >> >> Jan >> > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >