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
Jan Beulich (1):
xen: Introduce guest_handle_for_field
Jean Guyader (3):
xen: virq, remove VIRQ_XC_RESERVED
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 | 1905 ++++++++++++++++++++++++++++++++++++
xen/include/asm-x86/guest_access.h | 3 +
xen/include/public/v4v.h | 308 ++++++
xen/include/public/xen.h | 3 +-
xen/include/xen/event.h | 3 +
xen/include/xen/sched.h | 4 +
xen/include/xen/v4v.h | 133 +++
13 files changed, 2405 insertions(+), 17 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
This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE. Signed-off-by: Jan Beulich <JBeulich@suse.com> --- xen/include/asm-x86/guest_access.h | 3 +++ 1 file changed, 3 insertions(+) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
VIRQ_XC_RESERVED was reserved for V4V but we have switched to event channels so this place holder is no longer required. Signed-off-by: Jean Guyader <jean.guyader@citrix.com> --- xen/include/public/xen.h | 1 - 1 file changed, 1 deletion(-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Jean Guyader
2012-Sep-20 09:47 UTC
[PATCH 3/4] 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 | 1905 ++++++++++++++++++++++++++++++++++++ xen/include/public/v4v.h | 308 ++++++ xen/include/public/xen.h | 2 +- xen/include/xen/sched.h | 4 + xen/include/xen/v4v.h | 133 +++ 10 files changed, 2372 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 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote: > 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 []But that isn''t standard C either (before C99 at least). Jan
On 20 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote:>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote: >> 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 [] > > But that isn''t standard C either (before C99 at least). >I found that in xen/public/physdev.h struct physdev_pci_device_add { /* IN */ uint16_t seg; uint8_t bus; uint8_t devfn; uint32_t flags; struct { uint8_t bus; uint8_t devfn; } physfn; #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L uint32_t optarr[]; #elif defined(__GNUC__) uint32_t optarr[0]; #endif }; Would something similar be ok? Thanks, Jean
>>> On 20.09.12 at 12:27, Jean Guyader <jean.guyader@gmail.com> wrote: > On 20 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote: >>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote: >>> 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 [] >> >> But that isn''t standard C either (before C99 at least). >> > > I found that in xen/public/physdev.h > > struct physdev_pci_device_add { > /* IN */ > uint16_t seg; > uint8_t bus; > uint8_t devfn; > uint32_t flags; > struct { > uint8_t bus; > uint8_t devfn; > } physfn; > #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L > uint32_t optarr[]; > #elif defined(__GNUC__) > uint32_t optarr[0]; > #endif > }; > > Would something similar be ok?Yes, obviously. Jan