Re: [Xen-devel] Xen crash: map_domain_page() on an NMI path

[Kai Huang <dev.kai.huang@xxxxxxxxx>]

On Fri, Dec 20, 2013 at 4:43 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 19.12.13 at 17:19, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> However, for hardware pieces like this which are set up once at the
> start of day, and have the hardware pointed at a chosen region, would it
> be acceptable to allocate their frames low enough to be covered by the
> direct map area (protected by BUG()s?) and set up their base virtual
> addresses knowing that there will always be a valid mapping from any Xen
> pagetables?  This seems better than constantly playing around with the
> mappings.

That would still require further special casing in map_domain_page().

In the case here, and with 32-bit no longer a concern, a virtual
mapping should rather be obtained at boot time once and for all
using vmap().

A question about map_domain_page. If I understand correctly, currently map_domain_page will still do page table setup with virtual address in mapcache area. Why can't we just map all physical memory to XEN's  virtual address slot, and do mfn_to_virt to get the virtual address?

-Kai

> For the 'crashing' context, I was thinking of extending enum
> system_state to include "panic" and "crash_single" states, where
> crash_single implies "safe to not actually lock a spinlock"  Integrating
> this without an adverse effect on spinlock performance might be a little
> tricky however.

It's not just performance - depending what a particular lock
protects, just ignoring the need to take the lock may end up
using inconsistent state.

Jan

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

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