WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [patch 00/14] Kexec v20070912: Xen

On Thu, Sep 13, 2007 at 12:24:22PM +0900, Isaku Yamahata wrote:
> On Thu, Sep 13, 2007 at 11:21:04AM +0900, Horms wrote:
> > On Wed, Sep 12, 2007 at 12:20:23PM -0600, Alex Williamson wrote:
> > > On Wed, 2007-09-12 at 17:08 +0900, Simon Horman wrote:
> > > > The following series is the Xen patches that comprise
> > > > the lastest release of kexec for ia64 Xen. Patches
> > > > for Linux-Xen, Linux and kexec-tools are posted separately.
> > > > 
> > > > All the patches and some documentation on building
> > > > and running kexec can be found at:
> > > 
> > > Hi Simon,
> > > 
> > >    Thanks for your continued work on kexec.  I share Tristan's concern
> > > of mapping EFI into an HVM guest accessible space.  If we can prove that
> > > can't happen or can find a way to prevent it, I'm reasonable happy with
> > > this series (a few comments to follow separately).  If we can't get the
> > > EFI mapping resolved right away, lets figure out what patches are
> > > independent of that so you don't have to continue to manage all of these
> > > out of the tree.  Thanks,
> > 
> > Hi Alex,
> > 
> > thanks so much to you and others for your comments. I'll work my
> > way through them and comment on each in turn.
> > 
> > With regards to the EFI mapping problem, I think that it is fair to
> > say that this is the most difficult problem facing the code. I am of
> > the opinion that the current solution is the best one available.
> > 
> > The previous solution was to not map EFI and always make SAL
> > calls in physical mode. But this is problematic for a number of reasons
> > including:
> > - I'm not sure that it'll work on SN because it allows kernel-supplied
> >   EFI routines - I haven't worked through the details of this.
> > - Its a pain to configure. If you think you may ever want to Kexec or
> >   Kdump from Xen to Linux or Linux to Xen then you need to turn
> >   the phys_efi option on. Else its optional.
> > 
> > That said, while I think that the current approach is the best
> > one so far, I'm not entirely convinced that there isn't a better idea.
> > If people could scratch their heads a bit, that would be great.
> 
> I think the EFI mapping isn't protected from VTi domain as Tristan
> pointed out.
> One Idea addressing the issue is that reserve rids dedicated for
> mapping EFI and switch rid before/after calling EFI in xen.
> This approach may require some more effort. It would be problematic.
> However it can be worked on independently, I suppose.

I'm happy to explore all avenues. Could you give me a little more
information on what you mean by reserving rids?

> Given that the physical mode EFI approach is working
> (please correct if I'm wrong), we can merge some of his patches and
> address the EFI mapping issue later.
> It's burden to maintain the long patch series.
> 
> What do you think?

Personally I'd rather keep the alternate-EFI-map patches for now.
But if you prefer the phys_efi approach I can put those patches back in my
series and take out the alternate-EFI-map patches. In the longer
run I doubt that phys_efi will ever get merged into Linux, which
is one reason that I'd prefer not to use them.

-- 
宝曼 西門 (ホウマン・サイモン) | Simon Horman (Horms)

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel