Re: [Xen-devel] [PATCH v2] SVM: limit GIF=0 region

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.08.18 at 19:55, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 29/08/18 07:26, Jan Beulich wrote:
>>>>> On 29.08.18 at 01:06, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> Furthermore, to fix LBR handling, the first thing I'd have to do is
>>> revert this, so please leave it as it is.
>> Mind being a little more specific as to the whys here?
> 
> When vmcb->virt_ext.fields.lbr_enable is clear and DEBUGCTL.LBR is set,
> the hypervisor must atomically switch the 5 LBR MSRs inside the critical
> region.
> 
> Usage of DEBUGCTL.LBR is broken on pre-lbrv hardware (gen 1/2 svm?), and
> when suitably (mis)configured by nested virt.

Okay, that's what I had concluded on the way home yesterday.
But this needs doing before the first branch, i.e. in particular
prior to SPEC_CTRL_ENTRY_FROM_HVM. Hence the STGI could
still move ahead (provided the NMI/#MC issue was addressed).

Anyway - I guess I'll make the change and record further room
for improvement in the description.

>> From a purely formal pov, Boris'es R-b allows me to put the change in
>> as is. I'm not overly happy to do the requested change, but I
>> certainly will, provided - once again - I understand the reason.
>>
>> Furthermore, please don't forget that the more we delay
>> especially #MC, the more likely it becomes that a system will
>> crash in a far less obvious way than by logging an #MC.
> 
> #MC's only get raised after the bank registers have been updated, so
> even if a shutdown occurs, the data will be captured by the firmware
> after reset.
> 
> As for non-deferrable #MC's, a couple of extra stack/msr/vcpu references
> in the critical region doesn't alter the chances.  We were never going
> to survive, or won't trigger a new one.

The question isn't whether we survive, but whether the logged
data allows concluding what has happened (and in roughly what
context) in a halfway reasonable manner.

Jan



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