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

Re: [Xen-devel] HVM hypercalls, hvm_hypercall_table

What are you trying to do? It's not normal for domU's (even fully
paravirtualised ones) to need to do grant-table hypercalls. Granting access
to your own memory is done entirely via intercations via shared memory, with
no hypercalls at all.

 -- Keir

On 15/3/07 19:49, "George Surka" <gsurka@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

> For instance we need grant table operations for our PV drivers. Those
> are not currently supported as HVM-hypercalls.
> George 
> -----Original Message-----
> From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
> Sent: Thursday, March 15, 2007 3:39 PM
> To: George Surka; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] HVM hypercalls, hvm_hypercall_table
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of George
>> Surka
>> Sent: 15 March 2007 19:31
>> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: [Xen-devel] HVM hypercalls, hvm_hypercall_table
>> Hi everyone,
>> I am running XenEnterprise 3.1.0 (Xen v. on x86-32 hardware. I
>> have noticed that the hvm_hypercall_table is initialized for only 6
>> hypercalls (memory_op, multicall, xen_version, event_channel_op,
>> sched_op, and hvm_op). The hypercall_page for HVM domain is
>> initialized with HVM exit (VMCALL instr.) - all stubs.
> The purpose of the hvm_hypercall_table is to support para-virtual
> drivers. 
> You should (generally speaking) not be making other hypercalls from a
> fully-virtualized (HVM) domain, as those are potentially not safe. Is
> ther a particular hypercall you're after, or is this a generic question
> as to why this is?
>> So, how do I do the other hypercalls (beyond those 6) from HVM domain?
>> Do I just have to use INT 0x82 trap without using the hypercall-page
>> (without using the HYPERVISOR_* hypercall macros in hypercall.h)?
> No, you can't make any other hypercalls from fully virtualized domains.
> If you need further hypercalls, it may be possible to add further
> hypercalls, but I don't believe that a "wholesale" implementation of all
> hypercalls available to para-virtual Xen will make sense (and in some
> cases would be potentials for crashing the guest and/or hypervisor), so
> selective implementation is the key here.
> [Many of the hypercalls are implemented to overcome the same problems
> that the hardware solves in fully virtualized domains, so duplicating
> the solution doesn't actually help anything - just adds more code!]
> --
> Mats
>> Why there is just those six hypercalls implemented as HVM-hypercalls?
>> Thanks.
>> George
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list



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