Request complete reversion of XSA-60 patches

Request complete reversion of XSA-60 patches

[Andrew Cooper]

Hello,

Following CID 1128574 (Data race condition writing to
vcpu->arch.hvm_vcpu.cache_mode), I took a closer look at the expected
semantics surrounding domain->arch.hvm_domain.is_in_uc_mode

Embarrassingly, none of the reviewer (myself included) noticed that the
new "hvm_shadow_handle_cd()" was actually the regular CR0.CD switching
code for AMD SVM, which is now hidden behind an optional hvm_funcs
pointer only implemented in VT-x.

The changeset 62652c00efa55fb45374bcc92f7d96fc411aebb2 has therefore
caused a complete functional regression in AMD wrt CR0.CD handling.

>From my understanding after investigating, the new
"hvm_shadow_handle_cd()" function was actually common which needed doing
in all cases, otherwise HAP logdirty mode will break.  Therefore, this
change appears to have broken migration as well.

Furthermore, the series already missed correct cache flushing in certain
cases (e.g. writing the hypercall page).


I request that the series be reverted in it's entirety to minimise the
collateral damage until a full, complete and correct set of fixes can be
made.

~Andrew

Re: Was: Request complete reversion of XSA-60 patches

[Andrew Cooper]

Following a long discussion with Tim, it appears that despite the AMD
codepath being changed, there appear to be no relevant side effects as a
result, which reduces my main concern with the series.

However, in the process we identified more areas which need a cache flush.

vmx_ctxt_switch_from() needs a wbinvd() for the case where we service a
vmexit but get descheduled before returning.  There are also the
previously indicated areas which also need more cache invalidation.

There is also a wider problem with cached mappings from dom0, which are
identified but not introduced by this series.  Fixing this is still an
oustanding problem, with no sensible solution being apparent.

~Andrew

Re: Was: Request complete reversion of XSA-60 patches

[Jan Beulich]

>>> On 14.11.13 at 13:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Following a long discussion with Tim, it appears that despite the AMD
> codepath being changed, there appear to be no relevant side effects as a
> result, which reduces my main concern with the series.

Am I right in reading this as you withdrawing the revert request?

> However, in the process we identified more areas which need a cache flush.
> 
> vmx_ctxt_switch_from() needs a wbinvd() for the case where we service a
> vmexit but get descheduled before returning.  There are also the
> previously indicated areas which also need more cache invalidation.
> 
> There is also a wider problem with cached mappings from dom0, which are
> identified but not introduced by this series.  Fixing this is still an
> oustanding problem, with no sensible solution being apparent.

But you realize that the original code wasn't really complete
either (in particular with regards to necessary cache flushing)?
Hence I'm not really convinced the situation is now worse than it
was before.

Jan