[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |