From: Avi Kivity <avi@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, kvm <kvm@vger.kernel.org>,
Gleb Natapov <gleb@redhat.com>
Subject: Re: VMX and save/restore guest in virtual-8086 mode
Date: Thu, 08 Apr 2010 17:47:01 +0300 [thread overview]
Message-ID: <4BBDEC65.80400@redhat.com> (raw)
In-Reply-To: <20100408141604.GA20713@amt.cnet>
On 04/08/2010 05:16 PM, Marcelo Tosatti wrote:
> On Thu, Apr 08, 2010 at 11:05:56AM +0300, Avi Kivity wrote:
>
>> On 04/08/2010 10:54 AM, Jan Kiszka wrote:
>>
>>>
>>>>>> Looks like KVM_SET_REGS should write rmode.save_iopl (and a new save_vm)?
>>>>>>
>>>>>>
>>>>> Just like we manipulate the flags for guest debugging in the
>>>>> set/get_rflags vendor handlers, the same should happen for IOPL and VM.
>>>>> This is no business of enter_pmode/rmode.
>>>>>
>>>>>
>>>> This is vendor specific code, and it isn't manipulating guest values,
>>>> only host values (->set_rflags() is called when the guest value changes,
>>>> which isn't happening here). Of course some refactoring will be helpful
>>>> here.
>>>>
>>> Actually, the bug is that enter_pmode/rmode update save_iopl (and that
>>> no one saves the VM bit). That should happen in vmx_set_rflags to also
>>> keep track of changes _while_ we are in rmode.
>>>
>> Exactly - that's what I suggested above.
>>
> And new ioctl to save/restore save_iopl/save_vm.
>
That ioctl already exists, KVM_{GET,SET}_REGS.
We're writing via KVM_SET_SREGS eflags.vm=1 and eflags.iopl=3 while
cr0.pe=0. vmx_set_rflags() notices this and sets rmode.save_vm=1 and
rmode.save_iopl=3. Next we write via KVM_SET_SREGS cr0.pe=1. So we
call enter_pmode(), and recover eflags.vm and eflags.iopl from rmode.vm
and rmode.iopl. Win!
It's similar to how we handle cr0.ts, sometimes the host owns it so we
keep it in a shadow register, sometimes the guest owns it so we keep it
in cr0.
>>>> It's a bugfix that can go into -stable and supported distribution kernels.
>>>>
>>> Well, would be happy to throw out tones of workaround based on this
>>> approach. :)
>>>
> Do you mean you'd be interested in writing the patch? Sure, go ahead,
> let me know otherwise.
>
I took it to mean he wants to kill the other qemu workarounds for kernel
bugs.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-04-08 14:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-07 20:24 VMX and save/restore guest in virtual-8086 mode Marcelo Tosatti
2010-04-07 20:46 ` Avi Kivity
2010-04-08 7:22 ` Jan Kiszka
2010-04-08 7:29 ` Avi Kivity
2010-04-08 7:54 ` Jan Kiszka
2010-04-08 8:05 ` Avi Kivity
2010-04-08 14:16 ` Marcelo Tosatti
2010-04-08 14:47 ` Avi Kivity [this message]
2010-04-08 14:56 ` Jan Kiszka
2010-04-08 14:47 ` Marcelo Tosatti
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=4BBDEC65.80400@redhat.com \
--to=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox