xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com,
	daniel.kiper@oracle.com
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: How many patches are missing in upstream Linux?
Date: Thu, 6 Mar 2014 14:26:11 -0500	[thread overview]
Message-ID: <20140306192610.GI9852@localhost.localdomain> (raw)
In-Reply-To: <53185E4D0200007800121725@nat28.tlf.novell.com>

On Thu, Mar 06, 2014 at 10:38:53AM +0000, Jan Beulich wrote:
> >>> On 06.03.14 at 06:21, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> > Do you know how many features or patches are still missing in upstream 
> > Linux? I know some of them, like hugepage support, TS bit issue and PAT 
> > issue. But I guess I only known part of them. Is there any wiki page to track 

It might make sense to split this in five categories: Being worked on,
PVH can fulfill that, Hadn't looked at, and 'Simple enough - but it
would fantanstic if somebody could spare some time to look at it', the
maintainer is being <insert your own opinion here>..

If anybody is interested in helping, this list should give a good idea.
It would be quite helpful to have more folks look at some of these.

Being worked on are:
 - EFI (Daniel Kiper, CC-ed)
 - perf (Boris Ostrovsky, CC-ed).
 - user mode accessible PV clock (Boris or me)
 - XEN_ELFNOTE_INIT_P2M, XEN_ELFNOTE_MOD_START_PFN - I had been looking
   at that but I can't figure out a nice way of implementing this
   without the usage of SPARSEMAP_VMAP virtual addresses - which is how
   the classic Xen does it. But then - I don't know who is using huge PV
   guests - as the PVHVM does a fine job? But then with PVH, now you can
   boot with large amount of memory (1TB?) - so some of these issues
   would go away? Except the 'large ramdisk' as that would eat in the
   MODULES_VADDR I think? Needs more thinking.


PVH can do it:
 - PAT (it works right out of the box).
 - hugepages support (1Gb, 2MB, etc - all works!)
 - TS bit issue (works too).

Simple enough - but it would fantastic if somebody could spare some
time:
 - PAT - hpa suggested a nice way of making this work. It involes a sort
   of software lookup of WC, WP, UC bits. The complexity comes when it
   you have to deal with it on 4th and 3rd level pagetables and which
   bit to flip. But now that I think of, it should be as easy as having:

    pte_t get_bit_for_wc(int level)
   or such. That would allow PV guests to run this.

- TS bit issue. David Vrabel was mulling this one over. (CC-ed).

Hadn't looked at:
 - pvSCSI,
 - pvUSB
 - blktap (My recolleciton is that Citrix is just carrying the old
   patchset around - but the end goal would be for QEMU to do all
   of this - but they haven't found somebody willing to do a lot
   of the work in this).

Hadn't heard of before:
 - dcdbas
 - rbu
 - coretemp,
  -via-cputemp
Sounds like those driver just need a bit of fixes then? Perhaps their
issues have now been resolved with the 1-1 mapping and the latest set of
patches that David Vrabel had posted? Which makes the P2M code much more
smarter?

The maintainer is being <insert your own opinion here>:
 - 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.

   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.



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
> 

  parent reply	other threads:[~2014-03-06 19:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  5:21 How many patches are missing in upstream Linux? Zhang, Yang Z
2014-03-06 10:38 ` Jan Beulich
2014-03-06 13:47   ` Fabio Fantoni
2014-03-06 19:26   ` Konrad Rzeszutek Wilk [this message]
2014-03-06 19:36     ` David Vrabel
2014-03-06 19:39       ` Konrad Rzeszutek Wilk
2014-03-07  1:35         ` Zhang, Yang Z
2014-03-07  1:49     ` Zhang, Yang Z
2014-03-07  9:16     ` Jan Beulich
2014-03-10 20:55     ` Jeremy Fitzhardinge
2014-03-11 15:04       ` Konrad Rzeszutek Wilk
2014-03-11 16:15         ` Jan Beulich
2014-03-11 17:38           ` Konrad Rzeszutek Wilk
2014-03-11 17:38       ` Atom2
2014-03-11 17:53         ` Konrad Rzeszutek Wilk
2014-03-11 18:35           ` Atom2
2014-03-11 20:33             ` Konrad Rzeszutek Wilk
2014-03-12  1:00               ` Atom2
2014-03-12  8:20                 ` Jan Beulich
2014-03-12 11:14                   ` Atom2
2014-03-12 11:42                     ` Jan Beulich
2014-03-12 11:58                       ` Atom2
2014-03-12 13:50                         ` Konrad Rzeszutek Wilk
2014-03-12 15:09                           ` Atom2
2014-03-12 16:30                             ` Konrad Rzeszutek Wilk
2014-03-11 13:32     ` Ian Campbell
2014-03-11 15:09       ` Konrad Rzeszutek Wilk

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=20140306192610.GI9852@localhost.localdomain \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yang.z.zhang@intel.com \
    /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).