[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Software Plugin Interface in Xen hypervisor
So you are talking about the guest and host having different instruction set architectures (ISA)? How different? Xen is not an instruction set emulator (though it does emulate some instructions under some situations). The reason Xen (and other hypervisors) are successful is because nearly all instructions are executed natively, at full performance, rather than using emulation, which is extremely slow. If you are researching minor architecture changes, you might consider a simulator such as Bochs or RSIM. If you are thinking about very different ISAs and binary translation, this might be of interest: http://www.hpl.hp.com/techreports/2007/HPL-2007-77.html Abstract: Virtualization is emerging as an important technology in future systems, providing an extra layer of abstraction between the hardware and operating system. Previous work on virtualization has focused on the partitioning, isolation, and encapsulation features of virtual machines and their use for different applications, but mainly in the context of a specific processor architecture. In this paper, we argue for integrating an interface transformation layer to virtualization, specifically combining virtualization with a dynamic binary translator. This feature significantly increases the benefits from current applications of virtualization (e.g., for server consolidation and resource provisioning) while potentially enabling additional new uses of virtualization matched with emerging trends (e.g., virtual appliances and heterogeneous hardware). We have built MagiXen - pronounced "magician" - a prototype implementation of a Xen virtual machine monitor with integrated binary translation that can run IA-32 virtual machines on Itanium platforms. We present performance results for several typical benchmarks and discuss insights from our experiences with building the prototype. > -----Original Message----- > From: Nimgaonkar, Satyajeet [mailto:SatyajeetNimgaonkar@xxxxxxxxxx] > Sent: Wednesday, October 27, 2010 1:06 PM > To: Nimgaonkar, Satyajeet; Gianni Tedesco > Cc: Xen Devel > Subject: RE: [Xen-devel] Software Plugin Interface in Xen hypervisor > > Hi Gianni, > I want to actually emulate the VCPU and Memory > Management Unit and force the DOM Us to run on this new VCPU and MMU. > Can you provide any pointers on how to achieve this? > Thank you very much. > > Regards, > Satyajeet > ________________________________________ > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [xen-devel- > bounces@xxxxxxxxxxxxxxxxxxx] on behalf of Nimgaonkar, Satyajeet > [SatyajeetNimgaonkar@xxxxxxxxxx] > Sent: Wednesday, October 27, 2010 10:07 AM > To: Gianni Tedesco > Cc: Xen Devel > Subject: RE: [Xen-devel] Software Plugin Interface in Xen hypervisor > > Thanks Gianni for those details, I will look into it. > ________________________________________ > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [xen-devel- > bounces@xxxxxxxxxxxxxxxxxxx] on behalf of Gianni Tedesco > [gianni.tedesco@xxxxxxxxxx] > Sent: Wednesday, October 27, 2010 9:02 AM > To: Nimgaonkar, Satyajeet > Cc: Xen Devel > Subject: RE: [Xen-devel] Software Plugin Interface in Xen hypervisor > > On Tue, 2010-10-26 at 17:24 +0100, Nimgaonkar, Satyajeet wrote: > > Hi Gianni, > > I don't want to emulate devices instead I just want to > create a mechanism by modifying Xen hypervisor such that I can plug in > any software prototype of an architecture. So basically this mechanism > will be a software plug in interface, something like how VTPM is > provided in Xen. > > I hope this helps you to understand my question. > > Thanks, > > Yes I just didn't know what you meant by "architecture." Basically this > means "emulated devices" afaict? I mean VTPM is just a hardware device > AIUI. What I said before about qemu being the place to implement > devices > is not strictly true. Some things, such as APIC's and timers are > implemented in the hypervisor for performance reasons. > > You may want to look at arch/x86/hvm/vlapic.c etc. for how this is done > for HVM domains. For PV domains I guess we would just expose the > relevant functionality through the hypercall interface. > > There isn't really a "plug in" architecture that lets you swap these > things in and out of the hypervisor at runtime. I think most devs are > just compiling hypervisor and etherbooting it on a separate test > machine > with serial console setup. > > It really depends on the very specifics of what you are doing but if > you > really want rapid dev and testing, I would consider implementing your > devices in qemu. > > Gianni > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |