[Xen-devel] Demultiplexing Network Packets

["Ross C Mcilroy" <mcilrorc@xxxxxxxxxxxxx>]

Hi,

I’m interested in using Xen as part of an experimental platform I’m creating, and would be grateful if someone could answer some questions I have about how packets are demultiplexed between domains sharing a network device.

After reading “Safe Hardware Access with the Xen Virtual Machine Monitor”, I was under the impression that drivers would run in individual “isolated driver domains”, with each domain (including Domain 0) sharing the use of that single driver at a low level, using device channels.  I thought that, for example, network packets would be demultiplexed at a low level by the IDD, then passed up to the correct domain.  The packet would then seem to have arrived from the shared device, as it would have if the device was not being shared (i.e. with the same MAC address as the physical device etc.).

Instead, from reading the user guides, it seems that network devices are shared at a higher level.  It seems that Domain 0 controls the physical device (and driver) and routes network packets (through a virtual bridge) to the virtual devices on the other domains based on the IP header.  The domain the packet is destined for sees the packet as if it came from the virtual device (with a virtual MAC address of the virtual device instead of the actual MAC address of the shared device).  Please correct me if this is totally wrong, but it is the impression I got.

My project calls for packets to be demultiplexed between domains based on the MPLS (MultiProtocol Label Switching) label present on the layer 2.5 shim.  The packet therefore needs to be demultipexed before the IP header is processed.  Ideally, each domain would see what appears to them to be the physical network device, only with much reduced traffic, as only packets destined for that domain would be seen by it.  Similarly with outgoing packets, domains would send packets to the IDD as they would to the physical device (i.e. with the physical device’s MAC address).  The IDD would therefore not have to process these packets, just queue them, and send them based on traffic shaping rules (e.g. the credit based scheduler mentioned in the paper).  Is this possible?  If it’s not possible with the present architecture, would it be possible to add it, in which case what would I need to change?

Thanks for your help,

Ross