Messages in this thread | | | Subject | Re: [PATCH] xen/x86: Adjust stack pointer in xen_sysexit | From | Boris Ostrovsky <> | Date | Mon, 16 Nov 2015 15:31:52 -0500 |
| |
On 11/16/2015 02:03 PM, Andy Lutomirski wrote: > It's still a waste of effort, though. Also, I'd eventually like the > number of places in Xen code in which rsp/esp is invalid to be exactly > zero, and this approach makes this harder or even impossible.
That's what PVH is going to do.
> Does PVH hook into the entry asm code at all? I thought it was just > boot code and drivers.
Not the current version --- it starts with xen_start_kernel(). But we are currently changing it and my plan is to have a small stub executed initially (to set bootparams and such) and then jump to startup_{32|64}().
> > In any case, someone needs to do some serious review and cleanup on > the whole paravirt op mess. We have a bunch of paravirt ops that > serve little purpose. > > The paravirt infrastructure is a bit weird, too: it seems to > effectively have four states for each patch site. There's: > > 1. The initial state, which is unoptimized and works on native. > Presumably any of these that happen early also need to work, if > slowly, on Xen.
Not on PV (and as of today, on PVH) --- we start directly from xen_start_kernel(). I.e. from step 2.
> > 2. The Xen state without text patching. I'm not actually sure why > this exists at all. Are there pvops that need to switch too early for > us to patch the text?
I don't think so.
-boris
| |