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] PV drivers for HVM guests

To: Ky Srinivasan <ksrinivasan@xxxxxxxxxx>
Subject: Re: [Xen-devel] PV drivers for HVM guests
From: Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>
Date: Tue, 03 Oct 2006 18:31:06 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 03 Oct 2006 15:31:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45229025.E57C.0030.0@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45229025.E57C.0030.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Ky Srinivasan wrote:
I am trying to build PV drivers for SLES9 HVM guests. SLES 9 is based on the 
2.6.5 kernel. Since the PV driver code is really designed for the latest kernel 
release, I have had many issues/problems in building the PV drivers for older 
Linux OS targets - I have only been looking at the issues with 2.6.5 kernel 
base and I suspect the problem will be even worse if one were to look at older 
Linux kernels. This is unfortunate since PV drivers are so critical for HVM 
guests and there is considerable interest in supporting legacy Linux 
environments as HVM guests. The problems I have had to deal with can be broadly 
classified into:

a) Compiler related issues
b) Missing functionality in the legacy kernel - this includes features as well 
as changed data structures
c) Implementation differences of a given feature

These differences can be dealt with in a couple of different ways:
1) Modify the code in the PV drivers under appropriate compilation switches to 
deal with the differences in the base kernels.
2)  Introduce  a compatibility component that bridges the gap between the 
current PV code and a given Linux target and leave much of the PV driver  code 
untouched.

I have implemented both these schemes for the sles9 kernel and would like to 
get your input on your preference. I personally like option 2. Going forward, 
the evolution of PV drivers needs to be constrained by the required support for 
legacy Linux environments.

We have generally taken approach 1, for supporting SLES9 32/64 & RHEL4 32/64, with others under development. While the code is uglier, it is also more obvious to a maintainer when they run across something like the following:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,10)
        elevator_init(rq, "noop");
#else
        elevator_init(rq, &elevator_noop);
#endif

or

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,15)
                        end_that_request_last(
                                req, (bret->status == BLKIF_RSP_OKAY));
#else
                        end_that_request_last(req);
#endif

In this way, the sensitive areas of the code are obvious. As the PV drivers move forward, new kernel interface changes require similar changes. As you mention, which ever method is used, some level of discipline is required in maintaining the PV drivers.

With your suggested option 2, does this require separate "compatibility component" code for each supported kernel version? Or do you envision a single compatibility layer that would hide the conditionally compiled code from the PV drivers proper?

There is also the issue of whether the PV drivers can/should support multiple hypervisor versions moving forward.

Steve
--
Steve Ofsthun - Virtual Iron Software, Inc.

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