Hey,
Three patches that were discovered with v3.6. The first one:
[PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown
should have been found earlier, but it seems there is only a small selection
of provides run Xen 3.4 and without the 23839:42a45baf037d in xen-unstable.hg fix.
It is easy to reproduce with OVM 2.2 product.
The other two are a bit embarrassing. We had a similar issue with rdmsr_safe
pvops call in v3.5 where it was not implemented for Xen PV (but rdmsr was).
The fix was to make rdmsr_safe a macro around rdmsr and a lookout for other
calls that were not implemented. Well, v3.6 has gone by and now I find three other
culprits:
[PATCH 2/3] xen/bootup: allow {read|write}_cr8 pvops call.
[PATCH 3/3] xen/bootup: allow read_tscp call for Xen PV guests.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Three patches that were discovered with v3.6. The first one:
[PATCH 1/3] xen/pv-on-hvm kexec: add quirk for Xen 3.4 and shutdown
should have been found earlier, but it seems there is only a small selection
of provides run Xen 3.4 and without the 23839:42a45baf037d in xen-unstable.hg fix.
It is easy to reproduce with OVM 2.2 product.
The other two are a bit embarrassing. We had a similar issue with rdmsr_safe
pvops call in v3.5 where it was not implemented for Xen PV (but rdmsr was).
The fix was to make rdmsr_safe a macro around rdmsr and a lookout for other
calls that were not implemented. Well, v3.6 has gone by and now I find three other
culprits:
[PATCH 2/3] xen/bootup: allow {read|write}_cr8 pvops call.
[PATCH 3/3] xen/bootup: allow read_tscp call for Xen PV guests.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel