[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] XSA-60 - how to get back to a sane state
All, Jinsong's patches having been in for nearly a month now, but not being in a shape that would make releasing in 4.4 or backporting to the older trees desirable, we need to come to a conclusion on which way to go. Currently it looks like we have three options, but of course I'll be happy to see other (better!) ones proposed. 1) Stay with what we have. 2) Revert 86d60e85 ("VMX: flush cache when vmentry back to UC guest") in its entirety plus, perhaps, the change 62652c00 ("VMX: fix cr0.cd handling") did to vmx_ctxt_switch_to(). 3) Apply the attached patch that Andrew and I have been putting together, with the caveat that it's still incomplete (see below). The latter two are based on the observation that the amount of cache flushing we do with what is in the master tree right now is more than what we did prior to that patch series but still insufficient. Hence the revert would get us back to the earlier state (and obviously eliminate the performance problems that were observed when doing too eager flushing), whereas applying the extra 5th patch would get us closer to a proper solution. The problem with that new patch is it's - as said - still incomplete, yet setting ->arch.hvm_vcpu.hypervisor_access_uc_hvm_memory for all writes through map_domain_page_global() mappings would get rather ugly: - guest_walk_tables() (accumulating set_ad_bits() results) - all writes through vcpu_info() - event_fifo.c would need this scattered around - hvm_load_segment_selector()'s setting of the accessed bit - hvm_task_switch()'s handling of the busy bit - all the nested HVM code's writes through ->nv_vvmcx Plus the performance effects of it aren't really known yet (all we do know is that the too eager "flush always prior to VM entry" is causing unacceptable stalls). Otoh we have had no reports that the lack of proper cache flushing actually caused any problems, and hence reverting the partial flushing introduced isn't likely to push new problems onto people. Yet if, ever, such a problem would surface, it can be expected to be very hard to diagnose. Please, everyone having an opinion here - voice it. Thanks, Jan Attachment:
xsa60-5 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |