Re: [Xen-devel] Tagging Xen 4.0.0 first release candidate

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 05.01.10 07:42 >>>
>I plan to tag -rc1 later this week. If you have any outstanding patches,
>please send them to the list now.

While I have a kernel side draft patch implementing a replacement
privcmd mmap with proper error indication batch close to ready, I
don't have the libxc and qemu ones even started, yet. To fully
finish up the kernel side I wanted to wait for your and possibly
other's opinions on the lifted single shot mapping I suggested
earlier today.

Plus the way errors are to be propagated may be controversial: Other
than originally planned, after the paging patches went in, using a
simple bit field won't do anymore, as we now need at least two bits
for indicating all possible states. Right now I'm simply using an array
of int-s (returning the actual error codes):

typedef struct privcmd_mmap_batch {
        unsigned int num; /* number of pages to populate */
        domid_t dom;      /* target domain */
        __u64 addr;       /* virtual address */
        const xen_pfn_t __user *arr; /* array of mfns */
        int __user *err;  /* array of error codes */
} privcmd_mmap_batch_t;

but that could be considered overkill. A non-extensible alternative
would be two bit fields (one for error indications, the other for
paged-out ones), and another possibility would be to at least
use __s16 instead of int for the array to reduce the virtual address
space needed. A third possibility, helping in those cases where the
caller doesn't need the MFN array for other than passing to the ioctl,
could be to explicitly allow the two pointers to hold the same
address (i.e. documenting that the output will never overwrite
unconsumed input).

In any case I'm of the opinion that the tools limitations with the old
ioctl should be eliminated before 4.0 gets released - I had hoped
that someone with better knowledge of the tools than I have
would approach this, but since no-one showed up I'll try to.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel