Andrew Cooper: > On 11/04/18 12:48, Simon Gaiser wrote: >> Hi, >> >> when I use early microcode loading with the microcode update with the >> BTI mitigations, resuming from suspend to RAM is broken. >> >> Based on added logging to enter_state() (from power.c) it doesn't >> survive the local_irq_restore(flags) call (at least a printk() after the >> call doesn't output anything on the serial console). >> >> I guess that some irq handler tries to use IBRS/IBPB. But the microcode >> is only loaded later. >> >> If I simply move the microcode_resume_cpu(0) directly before the >> local_irq_restore(flags) everything seems to work fine. But I'm not sure >> if this has unintended consequences. >> >> I tested the above with Xen 4.8.3 from Qubes which includes the BTI and >> microcode patches from staging-4.8. AFAICS there are no commits which >> changes the affected code or other commits which sound relevant so this >> probably affected also all the newer branches. > > S3 support is a very unloved area of the hypervisor. > > Yes - we definitely need to get microcode reloaded before interrupts are > enabled.
Do you see any problems with simply moving microcode_resume_cpu(0) directly before the local_irq_restore(flags) call? (I'm not familiar with the code at all and (early) resume handling sounds like something which is easy to break in non obvious ways) > That said, I would have expected a backtrace complaining about > a GP fault if we had hit the use of IBRS/IBPB before the microcode was > reloaded. Yeah, not sure what's happening here. I don't get any output from after local_irq_restore(flags). If you have some ideas for more debug output I can easily test it. Simon
Description: OpenPGP digital signature
_______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xenproject.org/mailman/listinfo/xen-devel