Re: [Xen-devel] [PATCH RFC V2 4/6] xen: Support for VMCALL mem_events

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.03.15 at 14:50, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 07/11/2014 08:23 PM, Andrew Cooper wrote:
>> From the point of view of your in-guest agent, it would be a vmcall with
>> rax = 34 (hvmop) rdi = $N (send_mem_event subop) rsi = data or pointer
>> to struct containing data, depending on how exactly you implement the
>> hypercall.
>> 
>> You would have the bonus of being able to detect errors, e.g. -ENOENT
>> for "mem_event not active", get SVM support for free, and not need magic
>> numbers, or vendor specific terms like "vmcall" finding their way into
>> the Xen public API.
> 
> Actually, this only seems to be the case where mode == 8 in
> hvm_do_hypercall() (xen/arch/x86/hvm/hvm.c):
> 
> 4987                      : hvm_hypercall64_table)[eax](rdi, rsi, rdx,
> r10, r8, r9);
> 
> Otherwise (and this seems to be the case with my Xen build), ebx seems
> to be used for the subop:
> 
> 5033         regs->_eax = hvm_hypercall32_table[eax](ebx, ecx, edx, esi,
> edi, ebp);
> 
> So, ebx needs to be $N (send_mem_event subop), not rdi. Is this intended
> (rdi in one case and ebx in the other)?

Of course - the ABIs (and hence the use of registers for certain
specific purposes) of ix86 and x86-64 are different. Since there
are hypercall wrappers in both the kernel and the tool stack, you
shouldn't actually need to care about this on the caller side. And
the handler side doesn't deal with specific registers anyway
(outside of hvm_do_hypercall() that is).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel