Re: [Xen-devel] "Iomem mapping not permitted" during windows crash dump under GPLPV

[Steven Smith <steven.smith@xxxxxxxxxx>]

> >>> Someone on the ntdev list suggested that one approach could be to
> >>> allocate a single page at setup time and map that into each 'hole' I
> >>> leave behind by ballooning pages out. I haven't checked if Xen supports
> >>> a HVM DomU randomly mapping pages like that and if it will let it map
> >>> the same page multiple times, but it would remove the errors and keep
> >>> everything happy.
> >> 
> >> There is no question - it just has to support this. Linux would not work
> >> without this (nor can I imagine any other OS would).
> >
> >I don't think a page can be simultaneously mapped at multiple locations in a
> >guest's p2m though.
> 
> Aren't we talking about HVM guests here? If the guest maps a page, it
> doesn't know about the p2m. Likewise the balloon driver doesn't care
> about that table (and would install the mapping as James suggested
> instead of the [in the Linux balloon driver] pv-guest-only clearing of
> the respective 1:1 mapping page table entry).
The issue is the Windows crash dump driver, which walks over all of
the physical memory which Windows knows about and tries to write it
out.  There's no way for the PV drivers to tell the crash dump driver
to ignore a particular frame of memory, and so this includes writing
out all the frames which the balloon driver has relinquished.  The
Windows blkfront then ends up sending block requests which reference
ballooned-out memory, which causes an ugly but harmless warning in the
backend.

The obvious fix is for the frontend to just not send those frames, and
to substitute something else in instead, but that means that the
dump-mode block driver needs to be able to get at the list of
ballooned out frames, which is tricky due to architectural issues in
Windows[1].

Alternatively, you could imagine changing the semantics of the balloon
de-populate operation so that it replaces the removed page with, say,
an all-zeroes one, but that then means the P2M is no longer
one-to-one, which is a moderately frightening change just to silence a
warning.  On the other hand, we're kind of moving in that direction
anyway, with the page sharing stuff and the support for mapping grant
references in HVM guests, so it might be necessary anyway.

Finally, we could just tell James to ignore the warning :), which is
probably the right answer.

[1] Windows crash dump support is quite peculiar.  It's essentially
kdump-like, except that the kernel which you kexec appears to have
been written from scratch for the specific purpose of writing out
crash dumps and hibernation files, with a compatibility shim so that
it can run normal Windows drivers.  There's no Microsoft-blessed way
for normal drivers and dump mode drivers to coordinate, and, while
there are a few backdoors, they're rather unpleasant; we ended up
stashing stuff in xenstore.

> The main problem I would see him possibly having is that he might
> need to break up large pages, but otoh I'm not even sure Windows has
> a 1:1 mapping.
It doesn't.

Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel