to alternative names and that only gets compiled when 64-bit
arches need it for supporting 32-bit binaries.
My rewritten libxc domain builder takes a simliar approach ...
cheers,
Gerd
--
Gerd Hoffmann [EMAIL PROTECTED]
http://www.suse.de/~kraxel/julika-dora.jpeg
be xc_domain_memory_increase_reservation() or
xc_domain_memory_populate_physmap() ...
cheers,
Gerd
--
Gerd Hoffmann [EMAIL PROTECTED]
http://www.suse.de/~kraxel/julika-dora.jpeg
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen
Keir Fraser wrote:
On 20/10/06 09:01, Gerd Hoffmann [EMAIL PROTECTED] wrote:
domain builder. I could leave the interface just for that I suppose, but
equally we could fill in the initial P2M table when we allocate the domain's
initial memory reservation (since that hypercall returns
Hollis Blanchard wrote:
On Mon, 2006-12-04 at 11:58 +0100, Gerd Hoffmann wrote:
plain text document attachment (xen-generate-foreign-headers.diff)
This patch adds a script to generate headers with arch-specific
structs which can be included on any architecture. Can be used
to deal
it as-is
for now. It certaily can be added, feel free to send patches ;)
Hmm, that's ambitious. What exactly is your use case? If it's 32-on-64,
no endianness code is required, right?
That is the only one for now, yes, and it works fine without
byteswapping ...
cheers,
Gerd
--
Gerd
,
Gerd
--
Gerd Hoffmann [EMAIL PROTECTED]
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
pfn-mfn translation is needed was a bit
more complex than just looking up shadow_enabled.
HTH,
Gerd
--
Gerd Hoffmann [EMAIL PROTECTED]
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
