Bug 215679
Summary: | Can't use PV-on-HVM driver for the previous linux(like as RHEL4 U2 or U4) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Hidetoshi Nishi <nishi.hidetoshi> |
Component: | xenpv-kmod | Assignee: | Don Dutile (Red Hat) <ddutile> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 4.4 | CC: | tao, xen-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-06 17:45:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 246139, 246258, 276501, 296411 |
Description
Hidetoshi Nishi
2006-11-15 04:45:55 UTC
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 release. 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 5.2. This event sent from IssueTracker by gcase issue 107480 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? Thanks, Chris Lalancette Chris,
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.
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. 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 ???. Anyhow... 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 pv_wait_for_completion_timeout()). 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 unmodified_drivers/linux-2.6/compat-include/xen/platform-compat.h and unmodified_drivers/linux-2.6/platform-pci/platform-compat.c 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 issue 107480 Yes, please adjust the BZ & ITs associated with it to read RHEL4.u2,u4 instead of RHEL5 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 to 4.6. Product Management has reviewed and declined this request. You may appeal this decision by reopening this request. |