|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 MISSING/23] xsplice: Design document (v7).
On Thu, Feb 18, 2016 at 09:20:00AM -0700, Jan Beulich wrote:
> >>> On 12.02.16 at 22:57, <konrad.wilk@xxxxxxxxxx> wrote:
> > +struct xsplice_patch_func {
> > + const char *name;
> > + Elf64_Xwordnew_addr;
>
> Missing space.
>
> > + Elf64_Xword old_addr;
> > + Elf64_Word new_size;
> > + Elf64_Word long old_size;
>
> There are still two types left here.
That wouldn't compile very well.
>
> > +### XEN_SYSCTL_XSPLICE_GET (1)
> > +
> > +Retrieve an status of an specific payload. This caller provides:
> > +
> > + * A `struct xen_xsplice_name` called `name` which has the unique name.
> > + * A `struct xen_xsplice_status` structure which has all members
> > + set to zero: That is:
> > + * `status` *MUST* be set to zero.
> > + * `rc` *MUST* be set to zero.
>
> Why is this?
<scratches his head>..
It had an _pad entry in earlier versions. Let me remove the whole
'set to zero.."
>
> > +The structure is as follow:
> > +
> > +<pre>
> > +struct xen_xsplice_status {
> > +#define XSPLICE_STATUS_LOADED 1
> > +#define XSPLICE_STATUS_CHECKED 2
> > +#define XSPLICE_STATUS_APPLIED 3
> > + int32_t state; /* OUT: XSPLICE_STATE_*. IN: MUST be
> > zero. */
> > + int32_t rc; /* OUT: 0 if no error, otherwise
> > -XEN_EXX. */
> > + /* IN: MUST be zero. */
> > +};
> > +
> > +struct xen_sysctl_xsplice_summary {
> > + xen_xsplice_name_t name; /* IN, the name of the payload. */
> > + xen_xsplice_status_t status; /* IN/OUT: status of the payload. */
> > +};
>
> With the operation being named XEN_SYSCTL_XSPLICE_GET, shouldn't
> the structure tag be xen_sysctl_xsplice_get?
Yes!
>
> > +### XEN_SYSCTL_XSPLICE_LIST (2)
> > +
> > +Retrieve an array of abbreviated status and names of payloads that are
> > loaded in the
> > +hypervisor.
> > +
> > +The caller provides:
> > +
> > + * `version`. Initially (on first hypercall) *MUST* be zero.
> > + * `idx` index iterator. On first call *MUST* be zero, subsequent calls
> > varies.
> > + * `nr` the max number of entries to populate.
> > + * `pad` - *MUST* be zero.
> > + * `status` virtual address of where to write `struct xen_xsplice_status`
> > + structures. Caller *MUST* allocate up to `nr` of them.
> > + * `name` - virtual address of where to write the unique name of the
> > payload.
> > + Caller *MUST* allocate up to `nr` of them. Each *MUST* be of
> > + **XEN_XSPLICE_NAME_SIZE** size.
> > + * `len` - virtual address of where to write the length of each unique name
> > + of the payload. Caller *MUST* allocate up to `nr` of them. Each *MUST*
> > be
> > + of sizeof(uint32_t) (4 bytes).
> > +
> > +If the hypercall returns an positive number, it is the number (upto `nr`
> > +provided to the hypercall) of the payloads returned, along with `nr`
> > updated
> > +with the number of remaining payloads, `version` updated (it may be the
> > same
> > +across hypercalls - if it varies the data is stale and further calls could
> > +fail). The `status`, `name`, and `len`' are updated at their designed index
> > +value (`idx`) with the returned value of data.
> > +
> > +If the hypercall returns -XEN_E2BIG the `nr` is too big and should be
> > +lowered.
> > +
> > +If the hypercall returns an zero value that means there are no payloads.
>
> Maybe worth changing to "... there are no (more) payloads",
> considering the iterative nature of the operation?
Yes.
This is the change I did:
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index 9a95243..69c5176 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -289,10 +289,10 @@ describing the functions to be patched:
<pre>
struct xsplice_patch_func {
const char *name;
- Elf64_Xwordnew_addr;
+ Elf64_Xword new_addr;
Elf64_Xword old_addr;
Elf64_Word new_size;
- Elf64_Word long old_size;
+ Elf64_Word old_size;
uint8_t pad[32];
};
</pre>
@@ -425,10 +425,8 @@ struct xen_sysctl_xsplice_upload {
Retrieve an status of an specific payload. This caller provides:
* A `struct xen_xsplice_name` called `name` which has the unique name.
- * A `struct xen_xsplice_status` structure which has all members
- set to zero: That is:
- * `status` *MUST* be set to zero.
- * `rc` *MUST* be set to zero.
+ * A `struct xen_xsplice_status` structure. The member values will
+ be over-written upon completion.
Upon completion the `struct xen_xsplice_status` is updated.
@@ -473,12 +471,11 @@ struct xen_xsplice_status {
#define XSPLICE_STATUS_LOADED 1
#define XSPLICE_STATUS_CHECKED 2
#define XSPLICE_STATUS_APPLIED 3
- int32_t state; /* OUT: XSPLICE_STATE_*. IN: MUST be zero.
*/
+ int32_t state; /* OUT: XSPLICE_STATE_*. */
int32_t rc; /* OUT: 0 if no error, otherwise -XEN_EXX.
*/
- /* IN: MUST be zero. */
};
-struct xen_sysctl_xsplice_summary {
+struct xen_sysctl_xsplice_get {
xen_xsplice_name_t name; /* IN, the name of the payload. */
xen_xsplice_status_t status; /* IN/OUT: status of the payload. */
};
@@ -514,7 +511,7 @@ value (`idx`) with the returned value of data.
If the hypercall returns -XEN_E2BIG the `nr` is too big and should be
lowered.
-If the hypercall returns an zero value that means there are no payloads.
+If the hypercall returns an zero value there are no more payloads.
Note that due to the asynchronous nature of hypercalls the control domain might
have added or removed a number of payloads making this information stale. It is
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |