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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-08-03 at 09:39 +0100, Tim Deegan wrote:
> At 09:37 +0100 on 03 Aug (1343986678), Ian Campbell wrote:
> > On Fri, 2012-08-03 at 09:34 +0100, Tim Deegan wrote:
> > > At 08:48 +0100 on 03 Aug (1343983712), Ian Campbell wrote:
> > > > 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.
> > > > 
> > > > The other user of gpa in hvm_hap_nested_page_fault is a call to
> > > > p2m_mem_access_check, which currently also takes a paddr_t gpa but I
> > > > think a paddr_t is appropriate there too.
> > > > 
> > > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > 
> > > Acked-by: Tim Deegan <tim@xxxxxxx>
> > 
> > Is one of you or Jan going to apply or shall I? (I'm doing a tools
> > commit sweep right now)
> 
> If you're already applying things, please do apply up this one too.

Done.

I added an extra sentence to the commit log:
        Jan points out that this is also an issue for >4GB guests on the
        32 
        bit hypervisor.

> 
> Tim.



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