From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Simon Martin" Subject: Porting an OS to Xen Date: Sun, 13 Oct 2013 20:28:27 +0000 Message-ID: Reply-To: Simon Martin Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2356790365390700047==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============2356790365390700047== Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="------=_MBE9451AA0-C5E9-462B-B946-429A90FFA8A5"; micalg=SHA1; protocol="application/x-pkcs7-signature" --------=_MBE9451AA0-C5E9-462B-B946-429A90FFA8A5 Content-Type: multipart/alternative; boundary="------=_MB1E673DDE-E1F2-4D3E-B466-5F6F84C8C515" --------=_MB1E673DDE-E1F2-4D3E-B466-5F6F84C8C515 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Hi all, I originally posted this on the xenproject Q&A forum, and it was=20 suggested that I repost it here. If it would be better posted elsewhere=20 then please let me know. Please skip the next paragraph if you're not=20 interested in the why. Over the last 2 decades I have been developing a real-time OS with one=20 of my customers (I was an employee when we started, a consultant for the= =20 last 15 years). This runs on our own hardware (originally TI TMS320C3x,=20 then MIPS64, then ARM9). The system started off 80% C 20% Assembly, and=20 is now about 99% C and 1% Assembly (just the bootstrapping). We now have= =20 a requirement to run this OS in parallel with Windows. I have looked at=20 various real-time hypervisors and Windows extensions, however I think we= =20 can get more mileage out of Xen due to the open source nature of the=20 project. I bought the book "The Definitive Guide to the Xen Hypervisor" as it was= =20 recommended by the xenproject Q&A forum and it is very interesting,=20 however the examples are 32 bit and I am working 64 bit, and let's say=20 that my x86 assembler is a bit rusty to say the least! My questions (I am running Xen 4.1.4 on Debian Wheezy): 1.- I have looked at MirageOS but I think it is overkill for what I want= =20 to do. I just want a basic C wrapper to allow Xen to load my software, I= =20 would prefer not to have to learn OCaml, but if this is what it takes,=20 then I'll have to do it. 2.- Is there any sample simple x86_64 code that I can work from to get=20 out of the starting blocks? 3.- xl complains about my image not being a bzImage. Is there anyway I=20 can avoid this error/warning? If not how do I convert my image to a=20 bzImage? I'd rather not have to port in half the Linux bootstrap. 4.- Despite xl complaining about the kernel not being in bzImage format=20 it still seems to run (I get the same error message from the MirageOS=20 but the image loads and runs OK). However it crashes and I have no way=20 of seeing what's going on. Is there any way to debug my guest startup=20 inside Xen? TIA and Regards. -- _ _ Debian GNU User Simon Martin | | (_)_ __ _ ___ __ Project Manager | | | | '_ \| | | \ \/ / Milliways | |___| | | | | |_| |> < mailto: smartin@milliways.cl |_____|_|_| |_|\__,_/_/\_\ Si Hoc Legere Scis Nimium Eruditionis Habes --------=_MB1E673DDE-E1F2-4D3E-B466-5F6F84C8C515 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,
 
I originally posted this on the xenproject Q&A forum, and it was= suggested that I repost it here. If it would be better posted elsewhere= then please let me know. Please skip the next paragraph if you're not inte= rested in the why.
 
Over the last 2 decades I have been developing a real-time OS with = one of my customers (I was an employee when we started, a consultant for= the last 15 years). This runs on our own hardware (originally TI TMS320C3x= , then MIPS64, then ARM9). The system started off 80% C 20% Assembly, and= is now about 99% C and 1% Assembly (just the bootstrapping). We now= have a requirement to run this OS in parallel with Windows. I have looked= at various real-time hypervisors and Windows extensions, however I think= we can get more mileage out of Xen due to the open source nature of the= project.
 
I bought the book "The Definitive Guide to the Xen Hypervisor" as it= was recommended by the xenproject Q&A forum and it is very interesting= , however the examples are 32 bit and I am working 64 bit, and let's say= that my x86 assembler is a bit rusty to say the least!
 
My questions (I am running Xen 4.1.4 on Debian Wheezy):
 
1.- I have looked at MirageOS but I think it is overkill for what I= want to do. I just want a basic C wrapper to allow Xen to load my software= , I would prefer not to have to learn OCaml, but if this is what it takes,= then I'll have to do it.
 
2.- Is there any sample simple x86_64 code that I can work from to = get out of the starting blocks?
 
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 bzIm= age? I'd rather not have to port in half the Linux bootstrap.
 
4.- Despite xl complaining about the kernel not being in bzImage forma= t 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?
 
TIA and Regards.
 
--
 _  &= nbsp;  _  Debian GNU User   Simon Martin
| | &n= bsp; (_)_ __  _   ___  __  Project Manager
|= |   | | '_ \| | | \ \/ /  Milliways
| |___| | | | | |_|= |>  <   mailto: smartin@milliways.cl
|_____|_|_|= |_|\__,_/_/\_\
Si Hoc Legere Scis Nimium Eruditionis Habes
 
--------=_MB1E673DDE-E1F2-4D3E-B466-5F6F84C8C515-- --------=_MBE9451AA0-C5E9-462B-B946-429A90FFA8A5 Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 Content-Type: application/x-pkcs7-signature; name=smime.p7s MIIIVAYJKoZIhvcNAQcCoIIIRTCCCEECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBS0w ggUpMIIEEaADAgECAhAultupDIDtq3vCYoDUlSd9MA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEzMDQyNDAwMDAwMFoXDTE0MDQyNDIzNTk1OVow JTEjMCEGCSqGSIb3DQEJARYUc21hcnRpbkBtaWxsaXdheXMuY2wwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCLVN5OXAUec1v+vEbYmVEJw/OlVY4R1rIclr4odMh5Z0XcsnVJkLrl5SJS JPOs6ZAY+ppg+A4dXeo6+Q0fyHu2c3wECoGbxHaRaaoTAK2KuiMVBEh0Ozo4fFfdlPGjaM1/bbSV g0w7DGFBRfW3Wu0Vb+ukJHxi5lUHIwicK84HSdz8yU/GRYQ6o2tly/C3Bfhx+/drDyUj8cjrNGV1 234+x3oPcK+DE7bTJN2hCzGQW+qAHOHk9Z7Ju5abEvHmPaGZ8L0oFoytgN78hl6ZQqRSP+oFsTKJ 7aGO742ntZc9kj82OLLjHj7UZSpV54zEEhSQeY3NNzeiqb9Ws4iX31FnAgMBAAGjggHkMIIB4DAf BgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQULVGLzH/Dnd1xxJHZvpVN M8ebq8AwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQG CysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEB ATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBO MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAW gRRzbWFydGluQG1pbGxpd2F5cy5jbDANBgkqhkiG9w0BAQUFAAOCAQEAJ7CpmrpwM2PKdGJeaXeo a3m7R59LPcSIK1zHdV4bz7dOJ2lj5gZ73A1DwC5057RmaVBI1OCXyLqh4Fm38neAV9r+hnrEMpxW rLSIk9fm2Jfl26c3Q8+/IXwUV12q80mTPw8DEkkPeHOyxG29uKBXvjKtzz7wR6iXJoh8m3t+niwX tBYyC9kd5cwUuhZFfWbRnyneI77SMIrE2OP366lmSG3GYdBGCVHlltae/hhz8nzQBhm28/Q3ZKA+ ieE8ws5nDMUmu0zzMfFF9tZ5V5A5O2rJlWI2zK3KIBVrd7EcaMN778VHxwioxbt1Kv4RUC/CsRyv Qx2DuaSQoxLWzVdagTGCAu8wggLrAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAultupDIDtq3vCYoDUlSd9MAkGBSsOAwIaBQCgggEbMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAxMzIwMjgyN1owIwYJKoZIhvcNAQkEMRYEFP0D 8yLJHhXPAV+zF/MSguHGXCZUMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMQswCQYDVQQGEwJH QjEQMA4GA1UEBxMHU2FsZm9yZDEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZAIQLpbbqQyA7at7wmKA1JUnfTANBgkqhkiG9w0BAQEFAASCAQAY xIx+YlW1trvcmV+u49pOuNIPcR1Q3rYW3aB0SuqfFies2XKIQ2lAC7V5KnH/Yw9qRRtAYFjZaGiw CrUkNIw/nrVvsCP3jjxeNJHs8jI4FYtKmKQ5GQA1hGo7enyZmX9R/aUut9xMJvR0/rDBSIy3sgsx yxMekHlaA5t+TE3t8OEHNxGhdQNwDs/P14bfHIAeaYSrWrBoyqezGY53YrEYyjHzV2oLceIdUNrD 7rFT+Yd2Sn+9ejW3BvVrK0+lurrcKGKpgDDJoXBebKEB0ZO+7AZI9qptvoCNbqwHVijmk+N9EUmZ eviQ1k52aVqeA5EkuT0m+RQzwhNI47mP6/8q --------=_MBE9451AA0-C5E9-462B-B946-429A90FFA8A5-- --===============2356790365390700047== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2356790365390700047==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Porting an OS to Xen Date: Mon, 14 Oct 2013 00:07:25 +0100 Message-ID: <525B27AD.9050103@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4597257067180381707==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Simon Martin , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============4597257067180381707== Content-Type: multipart/alternative; boundary="------------040302090003070103040601" --------------040302090003070103040601 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 13/10/2013 21:28, Simon Martin wrote: > Hi all, > > I originally posted this on the xenproject Q&A forum, and it was > suggested that I repost it here. If it would be better posted > elsewhere then please let me know. Please skip the next paragraph if > you're not interested in the why. I would say that you have found the correct place to be asking questions like this. > > Over the last 2 decades I have been developing a real-time OS with one > of my customers (I was an employee when we started, a consultant for > the last 15 years). This runs on our own hardware (originally TI > TMS320C3x, then MIPS64, then ARM9). The system started off 80% C 20% > Assembly, and is now about 99% C and 1% Assembly (just the > bootstrapping). We now have a requirement to run this OS in parallel > with Windows. I have looked at various real-time hypervisors and > Windows extensions, however I think we can get more mileage out of Xen > due to the open source nature of the project. > > I bought the book "The Definitive Guide to the Xen Hypervisor" as it > was recommended by the xenproject Q&A forum and it is very > interesting, however the examples are 32 bit and I am working 64 bit, > and let's say that my x86 assembler is a bit rusty to say the least! > > My questions (I am running Xen 4.1.4 on Debian Wheezy): > > 1.- I have looked at MirageOS but I think it is overkill for what I > want to do. I just want a basic C wrapper to allow Xen to load my > software, I would prefer not to have to learn OCaml, but if this is > what it takes, then I'll have to do it. > > 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. > > 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. > > 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. on_crash="pause" in your domain configuration file will leave the VM state to be inspected. "coredump-destroy" and "coredump-restart" are also alternatives. xl dump-core 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. 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. Hope this is somewhat helpful ~Andrew --------------040302090003070103040601 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 13/10/2013 21:28, Simon Martin wrote:
Hi all,
 
I originally posted this on the xenproject Q&A forum, and it was suggested that I repost it here. If it would be better posted elsewhere then please let me know. Please skip the next paragraph if you're not interested in the why.

I would say that you have found the correct place to be asking questions like this.

 
Over the last 2 decades I have been developing a real-time OS with one of my customers (I was an employee when we started, a consultant for the last 15 years). This runs on our own hardware (originally TI TMS320C3x, then MIPS64, then ARM9). The system started off 80% C 20% Assembly, and is now about 99% C and 1% Assembly (just the bootstrapping). We now have a requirement to run this OS in parallel with Windows. I have looked at various real-time hypervisors and Windows extensions, however I think we can get more mileage out of Xen due to the open source nature of the project.
 
I bought the book "The Definitive Guide to the Xen Hypervisor" as it was recommended by the xenproject Q&A forum and it is very interesting, however the examples are 32 bit and I am working 64 bit, and let's say that my x86 assembler is a bit rusty to say the least!
 
My questions (I am running Xen 4.1.4 on Debian Wheezy):
 
1.- I have looked at MirageOS but I think it is overkill for what I want to do. I just want a basic C wrapper to allow Xen to load my software, I would prefer not to have to learn OCaml, but if this is what it takes, then I'll have to do it.
 
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.

 
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.

 
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.

on_crash="pause" 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.

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.

Hope this is somewhat helpful

