Re: Regressions in v3.3-rc1 introduced by "xen/granttable: Granttables V2 implementation"

From: Konrad Rzeszutek Wilk
Date: Wed Jan 25 2012 - 15:49:40 EST


On Wed, Jan 25, 2012 at 09:55:33AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> >
> > .. snip..
> > >
> > > and with this little patch I can get it to work:
> >
> > I get the domU to boot but the network stops being responsive.
> > I see this in the Dom0:
>
> Your original patch would set the version to two in the hypervisor and
> then ignore that and continue to use v1 so that isn't surprising.
>
> > (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> > [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> > [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> >
> > Replacing the patch with:
> >
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index 1cd94da..b4d4eac 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
> > int rc;
> > struct gnttab_set_version gsv;
> >
> > - gsv.version = 2;
> > + if (xen_hvm_domain())
> > + gsv.version = 1;
> > + else
> > + gsv.version = 2;
> > rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> > - if (rc == 0) {
> > + if (rc == 0 && gsv.version == 2) {
> > grant_table_version = 2;
> > gnttab_interface = &gnttab_v2_ops;
> > } else if (grant_table_version == 2) {
> >
> > Gets me back to how it worked in Linux v3.2.
> >
> > But that is just a band-aid fix...
>
> The real bug is presumably either that the Linux v2 code is buggy for
> use in an HVM guest or that Xen's support for v2 in HVM guests is either
> buggy or explicitly disabled (in which case set_version should fail for
> version=2).
>
> Is the set_version with version=1 succeeding or failing? Likewise for
> the version=2 call?

Both return 0. But version=2 returns the error in the hypervisor:

(XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)

>
> The original error was an "unable to handle kernel NULL pointer
> dereference at" gnttab_end_foreign_access_ref_v2+0x29/0x40. The only
> plausible candidates for such an error are the array access into to
> either the gnttab_shared or grstatus arrays. Do you know which one the
> IP corresponds to?

Didn't look deeper into this than just enought to send this hastily crafted
email. Will check shortly.
>
> On HVM for gnttab_shared we make an add_to_physmap call with
> XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> do something similar for the status array though and I don't see a
> XENMAPSPACE_* specifically for that case either in the hypervisor
> either.
>
> Ian.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/