x86/hvm: Don't raise #GP behind the emulators back for CR writes

x86/hvm: Don't raise #GP behind the emulators back for CR writes

hvm_set_cr{0,4}() are reachable from the emulator, but use
hvm_inject_hw_exception() directly.

Alter the API to make the callers of hvm_set_cr{0,3,4}() responsible for
raising #GP, and apply this change to all existing callers.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Issues identified which I am purposefully not fixing in this patch:

(I will try to get around to them, but probably not in the 4.9 timeframe, at
this point.)

 * hvm_set_cr3() doesn't handle bad 32bit PAE PDPTRs properly, as it doesn't
   actually have a path which raises #GP.
 * There is a lot of redundancy in our HVM CR setting routines, but not enough
   to trivially dedup at this point.
 * Both nested VT-x and SVM are liable raise #GP with L1, rather than failing
   the virtual vmentry/vmexit.  This is not a change in behaviour, but is far
   more obvious now.
 * The hvm_do_resume() path for vm_event processing has the same bug as the
   MSR side, where exceptions are raised after %rip has moved forwards.  This
   is also not a change in behaviour.