Re: [Xen-devel] [xen-unstable test] 13539: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.08.12 at 10:00, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2012-08-03 at 08:59 +0100, Jan Beulich wrote:
>> >>> On 03.08.12 at 09:48, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> > On Fri, 2012-08-03 at 06:12 +0100, Ian Campbell wrote:
>> >> On Fri, 2012-08-03 at 00:41 +0100, xen.org wrote:
>> >> > flight 13539 xen-unstable real [real]
>> >> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13539/ 
>> >> > 
>> >> > Regressions :-(
>> >> > 
>> >> > Tests which did not succeed and are blocking,
>> >> > including tests which could not be run:
>> >> >  build-i386-oldkern            4 xen-build                 fail REGR. 
>> >> > vs. 
>> > 13536
>> >> >  build-i386                    4 xen-build                 fail REGR. 
>> >> > vs. 
>> > 13536
>> > 
>> > 8<----------------------------------
>> > 
>> > # HG changeset patch
>> > # User Ian Campbell <ian.campbell@xxxxxxxxxx>
>> > # Date 1343980045 -3600
>> > # Node ID 23fdca3adb3346090ea8b65b77cad7d279cf9daf
>> > # Parent  95a4ab632ac25ce0ec6a245dcc46ad57d3c7030f
>> > nestedhvm: fix nested page fault build error on 32-bit
>> > 
>> >     cc1: warnings being treated as errors
>> >     hvm.c: In function âhvm_hap_nested_page_faultâ:
>> >     hvm.c:1282: error: passing argument 2 of 
>> > ânestedhvm_hap_nested_page_faultâ from incompatible pointer type 
>> > 
> /local/scratch/ianc/devel/xen-unstable.hg/xen/include/asm/hvm/nestedhvm.h:55: 
> 
>> > note: expected âpaddr_t *â but argument is of type âlong unsigned int *â
>> > 
>> > hvm_hap_nested_page_fault takes an unsigned long gpa and passes &gpa
>> > to nestedhvm_hap_nested_page_fault which takes a paddr_t *. Since both
>> > of the callers of hvm_hap_nested_page_fault (svm_do_nested_pgfault and
>> > ept_handle_violation) actually have the gpa which they pass to
>> > hvm_hap_nested_page_fault as a paddr_t I think it makes sense to
>> > change the argument to hvm_hap_nested_page_fault.
>> 
>> And that's even outside of the current build failure - it just
>> can't have worked for >4Gb guests on the 32-bit hypervisor.
> 
> Right. I must admit I was surprised to find that nestedhvm was a feature
> of 32 bit at all, I had expect the fix to be changing some sort of stub
> function...

So did I first think. But the function that needed changing really
isn't nested-HVM only, so the fix was required in any case (just
that without the exposing c/s, the problem would likely have been
found a lot later).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel