public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Nadav Har'El" <nyh@math.technion.ac.il>
To: Gleb Natapov <gleb@redhat.com>
Cc: Chris Wright <chrisw@redhat.com>, kvm@vger.kernel.org, avi@redhat.com
Subject: Re: KVM call minutes for Sept 21
Date: Wed, 22 Sep 2010 18:29:00 +0200	[thread overview]
Message-ID: <20100922162900.GA12492@fermat.math.technion.ac.il> (raw)
In-Reply-To: <20100922090248.GD11145@redhat.com>

On Wed, Sep 22, 2010, Gleb Natapov wrote about "Re: KVM call minutes for Sept 21":
> There is only one outstanding serious issue from my point of view: event
> injection path. I want it to be similar to how nested SVM handles it. I
> don't see why it can't be done the same way for VMX too. The way nested SVM
> does it looks cleaner and making code paths similar will allow us to
> consolidate the logic in common code later. This issue is too
> fundamental to be fixed after merge IMHO. Other nitpicks about missing
> checks that real HW does, but emulation doesn't can be fixed any time
> after merge.

I'll try my best to accomodate your request, but I tried to explain in my
previous mails (and so dir Orit Wasserman in her mails last year, by the way -
I found a long thread in the mailing list...) that there appears to be a
fundemental additional complexity in VMX that doesn't exist in SVM. In VMX,
you might have to inject another exception (IDT_VECTORING_INFO_FIELD) at the
same time that you're already trying to inject a page fault to L1, and this
doesn't appear (?) to exist in SVM.
However, since I didn't write this code myself, and didn't encounter all the
problems myself, I still want to try to see whether I can get "cleaner" code
to actually work. But I want it to be really cleaner - not just remove one
somewhat-ugly intervention from vmx_complete_interrupts() and move it to an
even uglier intervention somewhere else.

In any case, while I obviously agree that it's your prerogative not to merge
code that you consider ugly, I still don't see any particular problem to start
with the current, working, code, and fix it later. It's not like we can never
change this code after it's in - it's clearly marked with if(nested) and
doesn't effect anything in the non-nested path.

> I think the question was "why do we need nested virtualization" ;)

Then why was nested SVM merged in the first place? Isn't it too late to
ask this question now? :-)

Anyway, I tried to answer this question in my previous email.
I'm not sure what more I can say to answer this question better.

Thanks,

Nadav.

-- 
Nadav Har'El                        |   Wednesday, Sep 22 2010, 15 Tishri 5771
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Give Yogi a rifle. Support your right to
http://nadav.harel.org.il           |arm bears!

  reply	other threads:[~2010-09-22 16:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-21 18:05 KVM call minutes for Sept 21 Chris Wright
2010-09-21 18:23 ` Anthony Liguori
2010-09-22  0:04 ` Nadav Har'El
2010-09-22  1:48   ` Chris Wright
2010-09-22 17:49     ` Nadav Har'El
2010-09-22 18:03       ` Anthony Liguori
2010-09-22 19:34         ` Joerg Roedel
2010-09-22 19:48       ` Joerg Roedel
2010-09-22  9:02   ` Gleb Natapov
2010-09-22 16:29     ` Nadav Har'El [this message]
2010-09-22 17:47       ` Gleb Natapov
2010-09-22 19:20         ` Joerg Roedel
2010-09-22 20:18           ` Gleb Natapov
2010-09-22 23:00             ` Nadav Har'El
2010-09-26 14:03           ` Avi Kivity
2010-09-26 20:25             ` Joerg Roedel
2010-09-27  8:36               ` Avi Kivity
2010-09-27 14:18                 ` Gleb Natapov
2010-09-27 14:22                   ` Avi Kivity
2010-09-26 13:27   ` Avi Kivity
2010-09-26 14:28     ` Nadav Har'El
2010-09-26 14:50       ` Avi Kivity

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=20100922162900.GA12492@fermat.math.technion.ac.il \
    --to=nyh@math.technion.ac.il \
    --cc=avi@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=gleb@redhat.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