[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] How many patches are missing in upstream Linux?

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@xxxxxxxxx> 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)
   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
 - 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,
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

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

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

So many things, so little time. Zhang are you able to help with some of
> > 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.