~Andrew
--------------040302090003070103040601-- --===============4597257067180381707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4597257067180381707==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Simon Martin" Subject: Re: Porting an OS to Xen Date: Mon, 14 Oct 2013 16:22:29 +0000 Message-ID: References: <525B27AD.9050103@citrix.com> Reply-To: Simon Martin Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2655126300748261514==" Return-path: In-Reply-To: <525B27AD.9050103@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============2655126300748261514== Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="------=_MB6F90EFCF-B651-4D3B-AA59-1710F768AB45"; micalg=SHA1; protocol="application/x-pkcs7-signature" --------=_MB6F90EFCF-B651-4D3B-AA59-1710F768AB45 Content-Type: multipart/alternative; boundary="------=_MB6CACD8C5-4CE9-42E5-A9BF-0AA2588D0739" --------=_MB6CACD8C5-4CE9-42E5-A9BF-0AA2588D0739 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Hi Andrew Thank you very much for your response. Comments in line. Regards. ------ Original Message ------ From: "Andrew Cooper" To: "Simon Martin" ; xen-devel@lists.xen.org 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= =20 >>out of the starting blocks? > >Yes. I am not familiar with what is distributed with Wheezy; you are=20 >probably better checking out from the git tree (=20 >http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dsummary ). In=20 >extras/MiniOS, you will find MiniOS which is a minimal example of=20 >getting code working as a paravirtualised guest. It should certainly=20 >be a good starting point and reference. Got it. Merging it with the 32 bit example code I have. Slowly getting=20 there! > >> >>3.- xl complains about my image not being a bzImage. Is there anyway I= =20 >>can avoid this error/warning? If not how do I convert my image to a=20 >>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=20 >format that a Linux kernel might be, which would typically be an Elf=20 >multiboot image with some form of compression. I am generating an ELF-64 binary. I have a feeling that this is a=20 "normal error" when starting a non-bzImage kernel. The mini-os example=20 causes the same error, so I will ignore it. > >> >>4.- Despite xl complaining about the kernel not being in bzImage=20 >>format it still seems to run (I get the same error message from the=20 >>MirageOS but the image loads and runs OK). However it crashes and I=20 >>have no way of seeing what's going on. Is there any way to debug my=20 >>guest startup inside Xen? > >There are several options depending on your preference. > >on_crash=3D"pause" in your domain configuration file will leave the VM=20 >state to be inspected. "coredump-destroy" and "coredump-restart" are=20 >also alternatives. > >xl dump-core should create an Elf CORE file representing= =20 >the domain. > >The gdbsx set of tools (tools/debugger/gdbsx) allow you to attach gdb=20 >to a running Xen domain. > >Getting a PV console working (see the early code from MiniOS) would=20 >allow you to print inforation. > >Failing a PV console, if you build yourself a debug version of Xen, you= =20 >can use the console_io hypercall from your guest and get debugging=20 >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=20 >or might not be aware of: Xen has "arinc653", a maintained realtime=20 >scheduler which will likely be more appropriate to your requirements=20 >than the default "credit" scheduler. For simplicity's sake at the moment I propose to run my VM as the only=20 VM on a vcpu. My assumption is that this way there will be no=20 scheduling. Is this assumption correct? > > >Hope this is somewhat helpful > >~Andrew --------=_MB6CACD8C5-4CE9-42E5-A9BF-0AA2588D0739 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Andrew
 
Thank you very much for your response. Comments in line.
 
Regards.
 
------ Original Message ------
From: "Andrew Cooper" <andrew.cooper3@citrix.com>
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=3Dxen.git;a=3Dsummary ).  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 bzIm= age? I'd rather not have to port in half the Linux bootstrap.

What format are you trying to boot?  It should be happy booti= ng 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 forma= t 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.

on_= crash=3D"pause" 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.

Hopeful= ly 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 defaul= t "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
= --------=_MB6CACD8C5-4CE9-42E5-A9BF-0AA2588D0739-- --------=_MB6F90EFCF-B651-4D3B-AA59-1710F768AB45 Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 Content-Type: application/x-pkcs7-signature; name=smime.p7s MIIIVAYJKoZIhvcNAQcCoIIIRTCCCEECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBS0w ggUpMIIEEaADAgECAhAultupDIDtq3vCYoDUlSd9MA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEzMDQyNDAwMDAwMFoXDTE0MDQyNDIzNTk1OVow JTEjMCEGCSqGSIb3DQEJARYUc21hcnRpbkBtaWxsaXdheXMuY2wwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCLVN5OXAUec1v+vEbYmVEJw/OlVY4R1rIclr4odMh5Z0XcsnVJkLrl5SJS JPOs6ZAY+ppg+A4dXeo6+Q0fyHu2c3wECoGbxHaRaaoTAK2KuiMVBEh0Ozo4fFfdlPGjaM1/bbSV g0w7DGFBRfW3Wu0Vb+ukJHxi5lUHIwicK84HSdz8yU/GRYQ6o2tly/C3Bfhx+/drDyUj8cjrNGV1 234+x3oPcK+DE7bTJN2hCzGQW+qAHOHk9Z7Ju5abEvHmPaGZ8L0oFoytgN78hl6ZQqRSP+oFsTKJ 7aGO742ntZc9kj82OLLjHj7UZSpV54zEEhSQeY3NNzeiqb9Ws4iX31FnAgMBAAGjggHkMIIB4DAf BgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQULVGLzH/Dnd1xxJHZvpVN M8ebq8AwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQG CysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEB ATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBO MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6 Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAW gRRzbWFydGluQG1pbGxpd2F5cy5jbDANBgkqhkiG9w0BAQUFAAOCAQEAJ7CpmrpwM2PKdGJeaXeo a3m7R59LPcSIK1zHdV4bz7dOJ2lj5gZ73A1DwC5057RmaVBI1OCXyLqh4Fm38neAV9r+hnrEMpxW rLSIk9fm2Jfl26c3Q8+/IXwUV12q80mTPw8DEkkPeHOyxG29uKBXvjKtzz7wR6iXJoh8m3t+niwX tBYyC9kd5cwUuhZFfWbRnyneI77SMIrE2OP366lmSG3GYdBGCVHlltae/hhz8nzQBhm28/Q3ZKA+ ieE8ws5nDMUmu0zzMfFF9tZ5V5A5O2rJlWI2zK3KIBVrd7EcaMN778VHxwioxbt1Kv4RUC/CsRyv Qx2DuaSQoxLWzVdagTGCAu8wggLrAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhAultupDIDtq3vCYoDUlSd9MAkGBSsOAwIaBQCgggEbMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAxNDE2MjIyOVowIwYJKoZIhvcNAQkEMRYEFOXy Z/if3aNiojFoflx6Z+M59Rr7MIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMQswCQYDVQQGEwJH QjEQMA4GA1UEBxMHU2FsZm9yZDEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZAIQLpbbqQyA7at7wmKA1JUnfTANBgkqhkiG9w0BAQEFAASCAQBn GB6xwGqfjLB8LORFllrKVxvXyoUA+zQ8IXT8j5shZqCTIpd4JciZgpqQLSW7BKLk2IOd2SQ9WgcR BNRQdk4gg04LRyOcSjW3rpX2tBJAHmZOHM/Jrd8Lxdf6vJ5i46UuVgwfsWduH67QOXLfxfBao2FK YJ5YAEwvhnbAL3qMsVKRKYWg4evVqcP8AZX+EY4nAIDWJ25zOUeEpLW+T1KyrIQh8Kx0m5ZB+Sku UiAcdjBn4e/rKauDTDcBDB0L7BbZtyAPu+Y9CYKLNu8ca+NpKkkIkkPpIIIpellTAvAUiGsKkRcq NSvi33HlFxvFWy5my5jxuELSI/R/db0RtcnK --------=_MB6F90EFCF-B651-4D3B-AA59-1710F768AB45-- --===============2655126300748261514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2655126300748261514==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Porting an OS to Xen Date: Mon, 14 Oct 2013 17:31:53 +0100 Message-ID: <1381768313.24708.126.camel@kazak.uk.xensource.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Simon Martin Cc: Andrew Cooper , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Mon, 2013-10-14 at 16:22 +0000, Simon Martin wrote: > > > 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. I think the error is just during probing where it checks to see if it is a bzImage and falls through to trying ELF if not. The message could probably be made less error-ry. Ian. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Porting an OS to Xen Date: Mon, 14 Oct 2013 17:37:43 +0100 Message-ID: <525C1DD7.7050105@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4481462987722499127==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Simon Martin Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============4481462987722499127== Content-Type: multipart/alternative; boundary="------------020304080801020706090708" --------------020304080801020706090708 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On 14/10/13 17:22, Simon Martin wrote: >> >> 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? Your best option would be to create a cpupool for the individual cpu you want your VM to be running on. This way you can schedule that cpu using arinc653 independently of dom0 and domU being scheduled using regular credit. ~Andrew --------------020304080801020706090708 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
On 14/10/13 17:22, Simon Martin wrote:

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?

Your best option would be to create a cpupool for the individual cpu you want your VM to be running on.  This way you can schedule that cpu using arinc653 independently of dom0 and domU being scheduled using regular credit.

~Andrew
--------------020304080801020706090708-- --===============4481462987722499127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4481462987722499127==--