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
|
Home