From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corneliu ZUZU Subject: Re: [PATCH 0/1] ARM: Implement support for write-ctrlreg vm-events Date: Mon, 7 Mar 2016 11:31:15 +0200 Message-ID: <56DD4A63.3010604@bitdefender.com> References: <1457014210-14552-1-git-send-email-czuzu@bitdefender.com> <56DD3A2B.6060803@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7000011010479095064==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Tamas K Lengyel Cc: Kevin Tian , Keir Fraser , Jan Beulich , Razvan Cojocaru , Andrew Cooper , Xen-devel , Stefano Stabellini , Jun Nakajima List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============7000011010479095064== Content-Type: multipart/alternative; boundary="------------040000010200080200000709" This is a multi-part message in MIME format. --------------040000010200080200000709 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/7/2016 11:12 AM, Tamas K Lengyel wrote: > EPT is not really required for CR3 monitoring, it just has been the > case that vm_events have been only implemented for hap-enabled domains. I suppose this is not valid for vm-events in their entirety, right? I mean it seems to me that @ least for monitor vm-events VMX is enough. > AFAIK for non-hap case CR3 needs to be trapped unconditionally, yes. > > If the former is true, shouldn't we do a check like this in > vm_event_monitor_get_capabilities instead? > > > Yes, it should now, this code was just written before > vm_event_monitor_get_capabilities was introduced and we haven't gotten > around converting this check to it. Is there any reason why monitor vm-events in their current state wouldn't work on non-hap domains? If they would work, shouldn't we instead simply move the monitor.write_ctrlreg_enabled part out of the if ( paging_mode_hap(...) ) ? > > 2). I was also wondering why CR3 load/stores are trapped if paging > is disabled for a domain. > > > Good question, I was wondering about that myself at some point but I > haven't found an answer to it. Maybe some git archaeology can help > determining when that was added and why ;) > > Cheers, > Tamas Yep, will "blame into it". Thanks, Corneliu. --------------040000010200080200000709 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/7/2016 11:12 AM, Tamas K Lengyel wrote:
EPT is not really required for CR3 monitoring, it just has been the case that vm_events have been only implemented for hap-enabled domains.

I suppose this is not valid for vm-events in their entirety, right? I mean it seems to me that @ least for monitor vm-events VMX is enough.

AFAIK for non-hap case CR3 needs to be trapped unconditionally, yes.
 
If the former is true, shouldn't we do a check like this in vm_event_monitor_get_capabilities instead?

Yes, it should now, this code was just written before vm_event_monitor_get_capabilities was introduced and we haven't gotten around converting this check to it.

Is there any reason why monitor vm-events in their current state wouldn't work on non-hap domains?
If they would work, shouldn't we instead simply move the monitor.write_ctrlreg_enabled part out of the if ( paging_mode_hap(...) ) ?

 

2). I was also wondering why CR3 load/stores are trapped if paging is disabled for a domain.

Good question, I was wondering about that myself at some point but I haven't found an answer to it. Maybe some git archaeology can help determining when that was added and why ;)

Cheers,
Tamas

Yep, will "blame into it".

Thanks,
Corneliu.
--------------040000010200080200000709-- --===============7000011010479095064== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============7000011010479095064==--