public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@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, 8 Apr 2010 11:16:04 -0300	[thread overview]
Message-ID: <20100408141604.GA20713@amt.cnet> (raw)
In-Reply-To: <4BBD8E64.4070106@redhat.com>

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.

> >enter_rmode/pmode should
> >just trigger a set_rflags to update things.
> 
> Not what I had in mind, but a valid implementation.
> 
> >And vmx_get_rflags must
> >properly inject the saved flags instead of masking them out.
> 
> Yes.  No one ever bothers to play with iopl in real mode, so we
> never noticed this.  We do this for cr0 for example.
> 
> >>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.

> And I'll be happy to apply such patches.  Just ensure that 2.6.32.y
> and above have the fixes so we don't introduce regressions (I think
> most workarounds are a lot older).
> 
> -- 
> error compiling committee.c: too many arguments to function

  reply	other threads:[~2010-04-08 14:41 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 [this message]
2010-04-08 14:47             ` Avi Kivity
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=20100408141604.GA20713@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    /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