Re: [PATCH] arm/monitor vm-events: Implement guest-request support

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.02.16 at 12:26, <czuzu@bitdefender.com> wrote:
> On 2/22/2016 12:14 PM, Jan Beulich wrote:
>>>>> On 19.02.16 at 19:01, <czuzu@bitdefender.com> wrote:
>>> On 2/19/2016 7:15 PM, Jan Beulich wrote:
>>>>>>> On 19.02.16 at 17:25, <czuzu@bitdefender.com> wrote:
>>>>> On 2/19/2016 4:26 PM, Jan Beulich wrote:
>>>>>>>>> On 18.02.16 at 20:35, <czuzu@bitdefender.com> wrote:
>>>>> On the "HVM-ish" note, is there some incompatibility between ARM and the
>>>>> concept of HVM?
>>>> ARM guests are neither PV nor HVM right now, but somewhere in
>>>> the middle (PVHv2 may come closest).
>>> I did not know that, but the fact that there is already "hvm-like" code
>>> written for ARM didn't hint me towards that fact either :)
>>> I'm aware that I'm far from familiar with the codebase right now, I'm
>>> browsing more of the code these days and taking notes to try and
>>> understand in depth at least the parts I'm sending contributions for.
>>> I've already got some questions I want to post to the mailing list soon,
>>> *including* exactly how the distinction between the guest-types comes
>>> into play w/ the vm-events code.
>>> Specifically, I'm talking for example about the following piece of code
>>> from the X86 arch_monitor_get_capabilities:
>>>
>>>       /*
>>>        * At the moment only Intel HVM domains are supported. However, event
>>>        * delivery could be extended to AMD and PV domains.
>>>        */
>>>       if ( !is_hvm_domain(d) || !cpu_has_vmx )
>>>           return capabilities;
>>>
>>> == "However, event delivery could be extended to AMD and PV domains".
>>> This comment begs for questions like:
>>> * what would be necessary to extend support to PV domains?
>>> * can we really do this operation without hardware assisted
>>> virtualization whatsoever? If not, how much can we do without that?
>>> * what about pvh?
>>>
>>> Since I have other questions like the above and I'll probably have more
>>> while I'm trying to get a better picture of the code, would it be ok if
>>> we defer addressing these issues to then?
>> Yes, you should definitely not hijack this thread for other, more
>> general inquiries.
> 
> Ok then, should I also understand then that for now it's ok to keep the 
> "HVM-ish" hvm_event_traps & hvm_event_guest_request (I suppose you were 
> referring to these 2 functions above) on the common-side event.c until 
> we address these issues?
> Or I could try to move them to common/vm_event.c as you suggest renamed 
> to vm_event_traps & vm_event_guest_request and also rename 
> arch_hvm_event_fill_regs to arch_vm_event_fill_regs (?).

I'd say dropping the hvm_ suffixes / infixes would be fine (and
even desirable) alongside their movement to common/vm_event.c,
but the question really needs to go to the maintainers of that
code.

Jan