[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PV drivers for HVM guests

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 

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:

        elevator_init(rq, "noop");
        elevator_init(rq, &elevator_noop);


                                req, (bret->status == BLKIF_RSP_OKAY));

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 Ofsthun - Virtual Iron Software, Inc.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.