Bug 494876 - [RHEL5.4]: Explicitly zero CR[1] in getvcpucontext
[RHEL5.4]: Explicitly zero CR[1] in getvcpucontext
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Miroslav Rezanina
Red Hat Kernel QE team
: 499598 (view as bug list)
Depends On:
Blocks: 492570
  Show dependency treegraph
Reported: 2009-04-08 10:07 EDT by Chris Lalancette
Modified: 2009-09-02 05:00 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 05:00:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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


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 08:47:52 EDT
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 05:56:09 EDT
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 05:19:33 EDT
     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 08:26:05 EDT
*** Bug 499598 has been marked as a duplicate of this bug. ***
Comment 7 Don Zickus 2009-05-12 13:41:23 EDT
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 05:00:27 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.