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? > hypercall page is different in the target host, you may need to apply > fixups. The fixups (and the hypercall page itself) may be different > according to the guest mode (32-bit or 64-bit). thx, eddie ------------------------------------------------------------------------- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
