On Tue, 14 Dec 2010 10:40:57 +0200 Avi Kivity <avi@xxxxxxxxxx> wrote: > On 12/13/2010 09:03 PM, Scott Wood wrote: > > > > > > The interface is a lot simpler. The guest decides what to patch and > > > where to jump. A "please patch me" flag needs a ton of documentation on > > > what patch means and what the constraints on the guest environment are. > > > > > > > The constraints need to be documented, but I think "a ton" is a bit of > > an exaggeration > > I guess. It's correct for x86 (which has four processor modes, and you > need to consider segmentation, etc.), perhaps not so much for powerpc. Yeah, x86 seems like it could be a mess. We actually already wrote up these constraints for PowerPC for an upcoming version of ePAPR. > > -- and having the guest do the patching itself means > > that the structure of the shared page must become stable ABI. > > It has to be a stable ABI in any case so you can live migrate. Unless > you want the hypervisor to unpatch or something. Well, there's a difference between "stable among a set of implementations within which you can live upgrade" and "stable among all implementations that can run a guest without further modification". I'm thinking of things like completely different hypervisors (not just KVM) being able to run the same guest image with paravirt, newly added paravirts working on a guest that doesn't need updating beyond the initial change to permit rewriting, etc. And if there is a mistake made that needs to be incompatibly corrected, breaking live migration seems less bad than requiring guest code changes. I think there are good arguments for both ways -- I don't see any overwhelming reason to change from what KVM is already doing. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
