Xen devel - Jan 2011 - xenstore index reset in xb_init_comms breaks domU kdump

Keir,

in the commit below a reset of the rsp_cons/rsp_prod index was added.
http://xenbits.xen.org/staging/xen-unstable.hg?rev/1ec0d322402e

Is this reset really required for save/restore? I have not tried it, but
I would assume a restored guest would get an empty page to work with.
Also:
Could a guest be saved when its in the middle of a xenstore operation?

The reset breaks the xenstore interface in a crashed domU kernel. If the
crash kernel boots, it tries to operate on the new rsp_* index. But this
contains garbage, process_msg() tries to use the data as ''struct
xsd_sockmsg'', and kmalloc() fails.
If I remove the rsp_cons/rsp_prod reset in xb_init_comms(), the PV
drivers in the crash kernel can connect to xenstore.

Should the fixup code be removed, or is it essential for save/restore?


Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 26/01/2011 14:00, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> Keir,
> 
> in the commit below a reset of the rsp_cons/rsp_prod index was added.
> http://xenbits.xen.org/staging/xen-unstable.hg?rev/1ec0d322402e
> 
> Is this reset really required for save/restore? I have not tried it, but
> I would assume a restored guest would get an empty page to work with.
No, I''m pretty sure it doesn''t get a fresh page on restore.
> Also:
> Could a guest be saved when its in the middle of a xenstore operation?
No, a pv (or pv-on-hvm) guest suspends itself, and can therefore quiesce its
xenstore subsystem.
> The reset breaks the xenstore interface in a crashed domU kernel. If the
> crash kernel boots, it tries to operate on the new rsp_* index. But this
> contains garbage, process_msg() tries to use the data as ''struct
> xsd_sockmsg'', and kmalloc() fails.
> If I remove the rsp_cons/rsp_prod reset in xb_init_comms(), the PV
> drivers in the crash kernel can connect to xenstore.
> 
> Should the fixup code be removed, or is it essential for save/restore?
I think it is needed for save/restore. It may not be needed during boot
though. Your safest (lowest impact) fix would be to skip the reset when
booting a crash kernel. A kernel knows it is a crash kernel, I believe?

 -- Keir
> 
> Olaf
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Jan 26, Keir Fraser wrote:
> I think it is needed for save/restore. It may not be needed during boot
> though. Your safest (lowest impact) fix would be to skip the reset when
> booting a crash kernel. A kernel knows it is a crash kernel, I believe?
There is is is_kdump_kernel(), which relies on an unexported variable.
However, the kdump tool in SLES11 passes ''reset_devices'' in
cmdline. And
this variable is exported and used in a few drivers to do extra hardware
reset. My patch adds a if (!reset_devices) before the assignment.

reset_devices was added in commit
7e96287ddc4f42081e18248b6167041c0908004c and appeared in 2.6.19. Its not
yet part of linux-2.6.18-xen.hg, it should be easy to backport.

I will post my SLES11 SP1 version of the kdump patch shortly.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel