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