[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/8] x86/vm-event/monitor: turn monitor_write_data.do_write into enum
>>> On 04.07.16 at 16:24, <czuzu@xxxxxxxxxxxxxxx> wrote: > 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. > > 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?) A driver wouldn't normally do such things, unless the OS is really highly modularized (far beyond what Linux allows). But yes, this is a PV operation, but equally applies to PVHv2 (see commit 192df6f912 ["x86: allow HVM guests to use hypercalls to bring up vCPUs"]) and by extension/generalization HVM. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |