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

[Razvan Cojocaru <rcojocaru@bitdefender.com>]

On 03/17/2015 04:20 PM, Jan Beulich wrote:
>>>> On 17.03.15 at 15:07, <rcojocaru@bitdefender.com> wrote:
>> 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.
> 
> If you think about a bare HVM guest OS (i.e. without any PV
> drivers), then of course you should provide such hypercall
> wrappers for code to use instead of open coding it in potentially
> many places.
> 
>> 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.
> 
> Guest code ought to know what mode it runs in. And introspection
> code (in case this is about injection of such code) ought to also
> know which mode the monitored guest is in.

Yes, we'll try to handle this, I was mainly asking because based on
Andrew's suggestion (which only mentioned rdi, not ebx) I wanted to make
sure that this is not someting that people might prefer to change at Xen
source code level.


Thanks for the clarification,
Razvan