Re: [Xen-devel] HVM hypercalls, hvm_hypercall_table

[Keir Fraser <keir@xxxxxxxxxxxxx>]

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.3.0.3.0) 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel