Manuel Bouyer <bouyer@antioche.eu.org> writes:

> As for IOCTL_PRIVCMD_MMAP, I'll try to have a look in the next few days.

One problem with my change is that it ties up a page of wired memory
(per use) that doesn't actually get used for anything, because the PTE
is pointing elsewhere.  Aside from wasting RAM, this can also lead to
errors from xend like this:

  Error: Error creating domain: (35, 'Resource temporarily unavailable')
  ERROR: Could not lock memory for Xen hypercall (35 = Resource temporarily unavailable)

But I've found a new way to panic the kernel without that change: get
Xen into that state where domains that have been shut down hang around
in the domain list, like this:

  unreal01           2        0    1  ---s-      4.6    9602
  unreal02           3        0    1  ---s-      4.2    9603

And then restart xend.  (I still haven't been able to reliably
reproduce this on a uniprocessor, unfortunately.)  It looks like it's
the same underlying issue as the problem I thought I fixed with that
patch to xend; in both cases, with my change to IOCTL_PRIVCMD_MMAP,
the panic is replaced by xend dying with:

  xen.lowlevel.xu.PortError: Failed to map domain control interface

At one point I noticed that one of the xpq_update_foreign calls in
pmap_remap_pages was failing when this happens; I'll look into that
some more.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))