All of lore.kernel.org
 help / color / mirror / Atom feed
* To use xcs or not?
@ 2005-02-20  8:48 Jacob Gorm Hansen
  2005-02-20 17:04 ` Anthony Liguori
  0 siblings, 1 reply; 7+ messages in thread
From: Jacob Gorm Hansen @ 2005-02-20  8:48 UTC (permalink / raw)
  To: xen-devel

hi,

I am creating a graphics system where each VM draws into an OpenGL 
surface of a process running in dom0. I need to syncronize updates, 
ideally with the vertical blanking of the screen, but in the world of 
stupid PC hardware probably just with some refresh timer that my OpenGL 
process is tied to.

So when the screen has been redrawn, I need to wake up my domUs, and for 
this I wanted to use the ctrl_if mechanism. I borrowed some code from 
vm-shutdown in the (very nice) vm-tools package, setup a semaphore in 
the guest kernel, and for every screen update I send an XCS_REQUEST 
(only type that seems to do anything) up to the domU.

This works fine for a little while (1000 updates or so), whereafter xcs 
seems to go into an infinite loop. I am going to debug this a little, 
but before I dig in too dig I would like to know if this is the right 
solution for my problem. It seems a little worrying (performace wise) 
that all my notifications need to go via another user space process 
before reaching their destination. Would it be better to setup a 
dedicated event channel for this, and would doing so be possible from a 
user space process in dom0 (naturally I can create a special device node 
if I need to)?

Thanks,
Jacob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: To use xcs or not?
  2005-02-20  8:48 To use xcs or not? Jacob Gorm Hansen
@ 2005-02-20 17:04 ` Anthony Liguori
  2005-02-21  3:12   ` Jacob Gorm Hansen
  0 siblings, 1 reply; 7+ messages in thread
From: Anthony Liguori @ 2005-02-20 17:04 UTC (permalink / raw)
  To: Jacob Gorm Hansen; +Cc: xen-devel

Jacob Gorm Hansen wrote:

> I am creating a graphics system where each VM draws into an OpenGL 
> surface of a process running in dom0. I need to syncronize updates, 
> ideally with the vertical blanking of the screen, but in the world of 
> stupid PC hardware probably just with some refresh timer that my 
> OpenGL process is tied to.

Neat, is this some sort of specialized application or are you 
implementing a virtual frame buffer?

> So when the screen has been redrawn, I need to wake up my domUs, and 
> for this I wanted to use the ctrl_if mechanism. I borrowed some code 
> from vm-shutdown in the (very nice) vm-tools package, setup a 
> semaphore in the guest kernel, and for every screen update I send an 
> XCS_REQUEST (only type that seems to do anything) up to the domU.

This is probably a little overkill.  If all you need is notification, 
you probably just want to setup your own evtchn. 

> This works fine for a little while (1000 updates or so), whereafter 
> xcs seems to go into an infinite loop. I am going

xcs has some problems.  It needs some work.

Regards,

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: To use xcs or not?
  2005-02-20 17:04 ` Anthony Liguori
@ 2005-02-21  3:12   ` Jacob Gorm Hansen
  2005-02-21  5:04     ` Anthony Liguori
  0 siblings, 1 reply; 7+ messages in thread
From: Jacob Gorm Hansen @ 2005-02-21  3:12 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: xen-devel

Anthony Liguori wrote:
> Jacob Gorm Hansen wrote:
> 
>> I am creating a graphics system where each VM draws into an OpenGL 
>> surface of a process running in dom0. I need to syncronize updates, 
>> ideally with the vertical blanking of the screen, but in the world of 
>> stupid PC hardware probably just with some refresh timer that my 
>> OpenGL process is tied to.
> 
> 
> Neat, is this some sort of specialized application or are you 
> implementing a virtual frame buffer?

This is a specialized app for a research project, and the way I store 
pixels means I will not be compatible with applications using the kernel 
frame buffer, at least not initially. Hopefully my approach will so much 
better that people will dump X and recode their toolkits to run on my 
stuff though ;-) It will probably be a little while before this is at a 
level where it is usable to anyone else than me, but right now I do have 
some cool demos running.

>> So when the screen has been redrawn, I need to wake up my domUs, and 
>> for this I wanted to use the ctrl_if mechanism. I borrowed some code 
>> from vm-shutdown in the (very nice) vm-tools package, setup a 
>> semaphore in the guest kernel, and for every screen update I send an 
>> XCS_REQUEST (only type that seems to do anything) up to the domU.
> 
> 
> This is probably a little overkill.  If all you need is notification, 
> you probably just want to setup your own evtchn.

OK, I actually got the impression that using XCS was the easiest way 
around the problem, as you seem to need a lot of code for setting up 
your own channel (which I can copy-paste from somewhere I am sure).

Can I setup my own event channel in the guest, and still access it using 
/dev/evtchn in dom0?

Thanks,
Jacob



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: To use xcs or not?
  2005-02-21  3:12   ` Jacob Gorm Hansen
@ 2005-02-21  5:04     ` Anthony Liguori
  2005-02-21  6:23       ` Jacob Gorm Hansen
  0 siblings, 1 reply; 7+ messages in thread
From: Anthony Liguori @ 2005-02-21  5:04 UTC (permalink / raw)
  To: Jacob Gorm Hansen; +Cc: xen-devel

Jacob Gorm Hansen wrote:

> OK, I actually got the impression that using XCS was the easiest way 
> around the problem, as you seem to need a lot of code for setting up 
> your own channel (which I can copy-paste from somewhere I am sure).

For just using notify, it's quite simply.  The control channels are 
complicated because of the ring queue stuff.  If you were implementing 
this as a virtual device in vm-tools (of course, I'm not bias ;-)), all 
you would do is open /dev/evtchn and add that to the set of listener fds 
(see the console device for an example of this).

You would also need to allocate a port for notifications (vmm_alloc_port 
in vm-tools or xc_evtchn_bind_interdomain otherwise).  The easiest thing 
to do would be to use a well known endpoint (anything above 10 should be 
relatively safe for now although you'll probably need to negotiate it in 
the future).

When you get a read event on /dev/evtchn, all you do is read a 2 byte 
value from it.  This will be the port the event happened on.  You'll 
also have to unmask the event by writing that same value back to the device.

> Can I setup my own event channel in the guest, and still access it 
> using /dev/evtchn in dom0?

Yup.

Regards,

> Thanks,
> Jacob
>
>

-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: To use xcs or not?
  2005-02-21  5:04     ` Anthony Liguori
@ 2005-02-21  6:23       ` Jacob Gorm Hansen
  2005-02-21  6:31         ` Anthony Liguori
  0 siblings, 1 reply; 7+ messages in thread
From: Jacob Gorm Hansen @ 2005-02-21  6:23 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: xen-devel

Anthony Liguori wrote:
> Jacob Gorm Hansen wrote:
> 
>> OK, I actually got the impression that using XCS was the easiest way 
>> around the problem, as you seem to need a lot of code for setting up 
>> your own channel (which I can copy-paste from somewhere I am sure).
> 
> 
> For just using notify, it's quite simply.  The control channels are 
> complicated because of the ring queue stuff.  If you were implementing 
> this as a virtual device in vm-tools (of course, I'm not bias ;-)), all 
> you would do is open /dev/evtchn and add that to the set of listener fds 
> (see the console device for an example of this).
> 
> You would also need to allocate a port for notifications (vmm_alloc_port 
> in vm-tools or xc_evtchn_bind_interdomain otherwise).  The easiest thing 
> to do would be to use a well known endpoint (anything above 10 should be 
> relatively safe for now although you'll probably need to negotiate it in 
> the future).
>


Right now, in my domU driver I have:

     gfx_irq = bind_evtchn_to_irq(117);
     printk("got irq %d\n", gfx_irq);

     request_irq(gfx_irq, gfx_interrupt, SA_SAMPLE_RANDOM, "gfx", 0);

/which should get me interrupts when channel 117 gets notified, right?

> When you get a read event on /dev/evtchn, all you do is read a 2 byte 
> value from it.  This will be the port the event happened on.  You'll 
> also have to unmask the event by writing that same value back to the 
> device.
> 
>> Can I setup my own event channel in the guest, and still access it 
>> using /dev/evtchn in dom0?

Hmm from looking at the code in drivers/xen/evtchn/evtchn.c, it seems if 
I write to this device, I can unmask local event channels, but there is 
no notion of a target domain.

If I want to notify eventchannel #117 in, say, domain 5, how can I do 
that from dom0 using /dev/xen/evtchn?

Thanks,
Jacob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: To use xcs or not?
  2005-02-21  6:23       ` Jacob Gorm Hansen
@ 2005-02-21  6:31         ` Anthony Liguori
  2005-02-21  6:42           ` Jacob Gorm Hansen
  0 siblings, 1 reply; 7+ messages in thread
From: Anthony Liguori @ 2005-02-21  6:31 UTC (permalink / raw)
  To: Jacob Gorm Hansen; +Cc: xen-devel

Jacob Gorm Hansen wrote:

> Hmm from looking at the code in drivers/xen/evtchn/evtchn.c, it seems 
> if I write to this device, I can unmask local event channels, but 
> there is no notion of a target domain.

Port's come in pairs.  117 is the remote  port number.  Typically, in 
dom0 you would allocate the port pair (0, 117).  The 0 tells xc to 
allocate an unused local port that's connected to the remote port.

Local ports are always unique so there's no need to be domain specific.

> If I want to notify eventchannel #117 in, say, domain 5, how can I do 
> that from dom0 using /dev/xen/evtchn?
>
> Thanks,
> Jacob
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>


-- 
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: To use xcs or not?
  2005-02-21  6:31         ` Anthony Liguori
@ 2005-02-21  6:42           ` Jacob Gorm Hansen
  0 siblings, 0 replies; 7+ messages in thread
From: Jacob Gorm Hansen @ 2005-02-21  6:42 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: xen-devel

Anthony Liguori wrote:
> Jacob Gorm Hansen wrote:
> 
>> Hmm from looking at the code in drivers/xen/evtchn/evtchn.c, it seems 
>> if I write to this device, I can unmask local event channels, but 
>> there is no notion of a target domain.
> 
> 
> Port's come in pairs.  117 is the remote  port number.  Typically, in 
> dom0 you would allocate the port pair (0, 117).  The 0 tells xc to 
> allocate an unused local port that's connected to the remote port.
> 
> Local ports are always unique so there's no need to be domain specific.

I see. But that means there is no way to _send_ notifications from 
/dev/xen/evtchn? All I can do there is read incoming events?

Jacob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-02-21  6:42 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-20  8:48 To use xcs or not? Jacob Gorm Hansen
2005-02-20 17:04 ` Anthony Liguori
2005-02-21  3:12   ` Jacob Gorm Hansen
2005-02-21  5:04     ` Anthony Liguori
2005-02-21  6:23       ` Jacob Gorm Hansen
2005-02-21  6:31         ` Anthony Liguori
2005-02-21  6:42           ` Jacob Gorm Hansen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.