[lkml]   [2007]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [kvm-devel] [PATCH] Refactor hypercall infrastructure
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.

VA as in "Virtual Address"? the ppc people don't have
hypervisor-visible virtual addresses, and the hypervisor (on x86) can't
safely select a virtual address, and ...

That means you need a physical address, so you need a central
initialization routine, and drivers for unmodified OSes can no longer be
self contained.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-09-15 10:11    [W:0.049 / U:12.752 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site