Re: [Xen-devel] [PATCH v4 0/4] hvm/svm: Enable vm events for SVM

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/02/18 13:05, Razvan Cojocaru wrote:
> On 02/15/2018 02:36 PM, Andrew Cooper wrote:
>> One thing I note however is that patch 2 and 3 both turn on intercepts
>> and have no way of turning them back off.  This appears to be consistent
>> with the Intel side of things, but it is suboptimal for the guest when
>> an introspection agent detaches.
> That's very true (I've also pointed this out to Bitweasil when we've
> discussed the CR3 intercept crash after the noflush bit started to get
> used).
>
> I've also considered this when I've added the MSR write subscription
> code, however it didn't feel safe to just disable those exits when the
> introspection agent unplugs.

The problem is that we don't have a source of information to derive the
intercepts from, which is also what is causing chaos trying to get
nested virt working.

We only have what is programmed into the hardware structures, which
suffers from "multiple-producers" syndrome.

> For one, we'd have to store the previous state somewhere (we might be
> interested in a MSR, for example, for which exits were already enabled
> before we subscribed to it - we shouldn't disable exits for it then).
>
> And even if we did keep the previous state somewhere (with the assorted
> problems - where do we allocate space for it? etc.) - it's theoretically
> possible that some other Xen subsystem fiddles with the exits in the
> meantime, so the state we remember may not be the current state of
> affairs wrt exits.
>
> Am I overthinking this?

No - I don't think so.

The only way to solve this problem is to have all the information for
each agent (including Xen itself) interested in controlling the
behaviour of the guest to be available, hooked off struct domain/vcpu as
appropriate, and one single function to combine everyones view of the
world into the hardware configuration.

If you can't unambiguously recalculate the contents of the VMCS/VMCB,
then something is broken.

>
>> For the CPUID/MSR policy side of things, Jan has talked me in to
>> changing how cpuid_policy_updated() works, and implementing it as a
>> recalculation of the intercepts on the return-to-guest path.  It occurs
>> to me that this usefully extends to changes requested by the
>> introspection agent.
> Thanks, we'll look that up.

It doesn't exist yet :)

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel