|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] Paging and memory sharing for HVM guests
>>> Patrick Colp <pjcolp@xxxxxxxxx> 17.12.09 18:05 >>>
>Jan Beulich wrote:
>>>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 17.12.09 17:38 >>>
>>> 1). The "*mfnp |= 0x80000000U;" and "*mfnp |= 0xf0000000U;" should
>>> use a #define. Maybe copy over the #defines from the xen tree ?
>>
>> Did you find any defines in the tools sources for that? The only place I
>> found this condition being checked at all was in xc_map_foreign_pages(),
>> where it used hard-coded values. Or are you referring to the
>> XEN_DOMCTL_PFINFO_* values? I'd say they're being mis-used when
>> applied to the mfn array used by mmap-batch (including apparent
>> pre-existing uses).
>
>I think many people agree that this idea of using 0xf0000000 is a very
>inelegant solution (myself included). Maybe now would be a good time to
>hash out what the proper way to deal with this is. I think this discussion
>should extend to the privcmd/libxc mmap interfaces generally as well.
Yes, I fully agree. While I had cooked together a patch to make the
tools auto-detect whether the underlying (64-bit) kernel uses a
sufficiently wide mask as error indicator (and a Linux side patch to
actually make the kernel behaviorally match the pseudo-documentation
in privcmd.h ("array of mfns - top nibble set on err"), I meanwhile
realized that this would break older tools running on a fixed kernel
(a combination I suppose to be valid).
The only way I can see to solve this is a new ioctl, and if we need a
new ioctl anyway, we can as well design it properly. The question
however is what the best way for an error indication is: Fully over-
writing the passed in MFNs, an extra bit vector passed in (does user
mode have a sufficiently common interface for dealing with bit fields,
like the kernel's bitops.h?), or yet something else?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|