|
|
|
|
|
|
|
|
|
|
xen-ia64-devel
[Xen-ia64-devel] Re: copying data to guest
Quoting Jes Sorensen <jes@xxxxxxx>:
> tgingold@xxxxxxx wrote:
> > The basic answer is you can't do that reliably.
> >
> > I don't have Xen code under my hand now, but there are a few examples in
> such
> > direct write for some PAL calls and some EFI calls.
> >
> > But they may fail: the TLB may not have the entry and there is currently no
> > way to recover from such a miss.
> >
> > The correct way is to use a xencomm descriptor. Of course, this requires
> some
> > modification in kernel code but much safer.
>
> Hi Tristan,
>
> I just don't follow this, if this is the case then we have a major
> problem. There are multiple SAL calls that are defined to take a kernel
> virtual address to receive a result or provide input data to the call.
> We need to be able to do this for domU's if we want to provide full
> virtualization so it's not really something we can avoid.
IMHO, the current implementation is slightly broken (ie not reliable).
> Given that Xen uses a 1:1 mapping for all physical memory, we ought to
> be able to simply take the virtual kernel address from the SAL call,
> which we should be able to reliably convert to a metaphysical address
> by walking the page tables,
We can't walk page tables on ia64!
> or in the case of Linux, we know it uses a
> 1:1 mapping, then convert the metaphysical address to a physical address
> and access that via the 1:1 mapping?
*IMHO* Xen shouldn't be aware of linux 1:1 mapping. Modules are not in the
1:1 mapping area too.
> Or am I missing something here?
Although this should work, it is currently not reliable. I think this issue
must be fully discussed.
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
|
|