embeddedxen-devel — EmbeddedXEN development discussions

Re: [Embeddedxen-devel] Status of this project and relationship with XEN-ARM?

[ROSSIER D. <Dan...@he...>]

> -----Original Message-----
> From: Charles Woloszynski [mailto:charles.woloszynski@packet-
> dynamics.com]
> Sent: mercredi 13 janvier 2010 19:14
> To: emb...@li...
> Subject: [Embeddedxen-devel] Status of this project and relationship with
> XEN-ARM?
> 
> I am looking to run Xen on an ARM processor. I have found both this project
> and the Xen ARM work and I am trying to understand their relationship.
> 
> Is there any relationship between these?  Which is more current?

Xen ARM mainly focuses on security and ACM issues in general and has been developed by Samsung which
has quite a lot of commercial constraints on their efforts, so I can not state about the ongoing work and status.
EmbeddedXEN focuses on realtime systems aspects; we have developed a particular dom U (called domU U-RT) which
relies on Xenomai interfaces (http://www.xenomai.org). We remove the I-pipe nanokernel mechanism which is used
by Xenomai to process interrupts and control the access to hardware from non-realtime execution domain.

We originally based our port on Xen ARM's one, but brought quite a lot of changes and also various fixes specific to our environment.

> 
> I am ultimately looking to run Android under Xen?  Has that been done for
> this?
> 
> Can I build embeddedXen and run it under the Android QEMU emulator?

Concerning Androïd,   it depends on what kind of ARM core are you using (if it is compliant with armv5 instruction set and MMU, it is OK), otherwise you need to adapt
some arch-dependent code of the hypervisor. This should be possible providing some minimal efforts. However, Android itself needs to get paravirtualized; it means you have to adapt
the OS at the IRQ, timer, memory access, etc. layers in order to be compliant with the hypervisor API (hypercalls/upcalls). In EmbeddedXEN, most of XEN API has been moved into a dedicated directory (xen_guest) at the root of the source tree.


> 
> Thanks in advance,
> 
> Charlie
> 
> 

Daniel

[Embeddedxen-devel] Status of this project and relationship with XEN-ARM?

[Charles W. <cha...@pa...>]

I am looking to run Xen on an ARM processor. I have found both this project and the Xen ARM work and I am trying to understand their relationship.

Is there any relationship between these?  Which is more current?

I am ultimately looking to run Android under Xen?  Has that been done for this?

Can I build embeddedXen and run it under the Android QEMU emulator?

Thanks in advance,

Charlie

[Embeddedxen-devel] New Alpha release

[ROSSIER D. <Dan...@he...>]

Hi Folks,


After some delays due to unexpected problems, we are finally coming up with a new (working) release of EmbeddedXEN, which
includes both dom0 and domU-RT.

A lot of new features and changes have been made in this release (please see git history for all details):

Version 2.0 (End of PENAR project)

* dom0 and domU now fully integrated in the single binary image.
* Script build-embeddedxen for facilitating the build of the kernel.
* Simple application embedded in the nucleus/ directory
* Support for QEMU/Mainstone and Colibri/PXA270 machines.


Technical information
--------------------------
* Simplified hypervisor and guest time management
* IRQs management has also been partially reworked out.
* Handling of page tables of XEN and guest OS now 100% running
* Simplified IRQ Timer management / Only a periodic tick is configured for each guest OS. Frequency is specified at setup.

Further details are to be found in git history.

We are now currently focusing on performance assessment in different scenarios. The kernel scheduler of XEN (currently sched_sedf) has not
been adapted yet. Further changes will come up soon.

Please, if you plan to work with EmbeddedXEN or help us in its development, do not hesitate to contact us via the mailing list.

Enjoy the new EmbeddedXEN!


Daniel

[Embeddedxen-devel] Next release to come.

[ROSSIER D. <Dan...@he...>]

Hello,

By end of November, we will release a new version of EmbeddedXEN including the integration of dom0 and domU-RT, the new realtime domain which runs on top of XEN.

The framework includes both XEN, dom0 Linux and domU-RT Xenomai which are three separate images included in one single binary file.
Makefiles have been deeply adapted and a lot of changes have been made.
You can still have a look at ongoing development across the git repository.

We will also provide a simple user guide at this time.

Keep in touch...

Cheers
Daniel

[Embeddedxen-devel] Last news in the git repository...

[ROSSIER D. <Dan...@he...>]

The current version of embeddedXEN in the sourceforge git repository enables the boot of a Linux dom0 nearly up to the end; we are still working on the timer IRQ upcall issue (timer IRQ are not visible yet in the guest).

This version also includes the Xenomai code which is gradually *activated*. The port currently consists in removing the tight integration with the I-pipe/adeos kernel. We expect to have something working by end of September.

Cheers
Daniel

[Embeddedxen-devel] Problem with mapcache

[ROSSIER D. <Dan...@he...>]

Hello,

We recently faced a problem with the mapcache object in the ARM port from Samsung (xen-arm), in the context of embeddedXEN.

The mapcache is actually used during the guest operation on the page table entry manipulations. The hypervisor performs updates in the mapcache (via the mmu_update hypercall) to avoid modifying the *real* physical page containing the entry to be modified. It makes sense and this is also done in the x86 version of xen. However, we didn't succeed in figuring out how the real page is finally modified (i.e. flushed from the mapcache).

We noticed this issue during the dom0 bootstrap:  the mmu_update hypercall is called (for instance during the pmd_clear() operation), but the pmd entry is not really modified.

I sent out this mail to the xen-arm mailing list as well in order to get Samsung's feedback concerning this issue. In the meanwhile, as workaround, we have used the map_domain_page_with_guest_va_space() function with the right addresses to perform the modification on the *real* entry, and it works.

Thanks in advance for any comment/feedback.

Cheers
Daniel

[Embeddedxen-devel] Xenomai integration in the EmbeddedXen tree

[GERBER P. <Pat...@he...>]

Hello,

I have started to integrate Xenomai in the EmbeddedXen tree. 
All the files are in the tree, but there are still some compilation conflicts because of ipipe dependencies. 
So the compilation of Xenomai is still disabled in the tree config menu.

I will work to resolve all those conflicts probably in the next two weeks.

Patrick

[Embeddedxen-devel] Git repository updated: xen_guest subtree and source trees cleaning

[ROSSIER D. <Dan...@he...>]

Hi Folks,

I reworked out a bit the source tree of embeddedXEN in order to paravirtualize Linux in a convenient way.
First, the xen_guest subtree has been created and should contain all generic routines and structures (include/xen_guest is
also available) for all guest OS. miniOS has now been aligned according to this organization and ongoing work on Linux
paravirt based upon Samsung's one takes into account the new structure.

Furthermore, there was quite a big cleaning in the xen/ subtree so that the compilation using the __XEN__ flag is fully
supported for all files located in xen/. __XEN__ is not necessary anymore in the other "guest"-dedicated subtrees.
The xen/arch/arm has also been cleaned; only the files necessary to the hypervisor are present; the other have been moved into
the arch/arm/* subtree.

Currently, adaptations have been made only for the Mainstone board, but not for the Colibri. It will be done in the upcoming weeks.


Kind regards
Daniel

Re: [Embeddedxen-devel] Information on Embedded Xen for ARM

[ROSSIER D. <Dan...@he...>]

> -----Original Message-----
> From: Venkatraman V [mailto:ven...@gm...]
> Sent: jeudi, 25. juin 2009 13:41
> To: ROSSIER Daniel
> Subject: Re: Information on Embedded Xen for ARM
> 
> Hello Daniel,
> 
> I had downloaded the sources from sourceforge. Could you please help me
> in knowing the order in which i should go about the build process?
> 
> I saw a .config file in the un-tarred directory, so I just did a
> 
> make ARCH=arm CROSS_COMPILE=/scratchbox/compilers/arm-linux-2007q1-
> 21/bin/arm-none-linux-gnueabi-
> 
> It built completely and zImage was created under xen
> (xen/arch/arm/boot/zImage).
> 
> Once this was done, I assumed, this to be the kernel image to be given
> to qemu, which i did, using the following command:
> 
> sudo qemu-system-arm -M spitz -kernel ./xen/arch/arm/boot/zImage -
> mtdblock ../kgdb/pxa_nand_rootfs_ecc -hda ../linux-
> 2.6.27.8_console/scsi.img -serial stdio
> 
> where
> 1) pxa_nand_rootd_ecc is a nand flash i had created (with just the
> busybox), since you have to give a mtd device for PXA (spitz) in qemu)
> 
> 2) the scsi.img is a filesystem image (ext2) which could be excluded
> too.
> 
> However, this is the error (in italics) I receive:
> 
> Error: unrecognized/unsupported machine ID (r1 = 0x000002c9).
> 
> Available machine support:
> 
> ID (hex)    NAME
> 00000196    Intel HCDDBBVA0 Development Platform (aka Mainstone) /
> EmbeddedXEN (xen-pxa270-qemu)
> 
> Please check your kernel config and/or bootloader.
> 
> 

Yes, this is normal since the image is compiled for a Mainstone/PXA270 platform. If you want to use the image with a Spitz board, you simply need to adapt the machine-specific files accordingly. But I would recommend to use Mainstone as the emulated PXA270 platform.

> Please let me know as to where I am going wrong?
> 
> Regards
> 
> VenkatRaman
> 
> 


Daniel
ps: you can also retrieve the last version grom git, but be careful because the .config is currently for a Colibri/PXA270 board (just need to change the CONFIG_MACH_xxx in .config)
> 
> 
> 
> On Tue, Jun 23, 2009 at 11:50 AM, ROSSIER Daniel <Daniel.Rossier@heig-
> vd.ch> wrote:
> Hi Venkatraman,
> 
> > -----Original Message-----
> > From: Venkatraman V [mailto:ven...@gm...]
> > Sent: mardi, 23. juin 2009 07:18
> > To: ROSSIER Daniel
> > Subject: Information on Embedded Xen for ARM
> >
> > Hello Daniel,
> >
> > I saw your project on source forge, regarding the Embedded Xen for
> ARM.
> > Way to go!
> >
> > I would like to have some information regarding the project (which I
> > couldnt find).
> >
> > - Is it like an embedded hypervisor for ARM ?
> >
> > or
> >
> > - Is it a Hypervisor, bundled with the Linux 2.6.18 and the miniOS
> > kernel, to show the possibility of multi-kernel functionality on
> > embedded systems?
> >
> Well, both statemetns are corrects; the hypervisor is embedded within a
> single image including Linux 2.6.18 and miniOS. In the coming days,
> we will also provide the Xenomai subtree which contains all APIs for
> hard realtime applications (see http://www.xenomai.org).
> 
> Indeed, we want to dig into multi-kernel (and virtualization)
> approaches for embedded systems, especially for hard realtime and also
> for applications and OS migrating from one environment to another.
> 
> > Would download the binary and try it on qemu and would give my
> > feedback.
> >
> Thanks. Please don't hesitate to ask questions if any, or simply keep
> us informed about your feedback and ideas.
> 
> > Regards
> >
> > VenkatRaman
> >
> > PS: I am new to virtualization and linux environment, please bear
> with
> > me, in case I ask irrelevant questions...
> No worry.
> 
> Daniel

[Embeddedxen-devel] Hypervisor end address and updated git version for Colibri/PXA270

[ROSSIER D. <Dan...@he...>]

The end address of the hypervisor area has been changed to 0xfffe0000 because the (whole) d-cache flush of Xscale processor need to be transferred to this address as temporary buffer. This is specified in arch/arm/mach-pxa/generic.c (for all PXAs). Therefore the size of the hypervisor is 16 MB - 64 Ko which are reserved to this cache flush operation. Therefore, HYPERVISOR_SIZE has been reduced accordingly (include/asm/config.h).

Now, the git version also supports the Colibri/PXA270. Please, be careful with .config depending on if you use QEMU or the Colibri/PXA270 board; you must adapt the CONFIG_MACH_* accordingly (and only that).

Daniel

Re: [Embeddedxen-devel] [Xenomai-help] Running Xenomai in a virtual machine

[ROSSIER D. <Dan...@he...>]

> -----Original Message-----
> From: Jan Kiszka [mailto:jan...@si...]
> Sent: lundi, 22. juin 2009 15:55
> To: ROSSIER Daniel
> Cc: Johan Visser; xen...@gn...
> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
> 
> ROSSIER Daniel wrote:
> > Just going through this interesting thread, I though it might be of
> interest - probably not fully related to the topic, but... - to know
> > that we are currently working on some integration efforts of Xenomai
> on top of the XEN hypervisor in the context of the
> > embeddedXEN project. For the time being, it is purely devoted to ARM-
> based processors.
> >
> > In case of interest, please visit:
> https://sourceforge.net/projects/embeddedxen. Xenomai will appear as a
> natural subtree of embeddedXEN, like xen or minios,
> > but currently it is not present yet. The hypervisor and miniOS boots
> up in Mainstone/QEMU and soon on a Colibri/PXA270 board. EmbeddedXEN is
> mainly devoted to integrate multiple kernels into a single binary image
> for embedded systems with the support of hard realtime (domainU-RT, a
> new kind of Xen domain).
> 
> Interesting, will have a look (again). Last time I checked was two
> years
> ago when MontaVista (IIRC) announced it. Does/will this version Xen not
> suffer from the RT problems Xen upstream has, e.g. lacking
> preemptibility?

Indeed, it is a major point we want to investigate; we will assess the overhead bound 
to the upcall model of XEN. It is too early to make some predictions

> 
> And what will be the impact on Xenomai? A new sub-arch per real arch?
> Will Xenomai run stand-alone or together with a Linux kernel as on real
> silicon? In the former case, what will be the programming model,
> specifically regarding RT<->non-RT communication?

We are actually working out a standalone version of Xenomai (removing i-pipe) keeping 
the strict minimum of Linux functionalities in order to bootstrap a simple Xenomai domain (memory manager, .
I do not have yet a clear vision of how the RT/non-RT communication will look like, but probably
it will rely on the event channel mechanisms of XEN. Maybe Patrick can tell us more about that...

Daniel


> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux

Re: [Embeddedxen-devel] [Xenomai-help] Running Xenomai in a virtual machine

[ROSSIER D. <Dan...@he...>]

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gil...@xe...]
> Sent: lundi, 22. juin 2009 17:17
> To: ROSSIER Daniel
> Cc: Jan Kiszka; xen...@gn...; GERBER Patrick; embeddedxen-
> de...@li...
> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
> 
> ROSSIER Daniel wrote:
> >> -----Original Message-----
> >> From: Gilles Chanteperdrix [mailto:gil...@xe...]
> >> Sent: lundi, 22. juin 2009 16:27
> >> To: ROSSIER Daniel
> >> Cc: Jan Kiszka; xen...@gn...; GERBER Patrick; embeddedxen-
> >> de...@li...
> >> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
> >>
> >> ROSSIER Daniel wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Kiszka [mailto:jan...@si...]
> >>>> Sent: lundi, 22. juin 2009 15:55
> >>>> To: ROSSIER Daniel
> >>>> Cc: Johan Visser; xen...@gn...
> >>>> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
> >>>>
> >>>> ROSSIER Daniel wrote:
> >>>>> Just going through this interesting thread, I though it might be
> of
> >>>> interest - probably not fully related to the topic, but... - to
> know
> >>>>> that we are currently working on some integration efforts of
> >> Xenomai
> >>>> on top of the XEN hypervisor in the context of the
> >>>>> embeddedXEN project. For the time being, it is purely devoted to
> >> ARM-
> >>>> based processors.
> >>>>> In case of interest, please visit:
> >>>> https://sourceforge.net/projects/embeddedxen. Xenomai will appear
> as
> >> a
> >>>> natural subtree of embeddedXEN, like xen or minios,
> >>>>> but currently it is not present yet. The hypervisor and miniOS
> >> boots
> >>>> up in Mainstone/QEMU and soon on a Colibri/PXA270 board.
> EmbeddedXEN
> >> is
> >>>> mainly devoted to integrate multiple kernels into a single binary
> >> image
> >>>> for embedded systems with the support of hard realtime (domainU-
> RT,
> >> a
> >>>> new kind of Xen domain).
> >>>>
> >>>> Interesting, will have a look (again). Last time I checked was two
> >>>> years
> >>>> ago when MontaVista (IIRC) announced it. Does/will this version
> Xen
> >> not
> >>>> suffer from the RT problems Xen upstream has, e.g. lacking
> >>>> preemptibility?
> >>> Indeed, it is a major point we want to investigate; we will assess
> >> the overhead bound
> >>> to the upcall model of XEN. It is too early to make some
> predictions
> >>>
> >>>> And what will be the impact on Xenomai? A new sub-arch per real
> >> arch?
> >>>> Will Xenomai run stand-alone or together with a Linux kernel as on
> >> real
> >>>> silicon? In the former case, what will be the programming model,
> >>>> specifically regarding RT<->non-RT communication?
> >>> We are actually working out a standalone version of Xenomai
> (removing
> >> i-pipe) keeping
> >>> the strict minimum of Linux functionalities in order to bootstrap a
> >> simple Xenomai domain (memory manager, .
> >>> I do not have yet a clear vision of how the RT/non-RT communication
> >> will look like, but probably
> >>> it will rely on the event channel mechanisms of XEN. Maybe Patrick
> >> can tell us more about that...
> >>
> >> Maybe a stupid question: but does the Xen domain/context switch
> routine
> >> flush the cache?
> >
> > Not really a stupid question: every time a MMU-context switch occurs,
> the flash is
> > invalidated, therefore mostly each time there is a domain context
> switch.
> > The way how it is invalidated will depend on the processor; it is
> badly implemented
> > with PXA270/Xscale where the entire cash is flushed, requiring quite
> a lot of latency...
> > We can improve it using the Fast Context Switching Extension, but
> never made some tests with that.
> 
> The problem I see with FCSE is that you will need a way to allocate the
> PIDs globally, i.e. at Xen level.
> 

Yeap. It will definitively not be obvious to manage. Thanks anyway for raising up the issue. 
Any idea is welcome....
> --
>                                           Gilles

Re: [Embeddedxen-devel] [Xenomai-help] Running Xenomai in a virtual machine

[ROSSIER D. <Dan...@he...>]

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gil...@xe...]
> Sent: lundi, 22. juin 2009 16:27
> To: ROSSIER Daniel
> Cc: Jan Kiszka; xen...@gn...; GERBER Patrick; embeddedxen-
> de...@li...
> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
> 
> ROSSIER Daniel wrote:
> >> -----Original Message-----
> >> From: Jan Kiszka [mailto:jan...@si...]
> >> Sent: lundi, 22. juin 2009 15:55
> >> To: ROSSIER Daniel
> >> Cc: Johan Visser; xen...@gn...
> >> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
> >>
> >> ROSSIER Daniel wrote:
> >>> Just going through this interesting thread, I though it might be of
> >> interest - probably not fully related to the topic, but... - to know
> >>> that we are currently working on some integration efforts of
> Xenomai
> >> on top of the XEN hypervisor in the context of the
> >>> embeddedXEN project. For the time being, it is purely devoted to
> ARM-
> >> based processors.
> >>> In case of interest, please visit:
> >> https://sourceforge.net/projects/embeddedxen. Xenomai will appear as
> a
> >> natural subtree of embeddedXEN, like xen or minios,
> >>> but currently it is not present yet. The hypervisor and miniOS
> boots
> >> up in Mainstone/QEMU and soon on a Colibri/PXA270 board. EmbeddedXEN
> is
> >> mainly devoted to integrate multiple kernels into a single binary
> image
> >> for embedded systems with the support of hard realtime (domainU-RT,
> a
> >> new kind of Xen domain).
> >>
> >> Interesting, will have a look (again). Last time I checked was two
> >> years
> >> ago when MontaVista (IIRC) announced it. Does/will this version Xen
> not
> >> suffer from the RT problems Xen upstream has, e.g. lacking
> >> preemptibility?
> >
> > Indeed, it is a major point we want to investigate; we will assess
> the overhead bound
> > to the upcall model of XEN. It is too early to make some predictions
> >
> >> And what will be the impact on Xenomai? A new sub-arch per real
> arch?
> >> Will Xenomai run stand-alone or together with a Linux kernel as on
> real
> >> silicon? In the former case, what will be the programming model,
> >> specifically regarding RT<->non-RT communication?
> >
> > We are actually working out a standalone version of Xenomai (removing
> i-pipe) keeping
> > the strict minimum of Linux functionalities in order to bootstrap a
> simple Xenomai domain (memory manager, .
> > I do not have yet a clear vision of how the RT/non-RT communication
> will look like, but probably
> > it will rely on the event channel mechanisms of XEN. Maybe Patrick
> can tell us more about that...
> 
> Maybe a stupid question: but does the Xen domain/context switch routine
> flush the cache?

Not really a stupid question: every time a MMU-context switch occurs, the flash is 
invalidated, therefore mostly each time there is a domain context switch. 
The way how it is invalidated will depend on the processor; it is badly implemented
with PXA270/Xscale where the entire cash is flushed, requiring quite a lot of latency...
We can improve it using the Fast Context Switching Extension, but never made some tests with that.


Daniel

> 
> --
>                                           Gilles

[Embeddedxen-devel] Domain blocking - wrong behaviour

[ROSSIER D. <Dan...@he...>]

Hello,

Doing some tests with miniOS, we faced the following problem: 

The guest OS may block itself until the next event (whatever the event is) via the appropriate hypercall (HYPERVISOR_sched_op(SCHEDOP_block, 0). 

However, the hypervisor unblocks the domain as soon as an event occurs. If the next event happens to early, the hypervisor will unblock the domain even before the hypercall has blocked it, hence the guest OS waits indefinitely. To avoid this behaviour, we adapted the common/schedule.c hypervisor scheduler: the do_set_timer_op() has been modified in order to check if the offset is negative; in this case, it returns -1 and the guest OS can test return value before deciding if blocking itself or not.


Cheers
Daniel

[Embeddedxen-devel] New development release of EmbeddedXEN

[ROSSIER D. <Dan...@he...>]

Hello,

We just released a new version of embeddedXEN at sourceforge

The EmbeddedXEN project aims at building a single multi-kernel binary image that can be used on ARM platform with hard realtime applications.
Currently, a full integration of the hypervisor, miniOS and Linux kernel has been achieved. However, only miniOS is running as guest OS for the time being.
The ARM port is based on two major contributions: the first attempt from MontaVista, and the excellent work from Samsung which allowed us to speed up the development.

Further information are available at:  https://sourceforge.net/projects/embeddedxen

Next work will be (simplified roadmap):
-       to adapt the source tree in order to support the PXA270/Colibri platform (our first target platform)
-       to enable a paravirtualized version of Linux (which will also be inspired from Samsung's work)
-       to modify the hypervisor and to create a domainU-RT (Realtime) which will allows XENOMAI applications to run as guest OS (the hypervisor will replace the i-pipe nanokernel)
-       to enhance embeddedXEN with more features like grant-table which are currently not used.
-       to migrate on an ARM11-based i.M31 platform (phyCORE from Phytec)

Please be aware that the project still remains at an experimental and academic stage.

Any interest in making some contributions are welcome.

Kind regards
Daniel

[Embeddedxen-devel] Revised virtual and memory layout

[ROSSIER D. <Dan...@he...>]

Hello,

I've updated a new version of the virtual and physical memory layout of embeddedXEN.
You can find a pdf in the documentation section.

The main change is related to the 1:1 mapping of the hypervisor virtual addr space on the physical space:
Now the physical addr space of the hypervisor has moved on top of the RAM in order to simplify the original 1:1 mapping
during the bootstrap process.

Cheers
Daniel

[Embeddedxen-devel] Page tables allocation in the guest OS

[ROSSIER D. <Dan...@he...>]

Hi Folks,

There is a major difference between Samsung's port and EmbeddedXEN (close to x86 XEN tree) with respect to the way how page tables are allocated in miniOS (and probably with other guest OS): in Samsung's port, page tables are completely allocated during the domain construction in the hypervisor (taking into account the size of the guest OS). In their case, page tables are not built in bootstrap of miniOS. In the opposite, EmbeddedXEN is more aligned with the "official" method: only the minimal pages are allocated in the guest OS (remember the code in embeddedXEN in already allocated at the very beginning of hypervisor bootstrap) and thus, miniOS will perform the page table allocation during the bootstrap, based on the number of mfn which are passed via the start_info structure. Further explanations about miniOS bootstrap code can be found here: www.cs.uic.edu/~spopuri/minios.html

Another comment: in the include files, constants with prefix like L1_* or L2_* usually refer to some constants about the different level of page tables. L1 does NOT refer to the 1st-level page table (PGD or TTB for ARM), but the "last-level" (2nd) page table ("PTE" page table). For example, the constants below are defined in include/minos/arm/arch_mm.h

//#define L1_PAGETABLE_SHIFT      12
//#define L2_PAGETABLE_SHIFT      22
#define L1_PAGETABLE_SHIFT      12
#define L2_PAGETABLE_SHIFT      20

//#define L1_PAGETABLE_ENTRIES    1024
//#define L2_PAGETABLE_ENTRIES    1024
#define L1_PAGETABLE_ENTRIES    256  /* Coarse page table */
#define L2_PAGETABLE_ENTRIES    4096 /* TTB */

For ARM, the number of entries in the 1st level page table (L2_PAGETABLE_ENTRIES) is now 4096, since we consider only coarse page table entries for our 4KB pages. Consequently, there are 4 page frames which are dedicated to the 1st-level page table, and ARM enables to have 4 page tables per frame (aligned to 1KB) since there are only 256 entries in 2nd-level page table.

Daniel

Re: [Embeddedxen-devel] Welcome to this new mailing list

[ROSSIER D. <Dan...@he...>]

Hi Folks,

You are now in the new mailing list of the embeddedXEN project. I hope that mail exchanges will be fruitful and numerous.

(I'm writing this mail also to check the validity of the list).

Kind regards
Daniel