From: Anthony Liguori <aliguori@us.ibm.com>
To: Zachary Amsden <zach@vmware.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
kvm-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
Avi Kivity <avi@qumranet.com>
Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
Date: Sat, 15 Sep 2007 12:33:41 -0500 [thread overview]
Message-ID: <46EC1775.4000709@us.ibm.com> (raw)
In-Reply-To: <1189827476.5982.143.camel@bodhitayantram.eng.vmware.com>
Zachary Amsden wrote:
> On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
>
>
>> So then each module creates a hypercall page using this magic MSR and
>> the hypervisor has to keep track of it so that it can appropriately
>> change the page on migration. The page can only contain a single
>> instruction or else it cannot be easily changed (or you have to be able
>> to prevent the guest from being migrated while in the hypercall page).
>>
>> We're really talking about identical models. Instead of an MSR, the #GP
>> is what tells the hypervisor to update the instruction. The nice thing
>> about this is that you don't have to keep track of all the current
>> hypercall page locations in the hypervisor.
>>
>
> I agree, multiple hypercall pages is insane. I was thinking more of a
> single hypercall page, fixed in place by the hypervisor, not the kernel.
>
> Then each module can read an MSR saying what VA the hypercall page is
> at, and the hypervisor can simply flip one page to switch architectures.
>
That requires a memory hole though. In KVM, we don't have a memory hole.
Regards,
Anthony Liguori
> Zach
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Subject: Re: [PATCH] Refactor hypercall infrastructure
Date: Sat, 15 Sep 2007 12:33:41 -0500 [thread overview]
Message-ID: <46EC1775.4000709@us.ibm.com> (raw)
In-Reply-To: <1189827476.5982.143.camel-cxY/u30q8FloTgUnLF1by8fTvwmfpRNyZeezCHUQhQ4@public.gmane.org>
Zachary Amsden wrote:
> On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
>
>
>> So then each module creates a hypercall page using this magic MSR and
>> the hypervisor has to keep track of it so that it can appropriately
>> change the page on migration. The page can only contain a single
>> instruction or else it cannot be easily changed (or you have to be able
>> to prevent the guest from being migrated while in the hypercall page).
>>
>> We're really talking about identical models. Instead of an MSR, the #GP
>> is what tells the hypervisor to update the instruction. The nice thing
>> about this is that you don't have to keep track of all the current
>> hypercall page locations in the hypervisor.
>>
>
> I agree, multiple hypercall pages is insane. I was thinking more of a
> single hypercall page, fixed in place by the hypervisor, not the kernel.
>
> Then each module can read an MSR saying what VA the hypercall page is
> at, and the hypervisor can simply flip one page to switch architectures.
>
That requires a memory hole though. In KVM, we don't have a memory hole.
Regards,
Anthony Liguori
> Zach
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
next prev parent reply other threads:[~2007-09-15 17:33 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-14 19:45 [PATCH] Refactor hypercall infrastructure Anthony Liguori
[not found] ` <11897991353793-git-send-email-aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2007-09-14 19:47 ` Anthony Liguori
2007-09-14 20:53 ` Jeremy Fitzhardinge
2007-09-14 21:02 ` [kvm-devel] " Anthony Liguori
2007-09-14 21:02 ` Anthony Liguori
2007-09-14 21:20 ` [kvm-devel] " Zachary Amsden
2007-09-14 21:20 ` Zachary Amsden
2007-09-14 21:44 ` [kvm-devel] " Anthony Liguori
2007-09-14 21:44 ` Anthony Liguori
2007-09-15 3:37 ` [kvm-devel] " Zachary Amsden
2007-09-15 3:37 ` Zachary Amsden
2007-09-15 8:08 ` [kvm-devel] " Avi Kivity
2007-09-15 8:08 ` Avi Kivity
2007-09-15 17:33 ` Anthony Liguori [this message]
2007-09-15 17:33 ` Anthony Liguori
2007-09-14 21:22 ` [kvm-devel] " Jeremy Fitzhardinge
2007-09-14 21:22 ` Jeremy Fitzhardinge
2007-09-14 21:46 ` [kvm-devel] " Anthony Liguori
2007-09-14 21:46 ` Anthony Liguori
2007-09-14 21:52 ` [kvm-devel] " Jeremy Fitzhardinge
2007-09-14 21:52 ` Jeremy Fitzhardinge
2007-09-14 22:08 ` [kvm-devel] " Anthony Liguori
2007-09-14 22:08 ` Anthony Liguori
2007-09-14 22:40 ` [kvm-devel] " Nakajima, Jun
2007-09-14 22:40 ` Nakajima, Jun
2007-09-14 23:00 ` [kvm-devel] " Jeremy Fitzhardinge
2007-09-14 23:00 ` Jeremy Fitzhardinge
2007-09-15 0:10 ` [kvm-devel] " Nakajima, Jun
2007-09-15 0:10 ` Nakajima, Jun
2007-09-15 0:28 ` [kvm-devel] " Jeremy Fitzhardinge
2007-09-15 0:28 ` Jeremy Fitzhardinge
2007-09-15 1:04 ` [kvm-devel] " Nakajima, Jun
2007-09-15 1:04 ` Nakajima, Jun
2007-09-15 4:53 ` [kvm-devel] " Jeremy Fitzhardinge
2007-09-15 4:53 ` Jeremy Fitzhardinge
2007-09-15 6:11 ` [kvm-devel] " Nakajima, Jun
2007-09-15 6:11 ` Nakajima, Jun
2007-09-15 18:23 ` [kvm-devel] " Anthony Liguori
2007-09-17 18:14 ` Nakajima, Jun
2007-09-17 18:14 ` Nakajima, Jun
2007-09-17 18:27 ` [kvm-devel] " Anthony Liguori
2007-09-17 19:15 ` Jeremy Fitzhardinge
2007-09-17 19:15 ` Jeremy Fitzhardinge
2007-09-17 19:33 ` [kvm-devel] " Anthony Liguori
2007-09-17 19:33 ` Anthony Liguori
2007-09-17 19:15 ` [kvm-devel] " Jeremy Fitzhardinge
2007-09-17 20:52 ` Nakajima, Jun
2007-09-17 20:52 ` Nakajima, Jun
2007-09-15 8:00 ` [kvm-devel] " Avi Kivity
2007-09-15 8:00 ` Avi Kivity
2007-09-15 7:53 ` [kvm-devel] " Avi Kivity
2007-09-15 7:53 ` Avi Kivity
2007-09-15 2:35 ` Rusty Russell
2007-09-15 2:35 ` Rusty Russell
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=46EC1775.4000709@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=avi@qumranet.com \
--cc=jeremy@goop.org \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=zach@vmware.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.