v8 changes:
- Move v4v private structures to v4v.c
- fix padding
- Fix some coding style issues
- Drop the VIRQ_XC_RESERVED patch
v7 changes:
- Remove v4v_send from the API (v4v_sendv should be
used instead).
- Remove internal_v4v_iov
- Remove useless padding
- Switch back to use uint64_t for the pfn list
instead of xen_pfn_t (to avoid some compat code)
- Rename v4v_iptable to v4v_table.
- Use __copy_to/from_guest when possible
v6 changes:
- Check compiler before using [0] or [].
v5 changes:
- Fix prototypes in v4v.h for do_v4v_op
- Add padding to make sure all the structures
are 64 bits aligned
- Replace [0] with []
v4 changes:
- Stop using ssize_t, use long instead
- Return -MSGSIZE for message bigger than 2GB
- Fixup size handling
- Rename protocol with message_type to avoid the
confusion with the IP protocol flag
- Replaced V4V_DOMID_ANY value with DOMID_INVALID
- Replaced v4v_pfn_t with xen_pfn_t
- Add padding to struct v4v_info
- Fixup hypercall documentation
- Move V4V_ROUNDUP to v4v.c
- Remove v4v_utils.h (we could potentially add it later).
v3 changes:
- Switch to event channel
- Allocated a unbound event channel
per domain.
- Add a new v4v call to share the
event channel port.
- Public headers with actual type definition
- Align all the v4v type to 64 bits
- Modify v4v MAGIC numbers because we won''t
but backward compatible anymore
- Merge insert and insertv
- Merge send and sendv
- Turn all the lock prerequisite from comment
to ASSERT()
- Make use or write_atomic instead of volatile pointers
- Merge v4v_memcpy_to_guest_ring and
v4v_memcpy_to_guest_ring_from_guest
- Introduce copy_from_guest_maybe that can take
a void * and a handle as src address.
- Replace 6 arguments hypercalls with 5 arguments hypercalls.
v2 changes:
- Cleanup plugin header
- Include basic access control
- Use guest_handle_for_field
Jean Guyader (2):
xen: events, exposes evtchn_alloc_unbound_domain
xen: Add V4V implementation
xen/arch/x86/hvm/hvm.c | 6 +-
xen/arch/x86/x86_64/compat/entry.S | 2 +
xen/arch/x86/x86_64/entry.S | 2 +
xen/common/Makefile | 1 +
xen/common/domain.c | 13 +-
xen/common/event_channel.c | 39 +-
xen/common/v4v.c | 1922 ++++++++++++++++++++++++++++++++++++
xen/include/public/v4v.h | 308 ++++++
xen/include/public/xen.h | 2 +-
xen/include/xen/event.h | 3 +
xen/include/xen/sched.h | 4 +
xen/include/xen/v4v.h | 49 +
12 files changed, 2335 insertions(+), 16 deletions(-)
create mode 100644 xen/common/v4v.c
create mode 100644 xen/include/public/v4v.h
create mode 100644 xen/include/xen/v4v.h
--
1.7.9.5
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Jean Guyader
2012-Oct-25 17:55 UTC
[PATCH 1/2] xen: events, exposes evtchn_alloc_unbound_domain
Exposes evtchn_alloc_unbound_domain to the rest of Xen so we can create allocated unbound evtchn within Xen. Signed-off-by: Jean Guyader <jean.guyader@citrix.com> --- xen/common/event_channel.c | 39 +++++++++++++++++++++++++++------------ xen/include/xen/event.h | 3 +++ 2 files changed, 30 insertions(+), 12 deletions(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Setup of v4v domains a domain gets created and cleanup when a domain die. Wire up the v4v hypercall. Include v4v internal and public headers. Signed-off-by: Jean Guyader <jean.guyader@citrix.com> --- xen/arch/x86/hvm/hvm.c | 6 +- xen/arch/x86/x86_64/compat/entry.S | 2 + xen/arch/x86/x86_64/entry.S | 2 + xen/common/Makefile | 1 + xen/common/domain.c | 13 +- xen/common/v4v.c | 1922 ++++++++++++++++++++++++++++++++++++ xen/include/public/v4v.h | 308 ++++++ xen/include/public/xen.h | 2 +- xen/include/xen/sched.h | 4 + xen/include/xen/v4v.h | 49 + 10 files changed, 2305 insertions(+), 4 deletions(-) create mode 100644 xen/common/v4v.c create mode 100644 xen/include/public/v4v.h create mode 100644 xen/include/xen/v4v.h _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 25.10.12 at 19:55, Jean Guyader <jean.guyader@citrix.com> wrote: > v8 changes: > - Move v4v private structures to v4v.c > - fix paddingI still spotted at least one bogus padding field (in struct v4v_ring_message_header, where no field is more than 4-byte aligned afaict). Did you really carefully walk through all of them? Also, to validate the structures are really compatible between native and compat mode guests, I''d strongly recommend adding the leaf ones to xen/include/xlat.lst. Further I don''t think you sync-ed up your patches with the XEN_GUEST_HANDLE_PARAM() changes done for ARM, yet you also didn''t mention that the patch set is against other than the tip of unstable.> - Fix some coding style issuesThere appear to be plenty left (space between function name and opening parenthesis, indentation inside switch statement, missing parenthesization of macro expansion, missing newline between declarations and statements are which I noticed without specifically looking for them). Jan> - Drop the VIRQ_XC_RESERVED patch
On 10/29/2012 02:37 AM, Jan Beulich wrote:>>>> On 25.10.12 at 19:55, Jean Guyader <jean.guyader@citrix.com> wrote: >> v8 changes: >> - Move v4v private structures to v4v.c >> - fix padding > I still spotted at least one bogus padding field (in struct > v4v_ring_message_header, where no field is more than 4-byte > aligned afaict). Did you really carefully walk through all of them?Hi Jan, I am going to try and pilot this home, as I believe JeanG will not. I just had a couple of questions about your comments that I hope you could help me with.> Also, to validate the structures are really compatible between > native and compat mode guests, I''d strongly recommend adding > the leaf ones to xen/include/xlat.lst.I''m sorry I don''t understand. What is xlat.lst ? And how does it help ?> Further I don''t think you sync-ed up your patches with the > XEN_GUEST_HANDLE_PARAM() changes done for ARM, yet you > also didn''t mention that the patch set is against other than the > tip of unstable.Sorry, again I''m confused. I thought all the Xen ARM changes went into xen-unstable. What other branches/trees do you think I need to post the v4v patch set against ?> > There appear to be plenty left (space between function name and > opening parenthesis, indentation inside switch statement, missing > parenthesization of macro expansion, missing newline between > declarations and statements are which I noticed without specifically > looking for them). > >OK. This I can do. dom
>>> On 20.12.12 at 19:14, dom <dominic.curran@citrix.com> wrote: > On 10/29/2012 02:37 AM, Jan Beulich wrote: >>>>> On 25.10.12 at 19:55, Jean Guyader <jean.guyader@citrix.com> wrote: >> Also, to validate the structures are really compatible between >> native and compat mode guests, I''d strongly recommend adding >> the leaf ones to xen/include/xlat.lst. > > I''m sorry I don''t understand. What is xlat.lst ? And how does it help ?This lists types that need either translation or verification that no translation is needed (i.e. structure layouts and type sizes being identical) for compatibility mode guest support.>> Further I don''t think you sync-ed up your patches with the >> XEN_GUEST_HANDLE_PARAM() changes done for ARM, yet you >> also didn''t mention that the patch set is against other than the >> tip of unstable. > > Sorry, again I''m confused. I thought all the Xen ARM changes went into > xen-unstable. > What other branches/trees do you think I need to post the v4v patch set > against ?That''s my point: The ARM changes went in, yet this patch didn''t get sync-ed up accordingly (it ought to use the _PARAM() variant in all relevant places). Jan