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 14:07:02 +0200 Message-ID: <56DD6EE6.8030309@bitdefender.com> References: <1457014210-14552-1-git-send-email-czuzu@bitdefender.com> <56DD3A2B.6060803@bitdefender.com> <56DD4A63.3010604@bitdefender.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5691011584044696185==" 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. --===============5691011584044696185== Content-Type: multipart/alternative; boundary="------------080702070400090107060403" This is a multi-part message in MIME format. --------------080702070400090107060403 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/7/2016 11:45 AM, Tamas K Lengyel wrote: > > > On Mon, Mar 7, 2016 at 10:31 AM, Corneliu ZUZU > wrote: > > 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. > > > Yes. OTOH I don't think you can find any CPUs on the market today that > support VMX but have no EPT so this hasn't really caused any issues > for anyone using vm_events, but technically yes VMX is enough for > these events. > >> 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(...) ) ? > > > Yeap, that sounds like the right place to have that check. > > Tamas Good, with that out of the way, one more issue to solve. What I'm actually trying to do is to move that part of the code to the scheduling tail - i.e. enabling/disabling CPU_BASED_CR3_LOAD_EXITING only when we actually enter the vcpu. To do this I also need to know exactly in what cases CPU_BASED_CR3_LOAD_EXITING can/is enabled, besides the already mentioned case when a domain's paging is disabled. I'm searching through the codebase right now but it's a bit dizzying, can someone provide some feedback on this matter? Thanks, Corneliu. --------------080702070400090107060403 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/7/2016 11:45 AM, Tamas K Lengyel wrote:


On Mon, Mar 7, 2016 at 10:31 AM, Corneliu ZUZU <czuzu@bitdefender.com> wrote:
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.

Yes. OTOH I don't think you can find any CPUs on the market today that support VMX but have no EPT so this hasn't really caused any issues for anyone using vm_events, but technically yes VMX is enough for these events.
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(...) ) ?

Yeap, that sounds like the right place to have that check.
 
Tamas

Good, with that out of the way, one more issue to solve. What I'm actually trying to do is to move that part of the code to the scheduling tail - i.e. enabling/disabling CPU_BASED_CR3_LOAD_EXITING only when we actually enter the vcpu.
To do this I also need to know exactly in what cases CPU_BASED_CR3_LOAD_EXITING can/is enabled, besides the already mentioned case when a domain's paging is disabled.

I'm searching through the codebase right now but it's a bit dizzying, can someone provide some feedback on this matter?

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