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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Mar 10, 2014 at 01:55:57PM -0700, Jeremy Fitzhardinge wrote:
> 
> 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.

Odd. It should be fairly easy with the newest version of dracut. Just
add this in your /etc/dracut.conf

early_microcode="yes"

and obviously in your grub.cfg (/etc/default/grub) add on the Xen command line
GRUB_CMDLINE_XEN="scan=ucode"

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

I did look at that. And realized to make that work I would have to implement
the full parsing of microcode that the existing microcode code does.

Fortunatly the hypervisor does that already - so it would be possible for 
Xen to intercept the MSRs and just store the payload in some structure - and
when completed then run the microcode verify to see if it matches.

But it was not clear to me how to figure out whether we are done with
the 'upload' unless I do some early parsing of the microcode to figure
out the length. Which then means adding extra plumbing in the microcode API
in Xen.

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