Re: [Xen-devel] [PATCH 4/8] x86/vm-event/monitor: turn monitor_write_data.do_write into enum

[Corneliu ZUZU <czuzu@xxxxxxxxxxxxxxx>]

On 7/4/2016 5:08 PM, Jan Beulich wrote:
> > > > On 04.07.16 at 15:21, <czuzu@xxxxxxxxxxxxxxx> wrote:
> > On 7/4/2016 4:07 PM, Jan Beulich wrote:
> > > > > > On 04.07.16 at 14:47, <czuzu@xxxxxxxxxxxxxxx> wrote:
> > > > On 7/4/2016 3:37 PM, Jan Beulich wrote:
> > > > > > > > On 30.06.16 at 20:44, <czuzu@xxxxxxxxxxxxxxx> wrote:
> > > > > > After trapping a control-register write vm-event and -until- deciding if that
> > > > > > write is to be permitted or not (VM_EVENT_FLAG_DENY) and doing the actual
> > > > > > write,
> > > > > > there cannot and should not be another trapped control-register write event.
> > > > > Is that true even for the case where full register state gets updated
> > > > > for a vCPU?
> > > > AFAIK, the full register state cannot be updated _at once_, that is:
> > > > after each trapped register update monitor_write_data must _always_ be
> > > > handled _before reentering the vCPU_.
> > > I'm thinking about operations like VCPUOP_initialise here. Of course
> > > operations on current can't possibly update more than one register
> > > at a time.
> > Yes but those register update operations happen outside the vm-event
> > subsystem, i.e. in those cases the registers get updated directly, not
> > by setting bits in monitor_write_data.
> > Only hypervisor-trapped register updates (e.g. hvm_set_cr0 w/ may_defer
> > parameter = 1) which are deferred because of hvm_event_crX returning
> > true use monitor_write_data.
> That's why I had added "Is that updating-all-context case of no
> interest to a monitoring application, now and forever?" After all I
> gave VCPUOP_initialise as an example because the guest itself
> can invoke it, and so I had assumed this to be of interest to a
> monitoring app.
>
> Jan
Hmm, didn't have in mind the fact that the guest can do those kind of 
operations, I suppose that applies to PV guests, right? (in which case 
this scenario would be triggered by an in-guest PV driver, right?)
CR-write monitor vm-events currently only trap _machine instructions_ 
which cause CR writes, but in the future I can see why it might be 
useful for a monitoring app to trap _any kind of guest behavior_ which 
would cause that.
Good point, maybe Razvan and Tamas can chime in on this.

Thanks,
Corneliu.

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