On 03/17/2015 04:20 PM, Jan Beulich wrote: >>>> On 17.03.15 at 15:07, <rcojoc...@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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
