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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Konrad Rzeszutek Wilk wrote on 2014-03-07:
> 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.

Thanks for providing the information.
I think it's better to list them on wiki for people to check. Because I have 
been asked by customers to solve the problem often and the root-cause turns out 
to be the issue we already known but customer didn't aware of them. Especially 
for TS issue, I saw it from three different customers. The customers usually 
use the stable Linux as dom0 directly without any additional patch and they 
even don't know there are known issues for upstream Linux(There is no way for 
them to get it). So if we can put it in wiki, I think it will help them a lot.

> 
> So many things, so little time. Zhang are you able to help with some of these?

I hope I can. But there also lots of task waiting for me. :(

>>> 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
>>


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel