>>> On 16.03.18 at 16:42, wrote:
> On 16/03/18 15:04, Jan Beulich wrote:
> On 16.03.18 at 15:29, wrote:
>>> Somewhat independently of this patch, I think we should assert that
>>> flags are in the expected state in the return-to-guest path, so we
>>> notice accidental breakage like this more
On 16/03/18 15:04, Jan Beulich wrote:
On 16.03.18 at 15:29, wrote:
>> On 16/03/18 14:13, Jan Beulich wrote:
>>> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
>>> moved the STI past the PUSHF. While this isn't an active problem (as we
>>> force EFLAGS.IF to 1 before exi
>>> On 16.03.18 at 15:29, wrote:
> On 16/03/18 14:13, Jan Beulich wrote:
>> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
>> moved the STI past the PUSHF. While this isn't an active problem (as we
>> force EFLAGS.IF to 1 before exiting to guest context), let's not risk
>> i
On 16/03/18 14:13, Jan Beulich wrote:
> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
> moved the STI past the PUSHF. While this isn't an active problem (as we
> force EFLAGS.IF to 1 before exiting to guest context), let's not risk
> internal confusion by finding a PV guest
Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead")
moved the STI past the PUSHF. While this isn't an active problem (as we
force EFLAGS.IF to 1 before exiting to guest context), let's not risk
internal confusion by finding a PV guest frame with interrupts
apparently off.
Signed-