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. 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? -- yamahata _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
