On Thu, Aug 16, 2007 at 05:26:58PM -0600, Alex Williamson wrote:
> On Thu, 2007-08-16 at 17:46 +0900, Simon Horman wrote:
> > This series of pattches to allows EFI runtime regions to be mapped into the
> > same place that they are maped into in Linux. The reson for this is
> > descripbed in the last patch. The rest of the patches are various
> > peices of infastructure needed for the last patch to function.
> >
> > I am particularly interested in comments on the approach in general - as
> > discussed in the comment in the last patch - and the implementation of the
> > changes to the page_fault handler in the second last patch.
>
> Hi Simon,
>
> How much of this is the same as intended for upstream Linux/ia64
> kexec? Specifically, is that why sal_stub.S is put in linux-xen even
> though it doesn't exist upstream yet? BTW, there are references to PAL
> in there that I think need s/PAL/SAL/. Is calling PAL in physical mode
> when efi_phys == 1 handled by a separate patch?
I have posted these patches upstream, quite a long time ago,
and the response wasn't great. At that time I envisaged that
just using physical SAL calls would be the answer. But as
the Linux people didn't like that idea too much, I have been looking
at other options, hence the always map where Linux would approach.
As it is, this physical SAL stuff isn't needed for kexec to function
in Linux. Actually, its only needed in Xen so that mapping the
EFI regions can be delayed until after paging is fully set up.
I had little luck isolating exactly why the page fault handler bombed
out if EFI was mapped into guest space early on, but this may well
be a solvable problem, which would allow the physical mode stuff to
go away.
That said, currently the Linux code (and Xen I imagine) tries
to keep going with physical mode PAL calls if the EFI mapping fails.
I guess that the EFI mapping must never fail because without the
patches I provide Linux has no way of making physical mode EFI calls.
To answer your question more directly, very little of this code
is indended for upstream, as this code primarily facilitates Xen
being modified to accomodate Linux, without Linux needing to be
modified. This approach is certainly up for debate, though arguably
it makes some sense.
> It looks like we're making the assumption that calling
> SetVirtualAddressMap using the same set of virt-to-phys mappings between
> Linux and Xen will work. Is this known to be true? Is it spec'd? I'm
> a little concerned that the subsequent calls are going to blowup even if
> using the same mappings, and we'll just go back to using efi_phys. I
> agree with wanting to isolate changes to Xen, but patch 5 still feels a
> bit like a can of worms. Thanks,
The idea is that SetVirtualAddressMap is only ever called once,
on the first boot. The call on subsequent boots is avoided by
either putting logic around the call to see if efi is already mapped,
or as is currently the case in upstream Linux, having purgatory
(the bit of kexec that runs between the two kernels) replace
SetVirtualAddressMap with a dummy routine that always returns true.
The assumption is that calling SetVirtualAddressMap a second time
will always fail, regardless of the inputs. So we don't do that.
The patches to effect these changes weren't included in the series
that I posted yesterday. I can post the full series that includes
this change if you like.
A slightly out of date version is here:
http://www.vergenet.net/linux/kexec/ia64-xen/20070713/broken_out/
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home