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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 07/04/16 17:08, 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.

Well, the change does simplify the code for now but I can't bet on
"forever" - maybe Tamas has some ideas here also? It may be that the
prudent thing to do is leave the code without the enum change.


Thanks,
Razvan

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