This also impacts the "on change only" control setting code.
>From some debugging code: hvm_event_cr, value: 800000001aad0000, old:
1aad0000
This should not count as a changed CR3 value for reporting purposes.
The following patch resolves this reasonably, for a sane value of "change
only" reporting. Apologies for the old Xen version, but I assume this is
still an issue if the other issue was not resolved in staging.
--- xenserver-4.7.1-clean/xen/arch/x86/hvm/event.c 2017-05-10
11:29:14.135332964 -0600
+++ xenserver-4.7.1/xen/arch/x86/hvm/event.c 2018-01-25
16:52:05.938251000 -0700
@@ -33,6 +33,11 @@
struct arch_domain *ad = &curr->domain->arch;
unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
+
+ // Patch in work from Razvan
+ if ( hvm_pcid_enabled(curr) )
+ value &= ((1ull << 63) - 1);
+
if ( (ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask) &&
(!(ad->monitor.write_ctrlreg_onchangeonly & ctrlreg_bitmask) ||
value != old) )
On Thu, Jan 25, 2018 at 4:03 PM, Razvan Cojocaru <rcojoc...@bitdefender.com>
wrote:
> On 01/26/2018 12:17 AM, Bitweasil . wrote:
> > Razvan -
> >
> > Yes, that patch resolves the issues. Performance is abysmal (as
> > expected with a CR3 switch on every syscall), but things behave
> properly.>
> > Jan -
> >
> > It turns out that unrelated code in my livepatch was causing the
> > crashing when I filtered the high bit - I was not properly gating some
> > other CR3 processing code in the livepatch, and that was causing the
> > invalid opcode errors, not the filtered CR3 value. You are correct that
> > masking the bit should not cause any correctness issues, only
> > performance issues.
> >
> > Will one of you take up submitting this patch into the proper places?
> > I'm afraid I'm not very familiar with the Xen patch submission process.
>
> Yes, I'll send a proper patch.
>
>
> Thanks for pointing the issue out,
> Razvan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
