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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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

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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
>


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