[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1189827476.5982.143.camel@bodhitayantram.eng.vmware.com>
Date: Fri, 14 Sep 2007 20:37:56 -0700
From: Zachary Amsden <zach@...are.com>
To: Anthony Liguori <anthony@...emonkey.ws>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>,
Anthony Liguori <aliguori@...ibm.com>,
kvm-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
Avi Kivity <avi@...ranet.com>
Subject: Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure
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.
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists