Avi/Anthony:
        Following commit added #UD trap in KVM and do emulation in KVM.
It is good to avoid the mis hypercall instruction issue, but I am not
sure if it will have any serious side effect. I am blind to AMD
instruction, I assume, for example, AMD 3D now instruction may use
different binary and thus invalid_ops in Intel platform. If an
application with 3D now instructions is executed in Intel platform, now
KVM get #UD and may do emulation inside, will that cause problem rather
then we inject #UD to guest? If this suspicion is true, then probably we
need to do something more to this commitment, i.e. to emulate
cross-architecturally VMCALL instruction only for this purpose.

BTW, do we need to support live migrating an AMD VM to Intel platform or
vice versa?

thx,eddie



commit 8db6e3d54971e76019b02a6ad860c9df35218dfc
Date:   Mon Sep 17 14:57:50 2007 -0500

    KVM: Refactor hypercall infrastructure (v3)

    This patch refactors the current hypercall infrastructure to better
    support live migration and SMP.  It eliminates the hypercall page by
    trapping the UD exception that would occur if you used the wrong
hypercall
    instruction for the underlying architecture and replacing it with
the right
    one lazily.

    A fall-out of this patch is that the unhandled hypercalls no longer
trap to
    userspace.  There is very little reason though to use a hypercall to
    communicate with userspace as PIO or MMIO can be used.  There is no
code
    in tree that uses userspace hypercalls.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
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

Reply via email to