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. 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)? Why there is just those six hypercalls implemented as HVM-hypercalls? Thanks. George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > George Surka > Sent: 15 March 2007 19:31 > To: xen-devel@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@amd.com] Sent: Thursday, March 15, 2007 3:39 PM To: George Surka; xen-devel@lists.xensource.com Subject: RE: [Xen-devel] HVM hypercalls, hvm_hypercall_table> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of George > Surka > Sent: 15 March 2007 19:31 > To: xen-devel@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@marathontechnologies.com> 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@amd.com] > Sent: Thursday, March 15, 2007 3:39 PM > To: George Surka; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] HVM hypercalls, hvm_hypercall_table > > > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of George >> Surka >> Sent: 15 March 2007 19:31 >> To: xen-devel@lists.xensource.com >> 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel