[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 02/22/2016 01:38 PM, Jan Beulich wrote:
>>>> On 22.02.16 at 12:26, <czuzu@xxxxxxxxxxxxxxx> wrote:
>> On 2/22/2016 12:14 PM, Jan Beulich wrote:
>>>>>> On 19.02.16 at 19:01, <czuzu@xxxxxxxxxxxxxxx> wrote:
>>>> On 2/19/2016 7:15 PM, Jan Beulich wrote:
>>>>>>>> On 19.02.16 at 17:25, <czuzu@xxxxxxxxxxxxxxx> wrote:
>>>>>> On 2/19/2016 4:26 PM, Jan Beulich wrote:
>>>>>>>>>> On 18.02.16 at 20:35, <czuzu@xxxxxxxxxxxxxxx> 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.

I agree.


Thanks,
Razvan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.