Red Hat Bugzilla – Bug 215679
Can't use PV-on-HVM driver for the previous linux(like as RHEL4 U2 or U4)
Last modified: 2010-10-22 02:57:32 EDT
Description of problem:
The user of previous linux(RHEL4 U2 or U4) for guest domain can't use PV-on-
HVM driver. So they can't get the high I/O performance.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Use current VTx or VTi with previous Linux(RHEL4 U2 or U4)
poor I/O performance on VTx and VTi
high I/O performance on VTx and VTi
I'm pretty sure this is meant to be for x86/64, since bug 215672 is exactly the
same but specifically mentions IPF. I'm going to change the architecture here.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Due to capacity issues, this update has slipped to probable release some
time after the release of RHEL5.1. We're investigating the possibility of
delivering it asynchronously so it won't need to wait until the release of
This event sent from IssueTracker by gcase
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time. This request will be
reviewed for a future Red Hat Enterprise Linux release.
- Does RHEL 5.1 resolve the issue reported?
- Have you tested the beta PV HVM drivers for RHEL on a RHEL 5.1 host?
Has Fujitsu now tested the released PV-on-HVM drivers? And are they sufficient
to close out this bug?
Tetsu is out of the office for the rest of the week for a training in CA, but he
sent the following messages to Brian before he left.
> Fujitsu xen team has tested the updated pv-on-hvm driver for RHEL4/ia64,
> and confirmed that the vnif problem is fixed and it can communicate with
> no problem.
what is the issue with fixing this in RHEL 5.2?
What more is needed?
First, the fix(es) would have to go into the xenpv package for rhel4
(xenpv/RHEL-4-kmod), not rhel5. I'm not sure why this bz is tagged to rhel5;
maybe because the guest is running on rhel5 ???.
There are 2 known problems with pre-U5 (maybe pre-U4):
-- kzalloc() & wait_for_completion_timeout() are used in the code, and it
exists in the rhel4 kernel (and exported) in U5 & above, but not in U4 & earlier.
So, in order for a single, rhel4 binary rpm to support U2->U6, it would have to
have its own, private kzalloc() (let's call it pv_kzalloc()) and its own,
private wait_for_completion_timeout() (let's call it
Now, a private kzalloc is fairly trivial, and it's fairly safe to assume it's
functionality wouldn't have to change for its lifetime to match the kernel version.
But, a private wait_for_completion_timeout() is quite a bit more of a stretch,
and if the kernel changed that implementation, then the pv_ version would have
to be changed as well, and if the kernel changed & the xenpv-kmod didn't, in
lock step, there could potentially be problems.
So, for kernel <-> async-driver compatibility, this request is deemed a high
risk. Simple solution is to upgrade to later revs of rhel4 and use the xenpv
package that is compatible with these latter rhel4U[x] updates.
Likewise, if upgrading to later versions of rhel4 is deemed a (customer)
problem, the customer can take the source rpm, and re-enable the ifdef's in
to add the local functions back into the xen-platform-pci.ko module.
Should we adjust this BZ and the ITs associated with it to read RHEL4.x
instead of RHEL5? As you mentioned, this really is a RHEL4 issue.
Internal Status set to 'Waiting on Engineering'
This event sent from IssueTracker by gcase
Yes, please adjust the BZ & ITs associated with it to read RHEL4.u2,u4 instead
Changing to RHEL 4 at customer request, as the driver itself runs on RHEL 4.
At this point there are no plans to support the para-virt drivers for older
minor releases of RHEL than 4.6.
It should be well-known, that Minor Releases are the primary vehicle to enable
new functionality and that we generally do not provide maintenance for older
releases (this will somewhat change with the upcoming EUS offering, but even
there, new features would not be included). The pv-drivers require functionality
provided by 4.6.
So a customer who wants to make use of the paravirt-drivers, they have to move
Product Management has reviewed and declined this request. You may appeal this
decision by reopening this request.