From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Simon Martin" Subject: Mapping shared pages from Windows Date: Fri, 25 Oct 2013 19:35:10 +0000 Message-ID: Reply-To: Simon Martin Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5263515305470309727==" 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 --===============5263515305470309727== Content-Type: multipart/alternative; boundary="------=_MBA442B527-99DC-44FF-B7EC-3E807F7D9990" --------=_MBA442B527-99DC-44FF-B7EC-3E807F7D9990 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Hi all, I have been working on my little OS port and things seem to be going=20 reasonably OK. I am writing it from the ground up using David Chisnall's= =20 book "The Definitive Guide to the Xen Hypervisor" and referring to the=20 mini-os implementation. I find there are too many dependencies and=20 additional bits in the mini-os code to just pull the bits out that I=20 need. Maybe once I've got a better understanding I'll be able to go back= =20 and do something there. My next channel is to talk to my little OS from a Windows HVM. As a=20 start I have offered a shared page from my domain which I want to map in= =20 a little Windows app. I have been looking for a Windows API to access Xen, but I haven't found= =20 anything. I took a quick look at the GPLPV drivers but that is quite a=20 large set of files. Is there an easier starting point, and maybe even a=20 little documentation? Regards. -- _ _ Debian GNU User Simon Martin | | (_)_ __ _ ___ __ Project Manager | | | | '_ \| | | \ \/ / Milliways | |___| | | | | |_| |> < mailto: smartin@milliways.cl |_____|_|_| |_|\__,_/_/\_\ Si Hoc Legere Scis Nimium Eruditionis Habes --------=_MBA442B527-99DC-44FF-B7EC-3E807F7D9990 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi all,

I have been working on my little OS port and things seem to be going= reasonably OK. I am writing it from the ground up using David Chisnall's= book "The Definitive Guide to the Xen Hypervisor" and referring to the = mini-os implementation. I find there are too many dependencies and addition= al bits in the mini-os code to just pull the bits out that I need. Maybe= once I've got a better understanding I'll be able to go back and do someth= ing there.

My next channel is to talk to my little OS from a Windows HVM. As a= start I have offered a shared page from my domain which I want to map in= a little Windows app.

I have been looking for a Windows API to access Xen, but I haven't = found anything. I took a quick look at the GPLPV drivers but that is q= uite a large set of files. Is there an easier starting point, and maybe = even a little documentation?

Regards.

--
_  &= nbsp; _ Debian GNU User   Simon Martin
| | &n= bsp; (_)_ __ _   ___ __ Project Manager
|= |   | | '_ \| | | \ \/ / Milliways
| |___| | | | | |_|= |> <   mailto: smartin@milliways.cl
|_____|_|_|= |_|\__,_/_/\_\
Si Hoc Legere Scis Nimium Eruditionis Habes

--------=_MBA442B527-99DC-44FF-B7EC-3E807F7D9990-- --===============5263515305470309727== 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 --===============5263515305470309727==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Harper Subject: Re: Mapping shared pages from Windows Date: Fri, 25 Oct 2013 22:48:39 +0000 Message-ID: <6035A0D088A63A46850C3988ED045A4B665C6819@BITCOM1.int.sbss.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US 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 > Hi all, > > I have been working on my little OS port and things seem to be going > reasonably OK. I am writing it from the ground up using David Chisnall's book > "The Definitive Guide to the Xen Hypervisor" and referring to the mini-os > implementation. I find there are too many dependencies and additional bits > in the mini-os code to just pull the bits out that I need. Maybe once I've got a > better understanding I'll be able to go back and do something there. > > My next channel is to talk to my little OS from a Windows HVM. As a start I > have offered a shared page from my domain which I want to map in a little > Windows app. > > I have been looking for a Windows API to access Xen, but I haven't found > anything. I took a quick look at the GPLPV drivers but that is quite a large set > of files. Is there an easier starting point, and maybe even a little > documentation? > Under GPLPV, everything is currently done via mapping a page from Windows into Dom0 (or driver domain). Apart from a few cases at startup I don't think I map any foreign pages into Windows. The typical design of a xen driver (eg net/disk) is that you have a shared page for the io ring, an event channel for the front and backend drivers to deliver events to each other, and then the messages on the io ring may include grant references to other pages of memory for buffer passing. I think it would be possible to map a foreign page into Windows by swapping out the pfn of the foreign page with a windows page, or maybe to map it into the windows io space designated by the pci device used for interrupt delivery (although that is a limited resource). The other thing is that pretty much all of this happens in kernel space. Mapping a page of memory from Windows kernel to user space is something you'd probably try and avoid if possible (read ntdev archives for many, many opinions on this :) Mapping a page from userspace into xen would be better, but then your os would need to handle mapping the page from windows. I'll ask on the ntdev list about this as I'm curious now... GPLPV has some basic xenbus functionality available from userspace (enough for the shutdownmon app to detect that dom0 has requested a shutdown/reboot/whatever), but no functionality for event channel or grant table calls. Ideally these would be implemented in GPLPV to match the ioctl's that Linux uses and so the api libraries could be ported across, but that's a bit of work and I haven't had a need to do it so far. So... what are you going to do with this shared memory you are mapping? Does it need an associated event channel? Will it be a shared io ring with other mapped pages or will you just be passing tiny messages? If you are just passing tiny messages, and there isn't any particular performance requirements, maybe you could use xenbus to write into the xenstore and pass messages that way. A message every few seconds would be fine. 100 messages a second via xenbus might be too much. I'm happy to fix any bugs or shortcomings you find in the GPLPV side of the xenbus code. And I can look at adding event channel and page passing (which would allow a complete device implementation in userspace), but no guarantee I will be able to get anything done quickly. And you'd either need to handle the IOCTL calls yourself, or port over the various libraries from xen (the IOCTL's are pretty raw). James From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Simon Martin" Subject: Re: Mapping shared pages from Windows Date: Sun, 27 Oct 2013 22:43:40 +0000 Message-ID: References: <6035A0D088A63A46850C3988ED045A4B665C6819@BITCOM1.int.sbss.com.au> Reply-To: Simon Martin Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1397581866780590034==" Return-path: In-Reply-To: <6035A0D088A63A46850C3988ED045A4B665C6819@BITCOM1.int.sbss.com.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: James Harper , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1397581866780590034== Content-Type: multipart/related; boundary="=_wombat.nemo.cl-29681-1382913888-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_wombat.nemo.cl-29681-1382913888-0001-2 Content-Type: multipart/alternative; boundary="=_wombat.nemo.cl-29681-1382913888-0001-3" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_wombat.nemo.cl-29681-1382913888-0001-3 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wow, Thanks James. Much more information here than I expected! This mail list= =20 definitely rocks. My comments in line. Regards. >Under GPLPV, everything is currently done via mapping a page from=20 >Windows into Dom0 (or driver domain). Apart from a few cases at startup= =20 >I don't think I map any foreign pages into Windows. This is my use case. I will set up a static set of pages at start and=20 they won't change during execution. >The typical design of a xen driver (eg net/disk) is that you have a=20 >shared page for the io ring, an event channel for the front and backend= =20 >drivers to deliver events to each other, and then the messages on the=20 >io ring may include grant references to other pages of memory for=20 >buffer passing. I think it would be possible to map a foreign page into= =20 >Windows by swapping out the pfn of the foreign page with a windows=20 >page, or maybe to map it into the windows io space designated by the=20 >pci device used for interrupt delivery (although that is a limited=20 >resource). > >The other thing is that pretty much all of this happens in kernel=20 >space. Mapping a page of memory from Windows kernel to user space is=20 >something you'd probably try and avoid if possible (read ntdev archives= =20 >for many, many opinions on this Mapping a page from userspace into xen=20 >would be better, but then your os would need to handle mapping the page= =20 >from windows. I'll ask on the ntdev list about this as I'm curious=20 >now... This is exactly what I would like to do. That way I avoid Windows=20 user->kernel transition to access the page. I've just found your mail on= =20 NTDEV. It'll be interesting to see what comes back. At the moment I envisage sharing one page as a set of circular buffers=20 and event channels. If I can run this in user space then perfect,=20 otherwise I will have to write it as a kernel driver. I've written a=20 couple of Windows drivers (one USB and one PCI driver) in the past, but=20 userspace is much easier to debug. > >GPLPV has some basic xenbus functionality available from userspace=20 >(enough for the shutdownmon app to detect that dom0 has requested a=20 >shutdown/reboot/whatever), but no functionality for event channel or=20 >grant table calls. Ideally these would be implemented in GPLPV to match= =20 >the ioctl's that Linux uses and so the api libraries could be ported=20 >across, but that's a bit of work and I haven't had a need to do it so=20 >far. I don't know enough about xenbus yet to say anything about this. It's a=20 steep learning curve. Documentation seems to be 99% oriented to=20 administering Xen instances, I can find very little about Xen=20 development. Is that the situation or am I missing something? >So... what are you going to do with this shared memory you are mapping?= =20 >Does it need an associated event channel? Will it be a shared io ring=20 >with other mapped pages or will you just be passing tiny messages? If=20 >you are just passing tiny messages, and there isn't any particular=20 >performance requirements, maybe you could use xenbus to write into the=20 >xenstore and pass messages that way. A message every few seconds would=20 >be fine. 100 messages a second via xenbus might be too much. I am porting a real-time embedded OS that I originally developed on a=20 Texas Instruments TMS320C3x DSP on proprietary hardware. This was then=20 ported to MIPS64 (again on proprietary hardware) and now finally it's=20 running on an ARM9. I have already ported this to a Windows user space=20 application and run it as a simulator. Of course timing is all shot and=20 you can't use it to control any real time processes, but it suffices to=20 be able to program on the hoof without real hardware. The current project will run this simulator on a dedicated processing=20 core using the arinc653 scheduler (as recommended by Andrew Cooper) and=20 making it real time again. I will provide two interfaces to Windows user= =20 space applications, one that emulates the current TCP/Serial command=20 line interface we already have, and another that will provide low level=20 hooks into the OS functionality so we can provide tight integration=20 between Windows applications and the OS. I will use a shared memory block because I can end up pushing down tons=20 of data and the access is totally asynchronous and involves no other=20 processes. > >I'm happy to fix any bugs or shortcomings you find in the GPLPV side of= =20 >the xenbus code. And I can look at adding event channel and page=20 >passing (which would allow a complete device implementation in=20 >userspace), but no guarantee I will be able to get anything done=20 >quickly. And you'd either need to handle the IOCTL calls yourself, or=20 >port over the various libraries from xen (the IOCTL's are pretty raw). Thanks. Looks like GPLPV is the place to start. I already installed the=20 drives into the Windows 7 HVM, and they work a dream. I'll pull the=20 source code and start looking into that. At the moment my development is in the initial stages of learning the=20 Xen infrastructure and how to push things around. I expect to be another= =20 couple of weeks experimenting with ways of doing things before I decide=20 how this should be done. Like for instance setting up a CPU pool with=20 the arinc653 scheduler seems to crash the hypervisor. > >James Simon. --=_wombat.nemo.cl-29681-1382913888-0001-3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Wow,

Thanks James. Much more information here than I expected! This mail= list definitely rocks. My comments in line.

Regards.

Under GPLPV, everything is currently done via mapping a page from Wind= ows into Dom0 (or driver domain). Apart from a few cases at startup I don't= think I map any foreign pages into Windows.

This is my use case. I will set up a static set of pages at start and= they won't change during execution.

The typical design of a xen driver (eg net/disk) is that you have a= shared page for the io ring, an event channel for the front and backend= drivers to deliver events to each other, and then the messages on the io= ring may include grant references to other pages of memory for buffer pass= ing. I think it would be possible to map a foreign page into Windows by = swapping out the pfn of the foreign page with a windows page, or maybe to= map it into the windows io space designated by the pci device used for = interrupt delivery (although that is a limited resource).

The other thing is that pretty much all of this happens in kernel spac= e. Mapping a page of memory from Windows kernel to user space is something= you'd probably try and avoid if possible (read ntdev archives for many,= many opinions on this Mapping a page from= userspace into xen would be better, but then your os would need to handle= mapping the page from windows. I'll ask on the ntdev list about this as= I'm curious now...

This is exactly what I would like to do. That way I avoid Windows= user->kernel transition to access the page. I've just found your mail= on NTDEV. It'll be interesting to see what comes back.

At the moment I envisage= sharing one page as a set of circular buffers and event channels. If I = can run this in user space then perfect, otherwise I will have to write = it as a kernel driver. I've written a couple of Windows drivers (one USB= and one PCI driver) in the past, but userspace is much easier to debug.

GPLPV has some basic xenbus functionality available from userspace = (enough for the shutdownmon app to detect that dom0 has requested a shutdow= n/reboot/whatever), but no functionality for event channel or grant table= calls. Ideally these would be implemented in GPLPV to match the ioctl's= that Linux uses and so the api libraries could be ported across, but that'= s a bit of work and I haven't had a need to do it so far.

I don't know enough about xenbus yet to say anything about= this. It's a steep learning curve. Documentation seems to be 99% oriented to administering Xen= instances, I can find very little about Xen development. Is that the situa= tion or am I missing something?

So... what are you going to do with this shared memory you are mapping= ? Does it need an associated event channel? Will it be a shared io ring = with other mapped pages or will you just be passing tiny messages? If you= are just passing tiny messages, and there isn't any particular performance= requirements, maybe you could use xenbus to write into the xenstore and= pass messages that way. A message every few seconds would be fine. 100 = messages a second via xenbus might be too much.

I am porting a real-time= embedded OS that I originally = developed on a Texas Instruments TMS320C3x DSP on proprietary hardwa= re. This was then ported to MIPS64 (again on proprietary hardware) and now= finally it's running on an ARM9. I have already ported this to a Windows= user space application and run it as a simulator. Of course timing is all= shot and you can't use it to control any real time processes, but it suffi= ces to be able to program on the hoof without real hardware.

The current project will run this simulator on a dedicated proce= ssing core using the arinc653 scheduler (as recommended by Andrew Cooper)= and making it real time again. I will provide two interfaces= to Windows user space applications, one that emulates the current TCP/Seri= al command line interface we already have, and another that will provide= low level hooks into the OS functionality so we can provide tight integrat= ion between Windows applications and the OS.

I will use a shared memory block because I can end up pushing= down tons of data and the access is totally asynchronous and involves no= other processes.

I'm happy to fix any bugs or shortcomings you find in the GPLPV side= of the xenbus code. And I can look at adding event channel and page passin= g (which would allow a complete device implementation in userspace), but= no guarantee I will be able to get anything done quickly. And you'd either= need to handle the IOCTL calls yourself, or port over the various librarie= s from xen (the IOCTL's are pretty raw).

Thanks. Looks like GPLPV is the place to start. I already installed= the drives into the Windows 7 HVM, and they work a dream. I'll pull= the source code and start looking into that.

At the moment my development is in the initial stages of learning the&= nbsp;Xen infrastructure and how to push things around. I expect to be anoth= er couple of weeks experimenting with ways of doing things before I decide= how this should be done. Like for instance setting up a CPU pool with the= arinc653 scheduler seems to crash the hypervisor.

James

Simon.

--=_wombat.nemo.cl-29681-1382913888-0001-3-- --=_wombat.nemo.cl-29681-1382913888-0001-2 Content-Type: image/png Content-Transfer-Encoding: base64 Content-Disposition: inline Content-Id: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAJXSURBVDhPnZBPSJNxGMefQ5d2SDpUdCkIVl26tIiKUsOgWLEO6WHuUAgtoogORVDZ IQwkCLpIvEqZSvjiIZcQSb3OmZvCHCKLoQ7McKi1rXzpH72v2/v0fH9bq4OnBt993+f5fp7vCy8t dBNleoiWe4k+6uTK9pFPpIkMUbzsmH3IwYHHHTOXHsoFbpH+Jbxv1vpw1yzmu2z++tyBY8YeObi1 CtyL+vqhH6kLOc5rzFlRros531NyzLJHDg58pWDuMbnmO0n/ngzklkb8/KZ1h9Ji9BI7y4+U/9kh Bwced6og3U6+xYHdaef9RV4yvJx5fZozRj0vRwLszDcrx4w9cnDgcacKUm2kfZusN4tTp9gcPc6F gsWeoMZm7AwXU+eUY8YeOTjwuFMFUw/JsN757UK8jlfCRxQY1BK8MlzHhcRJ5ZixV7lw4HGnCuL3 KV5INjirsWouqZZXx6Cj/0hm7MsMeNypgmgLGT/HvbY9coinn+5k++1hUTXbozWi2pJjlv10l+TC gcedKjBuk/bp5UHTGjrA/Tc3sH69il+1bKt8eWjw3nbuu7GR+29VMTjwuFMFoavki7ZuTlvDNZwN 7edQ8yaeScYk+/vDPHBni8rBgcedRETPzpOru4n0mSd7clbkBOcHvTyh7eXIg13q7fBEu4c/yx45 OPC4UwUdAaL2RnJ3nl03lOrw5KyxANsTQbYnL4uulFxm7JGDA4+7SoHmJ2prILdIf3Ft6+xc7zHT DDfav8abHDhm7JGDA79WAeQS+USayBDFy44Ze+SKrxTg7//F9Bs8U4bjEi0nagAAAABJRU5ErkJg gg== --=_wombat.nemo.cl-29681-1382913888-0001-2-- --===============1397581866780590034== 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 --===============1397581866780590034==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Durrant Subject: Re: Mapping shared pages from Windows Date: Mon, 28 Oct 2013 09:46:37 +0000 Message-ID: <9AAE0902D5BC7E449B7C8E4E778ABCD01505B2@AMSPEX01CL01.citrite.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-US 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 RGUtaHRtbC1pbmcuLi4NCi0tLQ0KRnJvbTogeGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVuLm9y ZyBbbWFpbHRvOnhlbi1kZXZlbC1ib3VuY2VzQGxpc3RzLnhlbi5vcmddIE9uIEJlaGFsZiBPZiBT aW1vbiBNYXJ0aW4NClNlbnQ6IDI1IE9jdG9iZXIgMjAxMyAyMDozNQ0KVG86IHhlbi1kZXZlbEBs aXN0cy54ZW4ub3JnDQpTdWJqZWN0OiBbWGVuLWRldmVsXSBNYXBwaW5nIHNoYXJlZCBwYWdlcyBm cm9tIFdpbmRvd3MNCg0KSGkgYWxsLA0KwqANCkkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gbXkgbGl0 dGxlIE9TIHBvcnQgYW5kIHRoaW5ncyBzZWVtIHRvIGJlIGdvaW5nIHJlYXNvbmFibHkgT0suIEkg YW0gd3JpdGluZyBpdCBmcm9tIHRoZSBncm91bmQgdXAgdXNpbmcgRGF2aWQgQ2hpc25hbGwncyBi b29rICJUaGUgRGVmaW5pdGl2ZSBHdWlkZSB0byB0aGUgWGVuIEh5cGVydmlzb3IiIGFuZCByZWZl cnJpbmcgdG8gdGhlIG1pbmktb3MgaW1wbGVtZW50YXRpb24uIEkgZmluZCB0aGVyZSBhcmUgdG9v IG1hbnkgZGVwZW5kZW5jaWVzIGFuZCBhZGRpdGlvbmFsIGJpdHMgaW4gdGhlIG1pbmktb3MgY29k ZSB0byBqdXN0IHB1bGwgdGhlIGJpdHMgb3V0IHRoYXQgSSBuZWVkLiBNYXliZSBvbmNlIEkndmUg Z290IGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcgSSdsbCBiZSBhYmxlIHRvIGdvIGJhY2sgYW5kIGRv IHNvbWV0aGluZyB0aGVyZS4NCsKgDQpNeSBuZXh0IGNoYW5uZWwgaXMgdG8gdGFsayB0byBteSBs aXR0bGUgT1MgZnJvbSBhIFdpbmRvd3MgSFZNLiBBcyBhIHN0YXJ0IEkgaGF2ZSBvZmZlcmVkIGEg c2hhcmVkIHBhZ2UgZnJvbSBteSBkb21haW4gd2hpY2ggSSB3YW50IHRvIG1hcCBpbiBhIGxpdHRs ZSBXaW5kb3dzIGFwcC4NCsKgDQpJIGhhdmUgYmVlbiBsb29raW5nIGZvciBhIFdpbmRvd3MgQVBJ IHRvIGFjY2VzcyBYZW4sIGJ1dCBJIGhhdmVuJ3QgZm91bmQgYW55dGhpbmcuIEkgdG9vayBhIHF1 aWNrIGxvb2sgYXQgdGhlIEdQTFBWIGRyaXZlcnMgYnV0IHRoYXQgaXPCoHF1aXRlIGEgbGFyZ2Ug c2V0IG9mIGZpbGVzLiBJcyB0aGVyZSBhbiBlYXNpZXIgc3RhcnRpbmcgcG9pbnQsIGFuZCBtYXli ZSBldmVuIGEgbGl0dGxlIGRvY3VtZW50YXRpb24/DQrCoC0tLQ0KDQpZb3UgY2FuIGxvb2sgYXQg dGhlIFhlblNlcnZlciBQViBkcml2ZXJzIG9uIEdpdEh1Yi4gWGVuYnVzIHdvdWxkIGJlIHRoZSBw bGFjZSB0byBzdGFydCAoaHR0cHM6Ly9naXRodWIuY29tL3BhdWxkdS93aW4teGVuYnVzKSBhbmQg bG9vayBhdCB0aGUgJ3Vwc3RyZWFtJyBicmFuY2guIFRoZXJlIGFyZSBzZXZlcmFsIGhlYWRlciBm aWxlcyBpbiB0aGUgaW5jbHVkZSBzdWJkaXIgdGhlcmUgd2hpY2ggcHJvdmlkZSBrZXJuZWwgQVBJ cyB0byBYZW4gaW50ZXJmYWNlcyBzdWNoIGFzIHN0b3JlLCBldmVudCBjaGFubmVscywgZ3JhbnQg dGFibGUsIGV0Yy4NClRoZXJlIGlzIG9uZSB1c2VyIHNwYWNlIEFQSTogYSBXTUkgcHJvdmlkZXIg Zm9yIHhlbnN0b3JlIGltcGxlbWVudGVkIGJ5IHRoZSB4ZW5pZmFjZSBkcml2ZXIgKGluIHRoZSB3 aW4teGVuaWZhY2UgcmVwbykgYnV0IHRoYXQncyBub3QgZ29pbmcgdG8gYmUgYSBodWdlIGFtb3Vu dCBvZiB1c2UgdG8geW91Lg0KSSBzdXNwZWN0IHdoYXQgeW91J2xsIG5lZWQgdG8gZG8gaXMgYWRk IHN1cHBvcnQgZm9yIGdyYW50IG1hcHBpbmcgaW50byBvbmUgb2YgdGhlIHNldHMgb2YgV2luZG93 cyBQViBkcml2ZXJzLCBwcm9iYWJseSBieSBwbGFjaW5nIGluIHRoZSBwbGF0Zm9ybSBkZXZpY2Un cyBtZW1vcnkgYXBlcnR1cmUsIGFuZCB0aGVuIG1hcHBpbmcgdGhhdCBwYWdlIG91dCB0byB1c2Vy IHNwYWNlLiBZb3UnZCBhbHNvIHByb2JhYmx5IG5lZWQgYW4gaW5kZWZpbml0ZWx5IGJsb2NraW5n IElPQ1RMIG9yIHNvbWV0aGluZyB0aGF0IHRoYXQgd2lsbCB0ZWxsIHlvdSB3aGVuIHRoZSB1c2Vy IHByb2Nlc3MgZGllcyB0aG91Z2gsIG90aGVyd2lzZSB5b3Ugd29uJ3Qga25vdyB3aGVuIHRvIGRv IHRoZSBncmFudCB1bm1hcC4NCg0KICBQYXVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp c3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nate Studer Subject: Re: Mapping shared pages from Windows Date: Wed, 30 Oct 2013 14:39:28 -0400 Message-ID: <52715260.5@dornerworks.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 , "xen-devel@lists.xen.org" , Robert VanVossen List-Id: xen-devel@lists.xenproject.org On 10/27/2013 6:43 PM, Simon Martin wrote: > I am porting a real-time embedded OS that I originally developed on a Texas > Instruments TMS320C3x DSP on proprietary hardware. This was then ported to > MIPS64 (again on proprietary hardware) and now finally it's running on an ARM9. > I have already ported this to a Windows user space application and run it as a > simulator. Of course timing is all shot and you can't use it to control any real > time processes, but it suffices to be able to program on the hoof without real > hardware. Is your simulator going to be running on top of Windows? > > The current project will run this simulator on a dedicated processing core using > the arinc653 scheduler (as recommended by Andrew Cooper) and making it real time > again. The arinc653 scheduler is a fixed periodic timeslice scheduler, which may not be what you want. Can you achieve your goal with just cpu-pinning or cpu-pools and the credit or sedf schedulers? > > At the moment my development is in the initial stages of learning the Xen > infrastructure and how to push things around. I expect to be another couple of > weeks experimenting with ways of doing things before I decide how this should be > done. Like for instance setting up a CPU pool with the arinc653 scheduler seems > to crash the hypervisor. The arinc653 scheduler currently only supports a single physical core and does not really support CPU pools. It would be nice if it detected these conditions and printed an error though, instead of simply crashing... Nate >> >> James > Simon. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nate Studer Subject: Re: Mapping shared pages from Windows Date: Thu, 31 Oct 2013 14:19:09 -0400 Message-ID: <52729F1D.2080505@dornerworks.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 , Robbie VanVossen , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org > At the moment my development is in the initial stages of learning the Xen > infrastructure and how to push things around. I expect to be another couple of > weeks experimenting with ways of doing things before I decide how this should be > done. Like for instance setting up a CPU pool with the arinc653 scheduler seems > to crash the hypervisor. I just tried to repeat your issue and I get a crash in the credit scheduler!? (XEN) Xen BUG at sched_credit.c:917 (XEN) ----[ Xen-4.4-unstable x86_64 debug=y Tainted: C ]---- (XEN) CPU: 0 (XEN) RIP: e008:[] csched_free_vdata+0x9/0x15 (XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor If I create a pool with any scheduler other than arinc653, I do not see this crash, so something is definitely not right. I am pretty sure that this line in the arinc653 scheduler is the culprit. if ( (vc->sched_priv = xmalloc(arinc653_vcpu_t)) == NULL ) >> >> James > Simon. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >