All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>,
	david.vrabel@citrix.com, boris.ostrovsky@oracle.com,
	daniel.kiper@oracle.com
Cc: Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: How many patches are missing in upstream Linux?
Date: Mon, 10 Mar 2014 13:55:57 -0700	[thread overview]
Message-ID: <531E26DD.5030807@goop.org> (raw)
In-Reply-To: <20140306192610.GI9852@localhost.localdomain>


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

  parent reply	other threads:[~2014-03-10 20:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  5:21 How many patches are missing in upstream Linux? Zhang, Yang Z
2014-03-06 10:38 ` Jan Beulich
2014-03-06 13:47   ` Fabio Fantoni
2014-03-06 19:26   ` Konrad Rzeszutek Wilk
2014-03-06 19:36     ` David Vrabel
2014-03-06 19:39       ` Konrad Rzeszutek Wilk
2014-03-07  1:35         ` Zhang, Yang Z
2014-03-07  1:49     ` Zhang, Yang Z
2014-03-07  9:16     ` Jan Beulich
2014-03-10 20:55     ` Jeremy Fitzhardinge [this message]
2014-03-11 15:04       ` Konrad Rzeszutek Wilk
2014-03-11 16:15         ` Jan Beulich
2014-03-11 17:38           ` Konrad Rzeszutek Wilk
2014-03-11 17:38       ` Atom2
2014-03-11 17:53         ` Konrad Rzeszutek Wilk
2014-03-11 18:35           ` Atom2
2014-03-11 20:33             ` Konrad Rzeszutek Wilk
2014-03-12  1:00               ` Atom2
2014-03-12  8:20                 ` Jan Beulich
2014-03-12 11:14                   ` Atom2
2014-03-12 11:42                     ` Jan Beulich
2014-03-12 11:58                       ` Atom2
2014-03-12 13:50                         ` Konrad Rzeszutek Wilk
2014-03-12 15:09                           ` Atom2
2014-03-12 16:30                             ` Konrad Rzeszutek Wilk
2014-03-11 13:32     ` Ian Campbell
2014-03-11 15:09       ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=531E26DD.5030807@goop.org \
    --to=jeremy@goop.org \
    --cc=JBeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yang.z.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.