From mboxrd@z Thu Jan 1 00:00:00 1970 From: Razvan Cojocaru Subject: Re: [PATCH] arm/monitor vm-events: Implement guest-request support Date: Mon, 22 Feb 2016 13:40:06 +0200 Message-ID: <56CAF396.5070806@bitdefender.com> References: <1455824116-13783-1-git-send-email-czuzu@bitdefender.com> <56C7341402000078000D427C@prv-mh.provo.novell.com> <56C741E8.4070106@bitdefender.com> <56C75BB402000078000D444F@prv-mh.provo.novell.com> <56C75885.2010509@bitdefender.com> <56CAED8E02000078000D49B9@prv-mh.provo.novell.com> <56CAF058.9090501@bitdefender.com> <56CB012C02000078000D4A9A@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56CB012C02000078000D4A9A@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Corneliu ZUZU Cc: Tamas K Lengyel , Keir Fraser , Ian Campbell , Andrew Cooper , xen-devel@lists.xen.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 02/22/2016 01:38 PM, Jan Beulich wrote: >>>> On 22.02.16 at 12:26, wrote: >> On 2/22/2016 12:14 PM, Jan Beulich wrote: >>>>>> On 19.02.16 at 19:01, wrote: >>>> On 2/19/2016 7:15 PM, Jan Beulich wrote: >>>>>>>> On 19.02.16 at 17:25, wrote: >>>>>> On 2/19/2016 4:26 PM, Jan Beulich wrote: >>>>>>>>>> On 18.02.16 at 20:35, 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