| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Xen/ia64: hypercall support
> I am talking about the "real hypercall" like IA32/XEN did for
> the para-virtualization.
Yes, I am talking about real hypercalls like Xen/x86 also.
Linux makes calls to EFI/PAL/SAL that must be virtualized
(for example: how many bits in region registers? what is
my memory map?). I just took a different approach which didn't
require changing the Linux source:
In vBlades, these calls were manually replaced (paravirtualized)
in the Linux source with hypercalls. However, part of the
vBlades research was to minimize the number of changes to the
guest while maximizing performance (optimized paravirtualization).
Since EFI/PAL/SAL calls are all table-based and well-architected,
I wondered (in vBlades) if the calls could be intercepted below
the guest so that the guest source need not be modified/para-
virtualized for these infrequent, non-performance-sensitive
calls. But when Xen was announced HP shelved vBlades so I
never got around to trying it out.
So, when developing Xen/ia64 I tried this technique and it
worked: No changes are made to the guest; when the guest is
loaded and started (using the standard elilo interface), the
EFI/SAL/PAL function tables it is given have been modified to
do a hypercall to Xen.
So there is already a "real hypercall" interface architected,
designed, and working in Xen/ia64. It is just indirectly
used and currently invisible to the guest. It will definitely
need to be made explicitly visible to improve performance.
I just wasn't focused on performance for the alpha release.
> For the EFI/SAL/PAL calls, maybe it is better
> to be implemented in guest BIOS.
Please explain further.
Thanks!
Dan
====
Dong, Eddie <eddie.dong <at> intel.com> writes:
>
> Hi, Dan:
> I am talking about the "real hypercall" like IA32/XEN did for
> the para-virtualization. For the EFI/SAL/PAL calls, maybe it is better
> to be implemented in guest BIOS.
> Eddie
>
> > Re hypercalls. Actually there are hypercalls already in Xen/ia64
> > and they do use the break instruction. It's just that the domain
> > calls them indirectly so perhaps they are better called "hyperthunks"
> > ("Thunk" is a rarely used compiler term which originated in Algol 60
> > that means: "code that is used to convert calls to one interface
> > into calls to another"):
> >
> > When a domain is created, fake EFI/SAL/PAL (firmware) calls are
> > created
> > that contain the hypercalls. Thus when domain0 invokes an EFI/SAL/PAL
> > call, it calls a "stub" routine that invokes a break instruction/fault
> > that is recognized in Xen/ia64 as a hypercall, with arguments passed
> > in general registers (unlike Xen/x86 which passes hypercall arguments
> > in memory).
> >
> > You may want to step through a domain0 firmware call to see this work.
> > If I recall correctly, the code that creates the hyperthunks is
> > in arch/ia64/dom_fw.c
> >
> > While my intent is to use the same mechanism (breaks) for "real"
> > hypercalls,
> > I also want to explore the use of fast system calls (recently added
> > in Linux/ia64 by David Mosberger) using the epc instruction in certain
> > cases.
> >
> > Dan
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home