All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor
Date: Thu, 27 Oct 2016 18:41:00 +0200	[thread overview]
Message-ID: <20161027164059.GG4212@potion> (raw)
In-Reply-To: <0e5108b0-15f0-56c1-b9e5-626ecff644d7@redhat.com>

2016-10-26 23:40+0200, Laszlo Ersek:
> On 10/26/16 22:50, Radim Krčmář wrote:
>> [1/2] adds the emulation (and could be split into two patches if you'd like),
>> [2/2] just refactors the code.
>> 
>> This should fix an issue that users are hitting.  Laszlo found several reports:
>>  - https://bugs.launchpad.net/qemu/+bug/1623276
>>  - https://bugzilla.proxmox.com/show_bug.cgi?id=1182
>>  - https://bugs.archlinux.org/task/50778
>> 
>> I have only tested it with a simple kvm-unit-tests, though.  Reproducing the
>> iPXE issue is on the way ...
>> 
>> 
>> Radim Krčmář (2):
>>   KVM: x86: emulate fxsave and fxrstor
>>   KVM: x86: save one bit in ctxt->d
>> 
>>  arch/x86/kvm/emulate.c | 110 ++++++++++++++++++++++++++++++++++++++++++-------
>>  1 file changed, 94 insertions(+), 16 deletions(-)
>> 
> 
> I was just about to post iPXE patches that would disable the FXSAVE /
> FXRSTOR instructions in the CONFIG=qemu build (*), but you beat me to it
> with the KVM emulation code ;)
> 
> (*) If you look at the iPXE commit that added them, they are a
> workaround for a Tivoli VMM bug; i.e., irrelevant for QEMU/KVM guests.
> 
> ... Actually, those iPXE patches that conditionalize FXSAVE / FXRSTOR
> may still make sense -- we can rebuild iPXE, and bundle the refreshed
> binaries with QEMU v2.7.1, and swiftly at that. Whereas the KVM patches
> could take more time to propagate to users?... Not sure. What do you
> guys think?

This series won't get into 4.9, so it would take almost half a year
before the kernel trickles into experimental distros.  And updating
QEMU/iPXE isn't as dangerous as updating kernel, so I like the idea.

I am just tempted to drop a KVM patch with positive diffstat that fixes
something that doesn't really need fixing anymore. :)

  reply	other threads:[~2016-10-27 16:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 20:50 [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor Radim Krčmář
2016-10-26 20:50 ` [PATCH 1/2] " Radim Krčmář
2016-10-27  0:17   ` Bandan Das
2016-10-27 16:34     ` Radim Krčmář
2016-10-28  3:29       ` Bandan Das
2016-10-26 20:50 ` [PATCH 2/2] KVM: x86: save one bit in ctxt->d Radim Krčmář
2016-10-26 21:40 ` [PATCH 0/2] KVM: x86: emulate fxsave and fxrstor Laszlo Ersek
2016-10-27 16:41   ` Radim Krčmář [this message]
2016-10-27 17:01     ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161027164059.GG4212@potion \
    --to=rkrcmar@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lersek@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.