Remapping memory in a HVM DomU from one pfn to another?

Remapping memory in a HVM DomU from one pfn to another?

[James Harper]

In a Windows DomU, I would like to do re-map a page of physical memory
that I have allocated from normal memory to somewhere in PCI memory
space.

I think I need to do the following:

1. Allocate a page of memory from the 'non-paged pool'
2. Get the pfn of the memory I allocated (src pfn), and the pfn of where
I want to remap the memory to (dst pfn)
3. Get the mfn(?) of the memory currently mapped to the src pfn
4. Tell Xen to remap the mfn to the dst pfn

Can this be done? Any tips on the calls I need to make to do it? From a
quick look through the include files it kind of looks like I could use
XENMEM_translate_gpfn_list to get the mfn from the pfn, but I don't know
if that does what I want to do and I don't know where to go from
there... any suggestions?

Thanks

James

Re: Remapping memory in a HVM DomU from one pfn to another?

[Keir Fraser]

On 9/6/08 13:52, "James Harper" <james.harper@bendigoit.com.au> wrote:

> I think I need to do the following:
> 
> 1. Allocate a page of memory from the 'non-paged pool'
> 2. Get the pfn of the memory I allocated (src pfn), and the pfn of where
> I want to remap the memory to (dst pfn)
> 3. Get the mfn(?) of the memory currently mapped to the src pfn
> 4. Tell Xen to remap the mfn to the dst pfn
> 
> Can this be done? Any tips on the calls I need to make to do it? From a
> quick look through the include files it kind of looks like I could use
> XENMEM_translate_gpfn_list to get the mfn from the pfn, but I don't know
> if that does what I want to do and I don't know where to go from
> there... any suggestions?

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.

 -- Keir

RE: Remapping memory in a HVM DomU from one pfn to another?

[James Harper]

> > I think I need to do the following:
> >
> > 1. Allocate a page of memory from the 'non-paged pool'
> > 2. Get the pfn of the memory I allocated (src pfn), and the pfn of
where
> > I want to remap the memory to (dst pfn)
> > 3. Get the mfn(?) of the memory currently mapped to the src pfn
> > 4. Tell Xen to remap the mfn to the dst pfn
> >
> > Can this be done? Any tips on the calls I need to make to do it?
>From a
> > quick look through the include files it kind of looks like I could
use
> > XENMEM_translate_gpfn_list to get the mfn from the pfn, but I don't
know
> > if that does what I want to do and I don't know where to go from
> > there... any suggestions?
> 
> 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.
> 

Almost self-explanatory...

How do I use a 'XEN_GUEST_HANDLE(xen_pfn_t)'? 

Given the structure:

"
struct xen_memory_reservation {
    XEN_GUEST_HANDLE(xen_pfn_t) extent_start;
}
"

Do I say something like:

"
struct xen_memory_reservation xmr;
ULONG pfn;

pfn = get_pfn_from_somewhere();
set_xen_guest_handle(xmr.extent_start, pfn);
"

If I just want to swap one page, then am I right in saying that
nr_extents = 1 and extent_order = 0?

I guess I'll give it a go tonight... the worst it can do is not work :)

Thanks

James

RE: Remapping memory in a HVM DomU from one pfn to another?

[James Harper]

> 
> 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

Re: Remapping memory in a HVM DomU from one pfn to another?

[Keir Fraser]

On 10/6/08 13:02, "James Harper" <james.harper@bendigoit.com.au> wrote:

>> 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?

It does for now. We should be using the existing PV 32-on-64 compat shim for
memory_op() hypercall for HVM 32-on-64 too. As soon as someone does that
work, this hypercall will be available to you. It would already work for HVM
64-on-64 or 32-on-32.

 -- Keir

RE: Remapping memory in a HVM DomU from one pfn to another?

[James Harper]

> It does for now. We should be using the existing PV 32-on-64 compat
shim
> for
> memory_op() hypercall for HVM 32-on-64 too. As soon as someone does
that
> work, this hypercall will be available to you. It would already work
for
> HVM
> 64-on-64 or 32-on-32.
> 

I'll have to look for another way to get the job done then :)

Thanks

James

Re: Remapping memory in a HVM DomU from one pfn to another?

[Ben Guthro]

[-- 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

Re: Remapping memory in a HVM DomU from one pfn to another?

[Keir Fraser]

On 10/6/08 13:32, "James Harper" <james.harper@bendigoit.com.au> wrote:

>> It does for now. We should be using the existing PV 32-on-64 compat
> shim
>> for
>> memory_op() hypercall for HVM 32-on-64 too. As soon as someone does
> that
>> work, this hypercall will be available to you. It would already work
> for
>> HVM
>> 64-on-64 or 32-on-32.
>> 
> 
> I'll have to look for another way to get the job done then :)

Ben Guthro also just replied with the correct conclusion -- for this kind of
operation in 32-on-64 mode you are basically stuffed. There are no
alloc/dealloc/exchange functions exposed to the guest until someone plumbs
in the compat shim code (which already exists! It's just not plumbed into
this path.).

 -- Keir

Re: Remapping memory in a HVM DomU from one pfn to another?

[Keir Fraser]

On 10/6/08 13:02, "James Harper" <james.harper@bendigoit.com.au> wrote:

>> 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?

Good news is this should be supported as of xen-unstable c/s 17855. The bad
news is I'm reluctant to backport for the next 3.2 release as the required
changes to 32-on-64 argument translation are rather subtle. I guess we can
see how things go in xen-unstable and backport in a while if we sufficiently
care.

 -- Keir

RE: Remapping memory in a HVM DomU from one pfn to another?

[James Harper]

> On 10/6/08 13:02, "James Harper" <james.harper@bendigoit.com.au>
wrote:
> 
> >> 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?
> 
> Good news is this should be supported as of xen-unstable c/s 17855.
The
> bad
> news is I'm reluctant to backport for the next 3.2 release as the
required
> changes to 32-on-64 argument translation are rather subtle. I guess we
can
> see how things go in xen-unstable and backport in a while if we
> sufficiently
> care.
> 

I'm interested in the pvscsi stuff in unstable too. What's the timeline
for the next major release (eg 3.3 or whatever is coming after 3.2.x
finishes)?

For me to make use of it in the windows pv drivers it would really have
to be in all conceivable current releases, otherwise I might as well
just continue with my workaround. I know my code breaks on 3.0.x (I
should probably put that in the wiki...), but I'd like to continue to
support anything newer.

Windows is such a pain to code on compared to Linux :(

Thanks

James

Re: Remapping memory in a HVM DomU from one pfn to another?

[Keir Fraser]

On 13/6/08 13:58, "James Harper" <james.harper@bendigoit.com.au> wrote:

> I'm interested in the pvscsi stuff in unstable too. What's the timeline
> for the next major release (eg 3.3 or whatever is coming after 3.2.x
> finishes)?
> 
> For me to make use of it in the windows pv drivers it would really have
> to be in all conceivable current releases, otherwise I might as well
> just continue with my workaround. I know my code breaks on 3.0.x (I
> should probably put that in the wiki...), but I'd like to continue to
> support anything newer.
> 
> Windows is such a pain to code on compared to Linux :(

3.1 branch is done as far as I'm concerned, unless a maintainer steps up.
3.3.0 will likely be early August. 3.2.2 may be a bit before that.

 -- Keir