Re: Xen 3.3: Problem HVM guest

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Aug 14, 2008 at 01:59:35PM +0200, Christoph Egger wrote:
> > Did you try ktracing the process when is starts looping ?
> 
>    400      8 python2.4 CALL  mlock(0x7f7ff73fb000,0x1000)
>    400      8 python2.4 RET   mlock 0
>    400      8 python2.4 CALL  ioctl(8,_IOWR('P',0,0x38),0x7f7ff73fb760)
>    400      8 python2.4 GIO   fd 8 wrote 56 bytes
>        "\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\240\M-7?\M-w\^?\^?\0\0\M^?
> \M-g\^C\0\0\0\0\0\^A\0\0\
>         \0\0\0\0\0001S\240\M-{\^?\^?\0\0\^A\0\0\0\^A\0\0\0"
>    400      8 python2.4 GIO   fd 8 read 56 bytes
>        "\"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\240\M-7?\M-w\^?\^?\0\0\M^?
> \M-g\^C\0\0\0\0\0\^A\0\0\
>         \0\0\0\0\0001S\240\M-{\^?\^?\0\0\0\0\0\0\0\0\0\0"
>    400      8 python2.4 RET   ioctl 0
>    400      8 python2.4 CALL  munlock(0x7f7ff73fb000,0x1000)
>    400      8 python2.4 RET   munlock 0
>    400      8 python2.4 CALL  mmap(0,0x1000,3,0x1001,0xffffffff,0,0)
>    400      8 python2.4 RET   mmap 140187698843648/0x7f7ffdfdd000
>    400      8 python2.4 CALL  ioctl(8,_IOW('P',0x2,0x10),0x7f7ff73fb790)
>    400      8 python2.4 GIO   fd 8 wrote 16 bytes
>        "\^A\0\0\0\^A\0\0\0p\M-7?\M-w\^?\^?\0\0"
>    400      8 python2.4 RET   ioctl 0
>    400      3 python2.4 RET   select 0
>    400      3 python2.4 CALL  _lwp_park(0,0,0x7f7ffd104e80,0x7f7ffd104e80)
> 
> > I guess it's looping on page fault. To check for what's going on I would:
> > - check that privcmd_map_obj() gets the protection right for this address
> >   (it should be VM_PROT_READ | VM_PROT_WRITE, as we're remapping a range
> >    which was mmapped read/write)
> 
> Yes, protection is VM_PROT_READ | VM_PROT_WRITE.

Looks good

> 
> > - instrument privpgop_fault() to see if it gets called at all for this
> >   mapping, and if it's doing the right thing.
> >   There should be only one page in this object, and the machine address
> >   should be 0 (pobj->maddr[maddr_i])
> 
> Yes, privpgop_fault() is called. It looks like it's called in a loop.
> npages = 1 and machine address is 0.

OK, it has the right data. I guess it's called in a loop because writing at
the page keeps failing.

> 
> > - if privpgop_fault() behaves properly, check that the xpq_update_foreign()
> >    call in pmap_enter_ma() works as intended.
> 
> It is not failing at least.

Could you check the value of the pte (*ptep) after the call to
xpq_update_foreign() ?
Also, I guess we should be watching the value of 'ok' in
xpq_update_foreign(), which we're not doing right now ...

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--