| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
Re: [Xen-ia64-devel] Re: copying data to guest
On Mon, Mar 05, 2007 at 02:43:04PM +0100, Jes Sorensen wrote:
> > Tristan.
>
> Thought a bit more about this. I whipped up some code last week that
> relied on the 1:1 mapping knowledge which you don't like. I agree it's
> not ideal, however we have a real issue with the fact that some current
> SAL calls expect a kernel virtual address. We simply won't be able to
> provide full VT support if we cannot come up with a way to do this in
> a reliable manner :(
I don't understand you on this point. From the hypervisor POV, there is
almost no differences between dom0, domU and dom-VT concerning this point.
> I may be able to convince our PROM team to change the SAL calls that are
> SN2 specific to take physical addresses.
This will not change anything I fear. Can you explain what do you expect ?
> However even when taking
> physical (or metaphysical addresses) can we reliably access the memory?
> I presume we can? But what about the generic calls?
Maybe we misunderstand. Xen has a 1:1 map of the physical memory in virtual
memory like linux. The problem is Xen doesn't know the full virtual memory
mapping of a domain.
> Xencomm is fine for dom0 stuff, but not for domUs.
There is no difference between dom0 and domU here. Maybe I misunderstood
something.
> Well fine is a
> relative term here, the Xencomm API is probably the most ugly part of
> Xen I have come across so far :(
Xencomm code is scather among linux and the hypervisor. Xencomm has three
methods to do the work. Xencomm tries to be platform independant. All these
things make things not easy to follow but Xencomm is not complex. Roughly
speaking it is just a virtual to meta-physical translation of buffers.
>From your mails I have the impression we don't understand each other.
Xencomm tries to solve a simple ia64 specific issue: domain virtual addresses
can't be used realiabily in the hypervisor because the TLB entries may be
missing. Trying to inject TLB miss doesn't work well because all the code
is not designed to be re-startable (PAL and SAL is not for example). The
other solution is to translate virtual address to (meta) physical addresses and
to use them. This is Xencomm.
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home