RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer_write)

[Dexuan Cui <decui@microsoft.com>]

> -----Original Message-----
> From: Sitsofe Wheeler
> On Tue, Aug 26, 2014 at 10:30:54AM +0000, Dexuan Cui wrote:
> 
> > Actually I found the direct cause of the panic: sometimes
> > vmbus_post_msg() can return 4 (HV_STATUS_INVALID_ALIGNMENT), but
> > vmbus_open() doesn't propagate this error to the caller
> > synthvid_connect_vsp(), and vmbus_open() " goto error1"  and frees the
> > ringbuffer! So later the access to ring_buffer->read_index is caught
> > by CONFIG_DEBUG_PAGEALLOC.
> >
> > I don't see any "invalid alignment" here... and I can't explain why
> > vcpus=4 seems OK... Debugging WIP.
I think I found out why we got HV_STATUS_INVALID_ALIGNMENT:
according to Hypervisor Top Level Functional Specification(available at
http://blogs.msdn.com/b/virtual_pc_guy/archive/2014/02/17/updated-hypervisor-top-level-functional-specification.aspx),
do_hypercall() fails due to HV_STATUS_INVALID_ALIGNMENT, if "the
specified input or output GPA pointer is not aligned to 8 bytes",
or, "the specified input or output parameter lists spans pages".
Here the 'input' can rarely across the page boundary, especially when 
CONFIG_DEBUG_PAGEALLOC is on.

I'm making a patch for this. 

> >
> > BTW, please try the attached patch.  With it, the VM doesn't panic in
> > my side with vcpus=1 and can boot to shell prompt(looks the boot-up is
> > very slow. I have to wait for several minutes...)
> 
> A quick tip: inline patches tend to be better than attachments on LKML.
> This is because if the mimetype of the attachment is something like
> octet/stream then various tools (e.g.
> https://lkml.org/lkml/2014/8/26/271 and
> https://patchwork.kernel.org/project/LKML/list/?submitter=100981 ) won't
> archive/extract the patch...
OK, thanks for the reminder! 
I'll use inline patches(I hope my mail client has been configured to be smart
enough to not "auto-format" my inline patches...).

> I rebased your patch on top of the K.Y.'s "Drivers: hv: vmbus: Eliminate
> calls to BUG_ON()" patch set (see below). The combination no longer
> triggers the bug and it doesn't take too long to boot but the network
> interface fails to work (which I believe is .
the sentence is accidently trimmed here? :-)

> 
> Rebased vmbus open fixes patch.
The patch doesn't resolve all the issues.

> Boot dmesg output (there's no line that mentions retries). The
> framebuffer window also didn't resize itself:
> 
> [    7.848030] hv_vmbus: registering driver hyperv_fb
> [    7.859759] hyperv_fb: Unable to open vmbus channel
> [    7.871812] hyperv_fb: Unable to connect to VSP
We still see hyperv_fb can't work.

Thanks,
-- Dexuan