Re: [Xen-devel] [PATCH 0/1] ARM: Implement support for write-ctrlreg vm-events

[Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>]

On 3/7/2016 11:45 AM, Tamas K Lengyel wrote:

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel