RE: [Xen-devel] Questions about device/event channels in Xen.

["Liang Yang" <multisyncfe991@xxxxxxxxxxx>]

Hi Mark,

Thanks for your clarification. It is clear now. But I still have several
questions.

First: it seems Xen uses at least two different types of even "channels".
First type is for interrupt notification (upper call or uni-directional) and
the second if for the notification of queued descriptors (bi-directional).
So is the type of event channel fixed when Xen allocate them or not fixed
(for the same device), e.g. event channel 2 was a uni-directional type and
later can be changed to bi-directional type.

Second: as these events are handled asynchronously, does Xen treat different
type of event differently?  For example, does Xen always respond to
interrupt event immediately (unlike queuing more descriptors and then set up
event)?

Third: for a PCIe device, I can choose to use MSI or the legacy line-based
interrupt. Does different type of interrupt handling mechanism affect the
event channel set-up?

Liang

 
-----Original Message-----
From: M.A. Williamson [mailto:maw48@xxxxxxxxxxxxxxxx] On Behalf Of Mark
Williamson
Sent: Thursday, March 15, 2007 5:34 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Cc: Liang Yang; Petersson, Mats
Subject: Re: [Xen-devel] Questions about device/event channels in Xen.

The terminology may be confusing you here, so let me just say: Device
channels 
are not like Event channels.  They're different concepts...  let me 
elaborate:

> I just have several questions about device and event channel:
> 1. From the implementation point of view, are device and event channel the
> same (i.e. both based on shared memory)?

Event channels don't use interdomain shared memory.  They're like an 
interdomain interrupt line, provided as a service by Xen.  Basically a way 
for a pair of domains to "poke" each other to say "Something just happened 
and there's work for you to do".

The "device channel" uses interdomain shared memory (using grant tables) and

event channels to emulate the functionality of a device.  For instance, the 
blkfront and blkback drivers do something like the following:

1. blkfront wants to access a block of data
   -> queue a "read request" into memory it shares with blkback
   -> notify blkback in dom0 using an event channel
2. blkback experiences an "interrupt" as a result of the event sent to it
   -> looks in the shared memory to find the request
   -> executes the read operation
   -> puts a response in shared memory
   -> notifies blkfront in the domU using an event channel
3. blkfront experiences an "interrupt" due to the event sent to it
   -> completes processing of the new data

The combination of the shared memory (containing a ring buffer for requests 
and responses) and the event channel provides the facilities for the front 
and back drivers to talk to each other; this is the device channel.

> 2. In Xen papers, it is said up to 1024 channels are supported per domain.
> Does 1024 include both device channel and event channel?

This should be answered by the text above; device channels are a different 
thing, built using event channels.

> 3. Are these device/event channels allocated dynamically or statically for
> each domain?

XenLinux virtual device drivers bind event channels dynamically when they
set 
up their communications with another domain.

I think there are some statically allocated event channels for essential 
services (e.g. for XenStore and the domain's console).

> 4. It seems I need to allocate one device channel per device, is this
true?

Yes, but the device channel is something you build yourself using shared 
memory and event channels - it's up to you how you implement it.

In summary: event channels and shared memory are concrete services provided
by 
Xen using an API.  A "device channel" is a high level term for the way 
drivers use these facilities to communicate.

I hope this helps, please ask if you need any clarification.

Cheers,
Mark


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