RE: [Xen-users] Interrupt distribution

["ITZIAR BALENCIAGA" <ibalenciaga@xxxxxxxx>]

Thanks Fajar for trying to understand me.
I don't really understand very well how the real-time system works but I know that it's now working fine in a single core system and just with Windows as the OS. I'm making a project to try to get better results in a dual core system and I've read about the benefits of virtualization for real-time systems. I've been reading the user's guide of several commercial products and realized that they were the best solution. The problem is that they are expensive and I was asked to do something similar (a simplified version, of course) but with open source. I decided doing it with Xen but it seems it isn't possible making all what the commercial product promises (or at least I can't find the way of doing it). I'll put here the info about the RTS Hypervisor that made me believe this was possible:

RTS Hypervisor is a software agent that partitions hardware resources in such way that multiple OS can be run concurrently and in complete independence of one another and at full speed, without an
intervening software layer to detract from native real-time processing. Users assign computer resources and OSs to the various CPU cores.
The user makes nearly all product settings and customizations in a single, plain-text ASCII file. Here you may specify the number of CPU cores and the amount of memory to be used by a particular OS. The user can also assign legacy-device (non-PCI) interrupts and PCI devices to the exclusive use of specific operating systems. In a running system, in order not to impair an operating system’s realtime characteristics, the Hypervisor neither processes nor redirects any
IRQs. During startup, it programs the system’s Interrupt Controller so that every interrupt is dispatched directly (without intermediate software processing) to its designated CPU core. Each OS  processes its own interrupts.
It's often necessary for applications under one OS to communicate with and possibly coordinate activities with applications running under another OS. To this end, two communication mechanisms have been implemented: Shared Memory and Virtual Network.
Virtual Network moves the data through an area of main memory specifically designated
for that purpose. Since data is transferred through memory, this is a quick method for moving data from an application program under one operating system to another.

After reading it I thought I could make something similar but perhaps it isn't possible with Xen. I've taken the info direct from the user's guide so I hope this time you can understand my goals better.

Regards,

Itziar

-----Mensaje original-----
De: xen-users-bounces@xxxxxxxxxxxxxxxxxxx en nombre de Fajar A. Nugraha
Enviado el: jue 30/04/2009 15:22
Para: Xen List
Asunto: Re: [Xen-users] Interrupt distribution

On Thu, Apr 30, 2009 at 2:43 PM, ITZIAR BALENCIAGA <ibalenciaga@xxxxxxxx> wrote:
>
> I'm sorry if I haven't explained myself well. All these things are new for
> me and probably I haven't done it ok.

Actually what I meant was you should consider using inline replies,
like what I did for your email. It makes reading easier, thus it will
make it easier for others to understand what you mean.

If you deliberately make it hard for others to understand your email
(like top-posting, or including entire email digest, or simply remove
ALL the previous emails during replying) then it's unlikely that
anybode will even try to help you, since they have no idea what you
mean.

> You are right when you think about a real-time system with Xen. I have a
> dual core and up to now I have installed Xen to have a dom0 with Linux and a
> domU with Windows. I've set CPU affinity so that each OS has his own core.
> My idea is putting the real-time part in the linux part and the interface in
> Windows. The real-time part works like this: an interrupt is generated and
> send every x ms. It interrupts the system and some values are taken. Then
> the interface uses this vale to make several operations. What I want is that
> when anything happens the windows part to handle it. That is, that nothing
> disturbs the real-time part in order to maintain the necessary performance.

First of all virtualized system (like Xen) might not be the best
candidate for real-time or time-sensitive operations (like VOIP, for
example). While some people DO use VOIP server under Xen, the
virtualization layers (for CPU, network, and disk) will introduce more
overhead and more latency which (depending or your needs) might or
might not be tolerable.

Second of all, what you're saying doesn't make any sense to me. Seriously.
You're saying that when an interrupt happens (possibly because of some
input from some I/O device) you want the dom0 to take some values
(read the I/O device?), and then PASS the values to another domian
(which, in this perspective, is essentially another machine), and THEN
have the other OS process it? Doesn't look like a good real-time
system to me. The process of passing values between different machines
(what do you have in mind? TCP-IP?) by itself could introduce delay
and latency which might be unsuitable for real-time system.

> In a simple way what I want is something like telling the interrupts where
> they have to go to be handled, if they have to go to core 0 or 1.

Things like irqbalance can be used to move interrupts between
processors on the same kernel. It has no idea about other operating
system/kernels running in the same virtualized system.

I suggest you rethink your setup, or (If I incorrectly understand your
explanation) put a clearer description of what you want. Who knows,
perhaps all you need is simply to let domU (Windows) have a direct
access to the interrupt-generator device, which might be possible
using PCI or USB passthrough.

Regards,

Fajar

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users