WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] modifying drivers

To: Ritu kaur <ritu.kaur.us@xxxxxxxxx>
Subject: Re: [Xen-devel] modifying drivers
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Fri, 19 Feb 2010 16:22:12 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Delivery-date: Fri, 19 Feb 2010 16:22:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <29b32d341002191430q4261fd32y8b6834125c0ca04@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <29b32d341002180827v7cd5f219u767f97554fdf4c58@xxxxxxxxxxxxxx> <1266511171.10261.2027.camel@xxxxxxxxxxxxxxxxxxxxxx> <29b32d341002181603v4664b3ebn8b8a89b88f2ab63c@xxxxxxxxxxxxxx> <1266570469.10261.6982.camel@xxxxxxxxxxxxxxxxxxxxxx> <29b32d341002190912n50cf83a5l40dacd2d331fac2e@xxxxxxxxxxxxxx> <1266600267.11737.545.camel@xxxxxxxxxxxxxxxxxxxxxx> <29b32d341002191430q4261fd32y8b6834125c0ca04@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1
On 02/19/2010 02:30 PM, Ritu kaur wrote:
Thanks for the clarification. In our team meeting we decided to drop netback changes to support exclusive access and go with xe command line or xencenter way to do it(We are using Citrix Xenserver). Had couple of follow-up questions related to Xen.

1.Is it correct that netfront driver(or any *front driver) has to be explicitly integrated or compiled in the guest OS? the reason I ask this is,

An HVM domain can be completely unmodified, but it will be using emulated hardware devices with its normal drivers.

a. In the documents I have read, it mentions guest OS can run without any modification, however, if above is true we have to make sure guest OS we use are compiled with the relevant *front drivers.

An HVM domain can use PV drivers to optimise its IO path by bypassing the emulated devices and talking directly to the backends. PV domains always use PV drivers (but they've already been modified).

b. we had done some changes to netback and netfront(as mentioned in the previous email), when compiling kernel for dom0 it includes both netfront and netback and assumed via some mechanism this netfront driver would be integrated/installed into guest domains when they are installed.

No. A dom0 kernel doesn't have much use for frontends. They're usually present because a given kernel can run in either the dom0 or domU roles.

2. Any front or back driver communication is via xenbus only?

Xenbus is used to pass small amounts of control/status/config information between front and backends. Bulk data transfer is usually handled with shared pages containing ring buffers, and event channels for event signalling.

3. Supporting ioctl calls. Our driver has ioctl support to read/write hardware registers and one solution was to use pci passthrough mechanism, however, it binds the NIC to a specific domU and we do not want that. We would like to have multiple users access to hw registers(mainly stats and other stuff) via guest domains and be able to access them simultaneously. For this, we decided to go with the mechanism of shared memory/event channel similar to front and back drivers. Can you please provide some inputs on this?

It's hard to make any suggestions without knowing what your hardware is or what the use-cases are for these ioctls. Are you saying that you want to give multiple domUs direct unrestricted (read only?) access to the same set of registers? What kind of stats? Do guests need to read them at a very high rate, or could they fetch accumulated results at a lower rate?

    J

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