Dong, Eddie wrote: > Avi Kivity wrote: > >> Dong, Eddie wrote: >> >>> Anthony Liguori wrote: >>> >>> >>>> Dong, Eddie wrote: >>>> >>>> >>>>> Anthony: >>>>> Actually I am wondering if the binary used for VMMCALL could be >>>>> assumed will never be used by Intel processor or vice versa. BTW, >>>>> what is the nenefit to remove hypercall page, which provide more >>>>> clean approach IMO? >>>>> >>>>> >>>>> >>>> A hypercall page doesn't help the situation with respect to >>>> migration between an AMD and Intel system. >>>> >>>> >>> I guess I miss something. As if hypercall page is read only after >>> creation (by VMM), later memory migration won't overlap it. The page >>> could be a "Reserved" in e820 table. >>> >>> >> If migration happens while rip is in the hypercall page, and if the >> > > I didn't quit catch here. The source VM vCPU is in Qemu migration part, > The target VM VCPU is always waiting for migration data/command. > If you mean SMP case, all target VCPUs are in waiting for data/cmd, > and I assume source VCPUs are all in Qemu known state, not? > > >
I'm talking about the guest rip. The guest is not aware of the migration. Suppose that on the last copy that the guest rip is (hypercall_page_virt + 3). This address might be in the middle of some instruction on the hypercall page on the target machine. You need to fix up rip and possibly modify registers so that when it resumes it works correctly. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
