|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Tracking "Cannot allocate memory" error in shadow_alloc_
Tim Deegan wrote:
At 00:13 -0500 on 12 Jan (1168560825), Steven Rostedt wrote:
Why do we need that code, it's using stale data, and updating the shadow
page tables with a m2p mapping that is from a older domain.
The domain builder for translated PV guests still populates the physmap
before enabling shadow-translate mode, so needs this init code. Now
that paravirt-ops kernels use proper mmu operations that can probably be
fixed up.
In the meantime, cset 13326:dc0638bb4628 of xen-unstable should have
stopped it from killing the guest if it finds an entry that's too big.
Is there a way to tell if this is a translated PV guest? I'd rather not
do this code at all if it is not needed. We are mapping pages into a
guess from junk data. I hate to find out later on that something is
missed, and we allow for the guest to have access to memory it should
not have.
-- Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|