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

[Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>]

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