Tim Deegan
2011-May-10 12:55 UTC
[Xen-devel] [PATCH] use compat_*() for all 32-bit hypercalls.
The attached patch switches the handling of sched_op, get_xen_version and set_timer_op hypercalls from 32-bit HVM guests to use the compat versions of the handlers. As far as I can see this is correcting an oversight: other hypercalls are already redirected to the compat versions and having a mix of translated and untranslated seems like the worst option. The only one of these three that''s likely to cause trouble is schedop (poll) which almost always happens to work if you call the wrong version. However the interlock against concurrent event arrival doesn''t work, which was leading to lockups in the HVMloader xenbus code. Cc''ing various people who I know are responsible for HVM PV drivers just in case any ofthem have hardcoded this broken interface into client code. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2011-May-10 15:25 UTC
[Xen-devel] [PATCH] use compat_*() for all 32-bit hypercalls.
Is this a problem for 4.1 as well, or are the lockups in HVMloader xenbus in code that''s been introduced since then? -George On Tue, May 10, 2011 at 1:55 PM, Tim Deegan <Tim.Deegan@citrix.com> wrote:> The attached patch switches the handling of sched_op, get_xen_version > and set_timer_op hypercalls from 32-bit HVM guests to use the compat > versions of the handlers. As far as I can see this is correcting an > oversight: other hypercalls are already redirected to the compat > versions and having a mix of translated and untranslated seems like the > worst option. > > The only one of these three that''s likely to cause trouble is schedop > (poll) which almost always happens to work if you call the wrong > version. However the interlock against concurrent event arrival > doesn''t work, which was leading to lockups in the HVMloader xenbus code. > > Cc''ing various people who I know are responsible for HVM PV drivers just > in case any ofthem have hardcoded this broken interface into client > code. > > Cheers, > > Tim. > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Xen Platform Team > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2011-May-10 15:26 UTC
Re: [Xen-devel] [PATCH] use compat_*() for all 32-bit hypercalls.
At 16:25 +0100 on 10 May (1305044704), George Dunlap wrote:> Is this a problem for 4.1 as well, or are the lockups in HVMloader > xenbus in code that''s been introduced since then?This affects all hvmloaders that use xenbus, which I think includes 4.1 Tim.> On Tue, May 10, 2011 at 1:55 PM, Tim Deegan <Tim.Deegan@citrix.com> wrote: > > The attached patch switches the handling of sched_op, get_xen_version > > and set_timer_op hypercalls from 32-bit HVM guests to use the compat > > versions of the handlers. As far as I can see this is correcting an > > oversight: other hypercalls are already redirected to the compat > > versions and having a mix of translated and untranslated seems like the > > worst option. > > > > The only one of these three that''s likely to cause trouble is schedop > > (poll) which almost always happens to work if you call the wrong > > version. However the interlock against concurrent event arrival > > doesn''t work, which was leading to lockups in the HVMloader xenbus code. > > > > Cc''ing various people who I know are responsible for HVM PV drivers just > > in case any ofthem have hardcoded this broken interface into client > > code. > > > > Cheers, > > > > Tim. > > > > -- > > Tim Deegan <Tim.Deegan@citrix.com> > > Principal Software Engineer, Xen Platform Team > > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > >-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Xen Platform Team Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel