Xen devel - Dec 2006 - Call hypercall straightly from user space

Hi keir,

As you mention before, we may call hypercall straightly from user space 
rather than bouncing through guest kernel.

I''m planning to do this.

I want to modifty three hypercalls first.( I think they are frequently
used).
1. send_event_pending,
2. hvm_set_isa_irq_level,
3. hvm_set_pci_intx_level.


In the first hypercall, it sends port through pointer rather than value.
Thus it''s difficult to call send_event_pending from user space due to 
there is no similar mechanism as xencomm in user space.

Is it possible we pass port through value in send_event_pending
hypercall?

If you agree.
I would like to do this.


--Anthony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/12/06 8:03 am, "Xu, Anthony" <anthony.xu@intel.com> wrote:
> I want to modifty three hypercalls first.( I think they are frequently
> used).
> 1. send_event_pending,
> 2. hvm_set_isa_irq_level,
> 3. hvm_set_pci_intx_level.
> 
> 
> In the first hypercall, it sends port through pointer rather than value.
> Thus it''s difficult to call send_event_pending from user space due
to
> there is no similar mechanism as xencomm in user space.
> 
> Is it possible we pass port through value in send_event_pending
> hypercall?
It would have to be a new hypercall, for backward compatibility and also
because the event-channel hypercall has a function prototype that takes a
pointer: we don''t really want hypercall functions with different
prototypes
multiplexing onto the same hypercall. Also it sounds like you want to do
this for all three commands you mention above, and presumably any more that
seem commonly used in future. That being the case, perhaps you need a
well-defined register-based ABI for all ia64 hypercalls (e.g., first N bytes
of the first pointer-passed structs/values passed to a hypercall are
re-packed into a subset of the IA64''s register space). The disadvantage
here
is the need for IA64-specific repacking on the Xen and the guest sides of
the hypercall interface, unless we could think of some very cunning way to
avoid it. But the smaller changes you propose would likely end up being
IA64-specific anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/12/06 11:27 am, "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>
wrote:
> That being the case, perhaps you need a
> well-defined register-based ABI for all ia64 hypercalls (e.g., first N
bytes
> of the first pointer-passed structs/values passed to a hypercall are
> re-packed into a subset of the IA64''s register space). The
disadvantage here
> is the need for IA64-specific repacking on the Xen and the guest sides of
> the hypercall interface, unless we could think of some very cunning way to
> avoid it.
Another option would be for the guest user space to know the virt->machine
mapping for some of its address space, and use that as a pool to allocate
hypercall buffers from. Then user space could fill in the xencomm
descriptors for itself.

This would need special allocation in libxc for hypercall buffers (since
they would need to come from a pinned pool of memory for which libxc knows
the v->m mapping) but we want to add this anyway, even for x86 (to reduce
number of mlock/munlock calls we make).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, Dec 30, 2006 at 04:03:19PM +0800, Xu, Anthony
wrote:
> Hi keir,
> 
> As you mention before, we may call hypercall straightly from user space 
> rather than bouncing through guest kernel.
Hi,

I haven''t found the reference, but how security is addressed ?  How to
prevent
a user process from making such hypercalls ?

Tristan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 30/12/06 3:22 pm, "Tristan Gingold" <tgingold@free.fr> wrote:
>> As you mention before, we may call hypercall straightly from user space
>> rather than bouncing through guest kernel.
> Hi,
> 
> I haven''t found the reference, but how security is addressed ? 
How to prevent
> a user process from making such hypercalls ?
It would have to be enabled on a per-process basis by the guest kernel,
presumably during context switch.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser write on 2006年12月30日 23:58:
> On 30/12/06 3:22 pm, "Tristan Gingold" <tgingold@free.fr>
wrote:
> 
>>> As you mention before, we may call hypercall straightly from user
>>> space rather than bouncing through guest kernel.
>> Hi,
>> 
>> I haven''t found the reference, but how security is addressed ?
How
>> to prevent a user process from making such hypercalls ?
> 
> It would have to be enabled on a per-process basis by the guest
> kernel, presumably during context switch.
And only user process on dom0 can do this.

--Anthony
> 
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser write on 2006年12月30日 20:30:
> On 30/12/06 11:27 am, "Keir Fraser"
<Keir.Fraser@cl.cam.ac.uk> wrote:
> 
>> That being the case, perhaps you need a
>> well-defined register-based ABI for all ia64 hypercalls (e.g., first
>> N bytes of the first pointer-passed structs/values passed to a
>> hypercall are re-packed into a subset of the IA64''s register
space).
>> The disadvantage here is the need for IA64-specific repacking on the
>> Xen and the guest sides of the hypercall interface, unless we could
>> think of some very cunning way to avoid it.
> 
> Another option would be for the guest user space to know the
> virt->machine mapping for some of its address space, and use that as
> a pool to allocate hypercall buffers from. Then user space could fill
> in the xencomm descriptors for itself.
> 
> This would need special allocation in libxc for hypercall buffers
> (since they would need to come from a pinned pool of memory for which
> libxc knows the v->m mapping) but we want to add this anyway, even
> for x86 (to reduce number of mlock/munlock calls we make).

Thanks for your suggestions.
I would like to add another wrapper for some hypercalls, 
And after hypercall buffer is implemented, then I''ll follow it.

Thanks,
Anthony
> 
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel