Re: [Xen-devel] Porting an OS to Xen

["Simon Martin" <smartin@xxxxxxxxxxxx>]

Hi Andrew

 

Thank you very much for your response. Comments in line.

 

Regards.

 

------ Original Message ------

From: "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>

To: "Simon Martin" <smartin@xxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxx

Sent: 13/10/2013 20:07:25

Subject: Re: [Xen-devel] Porting an OS to Xen

On 13/10/2013 21:28, Simon Martin wrote: 

2.- Is there any sample simple x86_64 code that I can work from to get out of the starting blocks?

Yes.  I am not familiar with what is distributed with Wheezy; you are probably better checking out from the git tree ( http://xenbits.xen.org/gitweb/?p=xen.git;a=summary ).  In extras/MiniOS, you will find MiniOS which is a minimal example of getting code working as a paravirtualised guest.  It should certainly be a good starting point and reference.

Got it. Merging it with the 32 bit example code I have. Slowly getting there! 

 

3.- xl complains about my image not being a bzImage. Is there anyway I can avoid this error/warning? If not how do I convert my image to a bzImage? I'd rather not have to port in half the Linux bootstrap.

What format are you trying to boot?  It should be happy booting any format that a Linux kernel might be, which would typically be an Elf multiboot image with some form of compression.

I am generating an ELF-64 binary. I have a feeling that this is a "normal error" when starting a non-bzImage kernel. The mini-os example causes the same error, so I will ignore it.

 

4.- Despite xl complaining about the kernel not being in bzImage format it still seems to run (I get the same error message from the MirageOS but the image loads and runs OK). However it crashes and I have no way of seeing what's going on. Is there any way to debug my guest startup inside Xen?

There are several options depending on your preference.

in your domain configuration file will leave the VM state to be inspected.  "coredump-destroy" and "coredump-restart" are also alternatives.

xl dump-core <domid> <file> should create an Elf CORE file representing the domain.

The gdbsx set of tools (tools/debugger/gdbsx) allow you to attach gdb to a running Xen domain.

Getting a PV console working (see the early code from MiniOS) would allow you to print inforation.

Failing a PV console, if you build yourself a debug version of Xen, you can use the console_io hypercall from your guest and get debugging messages into the Xen console.

Hopefully that should be enough to get started with debugging.

Perfect. 

One final thing which come to mind given your request which you might or might not be aware of:  Xen has "arinc653", a maintained realtime scheduler which will likely be more appropriate to your requirements than the default "credit" scheduler.

For simplicity's sake at the moment I propose to run my VM as the only VM on a vcpu. My assumption is that this way there will be no scheduling. Is this assumption correct?

Hope this is somewhat helpful

~Andrew

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel