From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] arm/monitor vm-events: Implement guest-request support Date: Mon, 22 Feb 2016 04:38:04 -0700 Message-ID: <56CB012C02000078000D4A9A@prv-mh.provo.novell.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56CAF058.9090501@bitdefender.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Corneliu ZUZU Cc: Tamas K Lengyel , Keir Fraser , Ian Campbell , Razvan Cojocaru , Andrew Cooper , xen-devel@lists.xen.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org >>> 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. Jan