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

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 03/17/2015 03:58 PM, Jan Beulich wrote:
>>>> On 17.03.15 at 14:50, <rcojocaru@bitdefender.com> 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).

Yes, but Andrew's idea (which I think is very neat) is that instead of
the trickery I used to do in the original patch (create a specific
VMCALL vm_event and compare eax to a magic constant on VMCALL-based
VMEXITS, to figure out if all I wanted to do was send out the event),
that I should instead have the guest set up rax, rdi and rsi and execute
vmcall, which would then be translated to a real hypercall that sends
out a vm_event.

In this case, the (HVM) guest does need to concern itself with what
registers it should set up for that purpose. I suppose a workaround
could be to write the subop in both ebx and rdi, though without any
testing I don't know at this point what, if anything, might be broken
that way.


Thanks,
Razvan