On Thu, Sep 13, 2007 at 03:18:17PM +0900, Horms wrote:
> 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?
Note that I'm not sure this approach is possible or makes EFI/SAL/PAL
happy. It might not work because I haven't given a deep consideration it.
Presumably you know it better than me and others want to discuss on it.
Xen gives portion of usable rid to a guest, currently
IA64_MIN_IMPL_RID_BITS=18 bits. And it reserves one portion for its
own purpose (real mode emulation).
It means that a guest can only see virtual address of given rids.
and reserve rid for EFI
When we want to call EFI
- which the current rid to the rid for EFI
- call EFI
here tlb miss fault might occur, and we can distinguish the fault
caused by EFI call from guest domains by checking whether the current
rid is reserved for EFI.
- which back the previous rid
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home