|
[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)
- 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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |