RE: [Xen-devel] Software Plugin Interface in Xen hypervisor

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

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