From: Ben Guthro <bguthro@virtualiron.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir.fraser@eu.citrix.com>
Subject: Re: Remapping memory in a HVM DomU from one pfn to another?
Date: Tue, 10 Jun 2008 08:36:16 -0400 [thread overview]
Message-ID: <484E7540.9020707@virtualiron.com> (raw)
In-Reply-To: <AEC6C66638C05B468B556EA548C1A77D013DCDAC@trantor>
[-- Attachment #1.1: Type: text/plain, Size: 1550 bytes --]
I was just looking into this codepath yesterday, for ballooning down a
guest running in compat mode.
My analysis was that this functionality seems to be currently missing in
both 3.2 xen and
xen-unstable(3.3)
The following functions:
do_memory_op_compat32 (3.2)
hvm_memory_op_compat32 (3.3)
seem to be missing the "XENMEM_decrease_reservation" and
"XENMEM_increase_reservation" functionality while running in compat mode.
Similarly, for your codepath - it would appear it is also missing
XENMEM_exchange for you...
This will default to returning ENOSYS to hvm.c, and eventually bubble
our way
up to
linux/drivers/xen/balloon/balloon.c :: decrease_reservation
Where it checks the following after the memory op, and crashes the guest
kernel:
BUG_ON(ret != nr_pages);
So - for now - unless I'm misunderstanding something here...both you & I
appear to be SOL.
James Harper wrote on 06/10/2008 08:02 AM:
>> XENMEM_exchange. Look at 'struct xen_memory_exchange' in
>> xen/include/public/memory.h. Note that GMFN means PFN for an HVM
>>
> guest.
>
>> Hopefully it is all self-explanatory enough.
>>
>>
>
> I tried it and 'xm dmesg' says:
>
> (XEN) hvm.c:747:d11 memory_op 11.
>
> And looking in hvm.c, it appears that this occurs in
> do_memory_op_compat32(...) and the only supported memory_op function is
> XENMEM_add_to_physmap. Does that mean I'm out of luck?
>
> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
[-- Attachment #1.2: Type: text/html, Size: 2282 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2008-06-10 12:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-09 12:52 Remapping memory in a HVM DomU from one pfn to another? James Harper
2008-06-09 13:11 ` Keir Fraser
2008-06-10 7:18 ` James Harper
2008-06-10 12:02 ` James Harper
2008-06-10 12:15 ` Keir Fraser
2008-06-10 12:32 ` James Harper
2008-06-10 12:44 ` Keir Fraser
2008-06-10 12:36 ` Ben Guthro [this message]
2008-06-13 12:53 ` Keir Fraser
2008-06-13 12:58 ` James Harper
2008-06-13 13:05 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=484E7540.9020707@virtualiron.com \
--to=bguthro@virtualiron.com \
--cc=james.harper@bendigoit.com.au \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.