All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.