Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 494876

Summary: [RHEL5.4]: Explicitly zero CR[1] in getvcpucontext
Product: Red Hat Enterprise Linux 5 Reporter: Chris Lalancette <clalance>
Component: kernel-xenAssignee: Miroslav Rezanina <mrezanin>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: dzickus, mjenner, syeghiay, xen-maint
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 09:00:27 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: 492570    

Description Chris Lalancette 2009-04-08 14:07:57 UTC
Description of problem:
There was recently a patch posted to xen-devel to explicitly zero out the CR[1] memory in the hypervisor:

http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00183.html

Supposedly, this affects recent SUSE guests and recent PV-OPS guests, but after a quick look at the code, I can't seem to see how this will make a difference.  As far as I can tell, neither the SLES11 kernel nor the kernel.org PV-OPS kernel uses the CR[1] memory region.  That being said, it's certainly possible I'm missing something, so we should find out for sure, and backport xen-unstable c/s 19505 if necessary.

Comment 1 Chris Lalancette 2009-04-19 12:47:52 UTC
Assigned for triage.  Miroslav, we have to figure out whether this is actually needed or not.  At a quick glance, I couldn't figure it out.  If we don't need it, I'd want to know why we don't need it while upstream does, especially since supporting pv-ops guests is a high priority for us going forward.

Chris Lalancette

Comment 2 Miroslav Rezanina 2009-04-21 09:56:09 UTC
I'd recommended copy this patch as it guarantees that guest won't received undefined value that can cause guest to behave unstable. If we want to be sure that each calling getvcpucontext hypercall returns concrete value.

Comment 3 Chris Lalancette 2009-04-23 09:19:33 UTC
Miroslav,
     OK, a couple of things.  First, the patch that actually was committed into the upstream tree is slightly different than the one posted to the mailing list.  This happens often in the Xen world, you'll get used to it :).  That being said, we like to stay as close as possible to what is in the upstream; it makes future porting work easier.
     The second thing is that I still don't understand how or why this patch is needed.  Maybe I'm just missing something, but doing a "grep -rI ctrlreg *" in the pv-ops source tree, I *only* see ctrlreg[3] being used, not ctrlreg[1].  Now, it's entirely possible that I'm missing something, and it's copied around as part of a larger data structure.  But before committing the patch to the tree, I would like to understand better where and how this is used.  Maybe you can point out what I'm missing to make this patch useful.  Or, if need be, we can always email Ian Campbell (the original patch author) to see why exactly he posted the patch in the first place.

Chris Lalancette

Comment 5 Chris Lalancette 2009-05-07 12:26:05 UTC
*** Bug 499598 has been marked as a duplicate of this bug. ***

Comment 7 Don Zickus 2009-05-12 17:41:23 UTC
in kernel-2.6.18-146.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.

Comment 10 errata-xmlrpc 2009-09-02 09:00:27 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html