[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.